因此，在Solaris 10 10/09区域，我看到所有常驻内存都用完了。 在试图find分配所有物理内存的过程时，我注意到RSS总计“prstat”给出的不是加起来的区域中使用的整个RSS。
没有共享内存段，并且pmap -x报告与prstat中单个进程所报告的相同的使用数量。
这是一些命令输出。 正如你所看到的，为顶级进程添加RSS远不如报告的总体RSS（5063M）。
# prstat -n 20 -s rss -Z PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 18481 nobody 14G 1457M cpu18 30 0 0:20:51 4.3% java/272 18970 nobody 435M 399M sleep 59 0 0:02:44 1.2% java/30 19083 nobody 371M 363M sleep 59 0 0:02:08 0.4% java/47 18803 nobody 330M 257M sleep 59 0 0:09:51 13% java/366 22260 nobody 410M 132M sleep 59 0 3:52:07 0.3% java/23 12430 daemon 81M 35M sleep 59 0 0:00:23 0.0% httpd/28 12429 daemon 87M 33M sleep 59 0 0:00:22 0.0% httpd/28 ... very low usage processes .... ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE 17 93 3197M 5063M 99% 24:57:19 27% cygna 任何想法，所有的物理记忆已经走了？
常驻和共享重叠，或者：共享内存页面不是唯一的。 例如，如果多个进程将libc映射到它们的内存空间，那么这些将被共享（直到COW使它们不共享）。 pmap的输出可能会有帮助。
另请参阅此答案的一些见解，但请记住，Solaris和Linux内存pipe理在一些细节上有所不同（最重要的是过度使用的方法）： https ： //stackoverflow.com/questions/1612939/why-does-在朝阳的JVM继续用消费，不断更RSS内存偶数时，在堆