新的64位Linux系统有正常的进程(ps,grep等)占用过多的VIRT mem

我们刚刚从一台32位的机器移到了一台64位的机器上。 尽pipe新盒子的内存是旧盒子的两倍,但我们很快就耗尽了内存。

运行一个简单的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进程在旧机器上使用的是VIRT mem和2的63M。

新机器:

  • 企业Linux企业Linux服务器版本5.4(迦太基)
  • 红帽企业Linux服务器版本5.4(Tikanga)

旧机器:

  • 红帽企业Linux ES第四版(Nahant Update 4)

取决于你如何计算使用的内存。 如果你正在看“免费”,一定要打折使用的caching和缓冲区。

Linux试图caching尽可能多的磁盘活动,以便后续访问这些文件比再次访问磁盘快得多。 如果需要内存,caching将被释放以满足新的请求。

例如:

 # free total used free shared buffers cached Mem: 3973040 3944864 28176 0 433448 3123468 -/+ buffers/cache: 387948 3585092 Swap: 2040244 72080 1968164 

在这种情况下,虽然系统报告几乎所有的4G内存使用,但仔细检查表明,它的3G是“caching”,这意味着实际上有足够的内存。 free输出的第二行代表计算 – 不包括缓冲区和caching,有3.5G可用内存。

虚拟内存编号是误导性的。 它包括程序链接的所有共享库的大小。 这些库由于被共享而只加载一次到所有使用它们的程序的系统内存中。

在这种情况下,您的进程的内存使用情况的更好的衡量标准是驻留集大小(RSS),即虚拟内存之后的列。 这是您的应用程序正在使用的物理内存量。 假设你不打算进行交换,对于像ps这样的程序来说这是不太可能的,这是衡量应用程序在这种情况下使用多less“实际”内存的一个很好的方法。 按照这个标准,这个差别基本上可以忽略不计。

虚拟尺寸的巨大差异的原因可能是由于许多原因。 部分原因可能是由于64位和32位系统中的types较大,特别是指针。 另一个原因可能仅仅是因为图书馆规模的增加,或者是连接到不同数量的图书馆。

也许如果你给了这些机器上实际运行的更具代表性的样本,这将有助于查明你为什么内存不足。