我们刚从32位机转移到64位机。尽管新盒子的内存是旧盒子的两倍,但我们的内存很快就用完了。
运行一个简单的ps命令将说明这个问题。
新机器:
132 prod-Charlotte1-node1 ~/public_html/rearch/cgi-bin> ps aux | grep ps
root 293 0.0 0.0 0 0 ? S< May09 0:00 [kpsmoused]
xamine 2267 1.0 0.0 63728 928 pts/3 R+ 16:50 0:00 ps aux
xamine 2268 0.0 0.0 61172 752 pts/3 S+ 16:50 0:00 grep ps旧机器:
132 prod-116431-node1:/home/xamine> ps aux | grep ps
xamine 23191 0.0 0.0 2332 768 pts/6 R+ 15:41 0:00 ps aux
xamine 23192 0.0 0.0 3668 692 pts/6 S+ 15:41 0:00 grep ps注意,ps进程在旧机器上使用了63M的VIRT memvs2。
新机器:
旧机器:
发布于 2010-05-13 03:06:57
取决于您如何计算已使用的内存。如果您正在查看“免费”,请确保折扣缓存和缓冲区的使用。
Linux尽力缓存尽可能多的磁盘活动,这样对这些文件的后续访问要比再次访问磁盘快得多。如果需要内存,将释放缓存内存以满足新请求。
例:
# free
total used free shared buffers cached
Mem: 3973040 3944864 28176 0 433448 3123468
-/+ buffers/cache: 387948 3585092
Swap: 2040244 72080 1968164在这种情况下,当系统报告几乎所有4G内存时,更仔细的检查表明它的3G是“缓存”的,这意味着实际上有足够的内存可用。free输出的第二行表示计算--不包括缓冲区和缓存,有3.5G可用内存。
发布于 2010-05-13 01:24:00
virt内存号有误导性。它包括程序链接到的所有共享库的大小。这些库,由于是共享的,只在所有使用它们的程序的系统内存中加载一次。
在这种情况下,一个更好的衡量进程内存使用情况的方法是驻留集大小(RSS),它是虚拟内存之后的列。这是您的应用程序正在使用的物理内存量。假设您不准备进行交换,这对于像ps这样的程序是不太可能的,这很好地衡量了应用程序在本例中使用了多少“实际”内存。根据这一衡量标准,两者之间的差异基本上可以忽略不计。
虚拟大小差异很大的原因可能是由于各种原因。部分原因可能是64位对32位系统中类型(特别是指针)的较大大小。另一个原因可能只是因为库的大小增加,或者是链接到不同数量的库。
也许,如果您提供了一个更有代表性的示例,说明在这些机器上实际运行的是什么,这将更有助于找出内存不足的原因。
https://serverfault.com/questions/141321
复制相似问题