我们刚刚从 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 内存,而旧机器上只有 2M。
新机器:
- 企业 Linux 企业 Linux 服务器版本 5.4 (Carthage)
- Red Hat Enterprise Linux 服务器版本 5.4 (Tikanga)
旧机器:
- Red Hat Enterprise Linux ES 版本 4(Nahant 更新 4)
答案1
取决于您如何计算已用内存。如果您查看的是“空闲”,请确保扣除已使用的缓存和缓冲区。
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 可用内存。
答案2
虚拟内存数字具有误导性。它包括程序链接的所有共享库的大小。由于这些库是共享的,因此对于使用它们的所有程序来说,它们只会被加载到系统内存中一次。
在这种情况下,衡量进程内存使用情况的更好方法是使用驻留集大小 (RSS),即虚拟内存后面的列。这是应用程序使用的物理内存量。假设您不打算进行交换(对于像 ps 这样的程序来说,这不太可能),这是衡量应用程序在这种情况下使用了多少“实际”内存的一个很好的指标。按照这个指标,差异基本上可以忽略不计。
虚拟大小的巨大差异可能是由多种原因造成的。部分原因可能是由于 64 位系统与 32 位系统相比,类型(尤其是指针)的大小更大。另一个原因可能只是由于库的大小增加,或者链接到不同数量的库。
也许,如果您提供这些机器上实际运行的更具代表性的样本,它将更有助于查明内存不足的原因。