服务器 Gind.cn
  1. 服务器 Gind.cn
  3. exception高的dentrycaching使用率
Intereting Posts
如何设置客户端和服务器无关的VPN 比较二进制文件 ZFS（Solaris 11） – SAS控制器死亡并被replace – 池被暂停 rsync失败 – 设备上没有剩余空间（28） 在到达WSGI之前，Apache2返回404代理请求 使用ap9630networkingpipe理卡configurationapc ups 使用git repo保持远程服务器的最新状态 虚拟化：64位还是32位？ 有效处理2百万个文件 macros，模板，函数或类似的Apache的conf文件 获取由vCenterpipe理的虚拟机中的所有快照列表？ 杀死过程如果高负荷平均 允许用户更改文件夹的权限，但不删除/更改域pipe理员访问？ 限制目录大小 Debian Squeeze服务器可以Ping IP地址，但不能域名

exception高的dentrycaching使用率

问题

内核为2.6.32和128 GB的物理内存的CentOS机器几天前遇到麻烦。 负责的系统pipe理员告诉我，由于交换，PHP-FPM应用程序不再及时响应请求，并且free看到几乎没有剩余内存，他select重新启动机器。

我知道可用内存在Linux上可能是一个令人困惑的概念，重启也许是错误的做法。 然而，提到的pipe理员指责PHP应用程序（我负责），并拒绝进一步调查。

我能够自己find的是这样的：

  • 在重新启动之前，空闲内存（包括缓冲区和caching）只有几百MB。
  • 在重新启动之前， /proc/meminfo报告了大约90 GB的板内存使用情况（是，GB）。
  • 重新启动后，空闲内存为119 GB，在一小时内下降到100 GB左右，因为PHP-FPM工作人员（其中约600人）正在恢复生机，每个人都显示30到40 MB RES列（最近几个月已经这样了，考虑到PHP应用程序的性质，它是完全合理的）。 进程列表中没有任何内容会消耗不寻常的或值得注意的RAM数量。
  • 重新启动后，Slab内存大约为300 MB

如果自那时以来一直在监视系统，最值得注意的是Slab内存以每天5GB的速度直线增长。 free和/proc/meminfo报告的free内存以相同的速率下降。 Slab目前在46 GB。 根据slabtop大部分是用于dentry条目：

可用内存： 

 free -m total used free shared buffers cached Mem: 129048 76435 52612 0 144 7675 -/+ buffers/cache: 68615 60432 Swap: 8191 0 8191

meminfo中： 

 cat /proc/meminfo MemTotal: 132145324 kB MemFree: 53620068 kB Buffers: 147760 kB Cached: 8239072 kB SwapCached: 0 kB Active: 20300940 kB Inactive: 6512716 kB Active(anon): 18408460 kB Inactive(anon): 24736 kB Active(file): 1892480 kB Inactive(file): 6487980 kB Unevictable: 8608 kB Mlocked: 8608 kB SwapTotal: 8388600 kB SwapFree: 8388600 kB Dirty: 11416 kB Writeback: 0 kB AnonPages: 18436224 kB Mapped: 94536 kB Shmem: 6364 kB Slab: 46240380 kB SReclaimable: 44561644 kB SUnreclaim: 1678736 kB KernelStack: 9336 kB PageTables: 457516 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 72364108 kB Committed_AS: 22305444 kB VmallocTotal: 34359738367 kB VmallocUsed: 480164 kB VmallocChunk: 34290830848 kB HardwareCorrupted: 0 kB AnonHugePages: 12216320 kB HugePages_Total: 2048 HugePages_Free: 2048 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 5604 kB DirectMap2M: 2078720 kB DirectMap1G: 132120576 kB

Slabtop： 

 slabtop --once Active / Total Objects (% used) : 225920064 / 226193412 (99.9%) Active / Total Slabs (% used) : 11556364 / 11556415 (100.0%) Active / Total Caches (% used) : 110 / 194 (56.7%) Active / Total Size (% used) : 43278793.73K / 43315465.42K (99.9%) Minimum / Average / Maximum Object : 0.02K / 0.19K / 4096.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 221416340 221416039 3% 0.19K 11070817 20 44283268K dentry 1123443 1122739 99% 0.41K 124827 9 499308K fuse_request 1122320 1122180 99% 0.75K 224464 5 897856K fuse_inode 761539 754272 99% 0.20K 40081 19 160324K vm_area_struct 437858 223259 50% 0.10K 11834 37 47336K buffer_head 353353 347519 98% 0.05K 4589 77 18356K anon_vma_chain 325090 324190 99% 0.06K 5510 59 22040K size-64 146272 145422 99% 0.03K 1306 112 5224K size-32 137625 137614 99% 1.02K 45875 3 183500K nfs_inode_cache 128800 118407 91% 0.04K 1400 92 5600K anon_vma 59101 46853 79% 0.55K 8443 7 33772K radix_tree_node 52620 52009 98% 0.12K 1754 30 7016K size-128 19359 19253 99% 0.14K 717 27 2868K sysfs_dir_cache 10240 7746 75% 0.19K 512 20 2048K filp

VFScaching压力： 

 cat /proc/sys/vm/vfs_cache_pressure 125

Swappiness： 

 cat /proc/sys/vm/swappiness 0

我知道未使用的内存是浪费内存，所以这不应该是一件坏事（尤其是考虑到44 GB显示为SReclaimable）。 然而，显然这台机器还是遇到了问题，而且恐怕当Slab超过90GB时，几天之内会再次出现这种情况。

问题

我有这些问题：

  • 我正确地认为Slab内存总是物理内存，而且这个数字已经从MemFree的值中减去了吗？
  • 如此多的dentry条目是否正常？ PHP应用程序可以访问大约1.5M的文件，但是其中大部分是归档文件，并且根本没有访问常规的网页stream量。
  • 有什么可以解释的事实，即cachinginode的数量远远低于cachingdentries的数量，如果他们不相关？
  • 如果系统遇到内存麻烦，内核是不是应该自动释放一些内存？ 可能是什么原因，这不会发生？
  • 有什么方法可以“查看”dentrycaching来查看所有这些内存（即，正在caching的path是什么）？ 也许这指向某种内存泄漏，符号链接循环，或者实际上是PHP应用程序做错的事情。
  • PHP应用程序代码以及所有的资产文件都是通过GlusterFSnetworking文件系统装载的，可能与它有关系吗？

请记住，我不能以root身份进行调查，只能以普通用户身份进行调查，而pipe理员拒绝提供帮助。 他甚至不会运行典型的echo 2 > /proc/sys/vm/drop_cachestesting来查看Slab内存是否真的可以回收。

任何深入了解可能发生的事情以及如何进一步调查将不胜感激。

更新

一些更多的诊断信息：

坐骑： 

 cat /proc/self/mounts rootfs / rootfs rw 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 devtmpfs /dev devtmpfs rw,relatime,size=66063000k,nr_inodes=16515750,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,relatime 0 0 /dev/mapper/sysvg-lv_root / ext4 rw,relatime,barrier=1,data=ordered 0 0 /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0 /dev/sda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0 tmpfs /phptmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0 tmpfs /wsdltmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 cgroup /cgroup/cpuset cgroup rw,relatime,cpuset 0 0 cgroup /cgroup/cpu cgroup rw,relatime,cpu 0 0 cgroup /cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0 cgroup /cgroup/memory cgroup rw,relatime,memory 0 0 cgroup /cgroup/devices cgroup rw,relatime,devices 0 0 cgroup /cgroup/freezer cgroup rw,relatime,freezer 0 0 cgroup /cgroup/net_cls cgroup rw,relatime,net_cls 0 0 cgroup /cgroup/blkio cgroup rw,relatime,blkio 0 0 /etc/glusterfs/glusterfs-www.vol /var/www fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0 /etc/glusterfs/glusterfs-upload.vol /var/upload fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 172.17.39.78:/www /data/www nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78 0 0

login信息： 

 cat /proc/self/mountinfo 16 21 0:3 / /proc rw,relatime - proc proc rw 17 21 0:0 / /sys rw,relatime - sysfs sysfs rw 18 21 0:5 / /dev rw,relatime - devtmpfs devtmpfs rw,size=66063000k,nr_inodes=16515750,mode=755 19 18 0:11 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000 20 18 0:16 / /dev/shm rw,relatime - tmpfs tmpfs rw 21 1 253:1 / / rw,relatime - ext4 /dev/mapper/sysvg-lv_root rw,barrier=1,data=ordered 22 16 0:15 / /proc/bus/usb rw,relatime - usbfs /proc/bus/usb rw 23 21 8:1 / /boot rw,relatime - ext4 /dev/sda1 rw,barrier=1,data=ordered 24 21 0:17 / /phptmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777 25 21 0:18 / /wsdltmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777 26 16 0:19 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc none rw 27 21 0:20 / /cgroup/cpuset rw,relatime - cgroup cgroup rw,cpuset 28 21 0:21 / /cgroup/cpu rw,relatime - cgroup cgroup rw,cpu 29 21 0:22 / /cgroup/cpuacct rw,relatime - cgroup cgroup rw,cpuacct 30 21 0:23 / /cgroup/memory rw,relatime - cgroup cgroup rw,memory 31 21 0:24 / /cgroup/devices rw,relatime - cgroup cgroup rw,devices 32 21 0:25 / /cgroup/freezer rw,relatime - cgroup cgroup rw,freezer 33 21 0:26 / /cgroup/net_cls rw,relatime - cgroup cgroup rw,net_cls 34 21 0:27 / /cgroup/blkio rw,relatime - cgroup cgroup rw,blkio 35 21 0:28 / /var/www rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-www.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 36 21 0:29 / /var/upload rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-upload.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 37 21 0:30 / /var/lib/nfs/rpc_pipefs rw,relatime - rpc_pipefs sunrpc rw 39 21 0:31 / /data/www rw,relatime - nfs 172.17.39.78:/www rw,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78

GlusterFSconfiguration： 

 cat /etc/glusterfs/glusterfs-www.vol volume remote1 type protocol/client option transport-type tcp option remote-host 172.17.39.71 option ping-timeout 10 option transport.socket.nodelay on # undocumented option for speed # http://gluster.org/pipermail/gluster-users/2009-September/003158.html option remote-subvolume /data/www end-volume volume remote2 type protocol/client option transport-type tcp option remote-host 172.17.39.72 option ping-timeout 10 option transport.socket.nodelay on # undocumented option for speed # http://gluster.org/pipermail/gluster-users/2009-September/003158.html option remote-subvolume /data/www end-volume volume remote3 type protocol/client option transport-type tcp option remote-host 172.17.39.73 option ping-timeout 10 option transport.socket.nodelay on # undocumented option for speed # http://gluster.org/pipermail/gluster-users/2009-September/003158.html option remote-subvolume /data/www end-volume volume remote4 type protocol/client option transport-type tcp option remote-host 172.17.39.74 option ping-timeout 10 option transport.socket.nodelay on # undocumented option for speed # http://gluster.org/pipermail/gluster-users/2009-September/003158.html option remote-subvolume /data/www end-volume volume replicate1 type cluster/replicate option lookup-unhashed off # off will reduce cpu usage, and network option local-volume-name 'hostname' subvolumes remote1 remote2 end-volume volume replicate2 type cluster/replicate option lookup-unhashed off # off will reduce cpu usage, and network option local-volume-name 'hostname' subvolumes remote3 remote4 end-volume volume distribute type cluster/distribute subvolumes replicate1 replicate2 end-volume volume iocache type performance/io-cache option cache-size 8192MB # default is 32MB subvolumes distribute end-volume volume writeback type performance/write-behind option cache-size 1024MB option window-size 1MB subvolumes iocache end-volume ### Add io-threads for parallel requisitions volume iothreads type performance/io-threads option thread-count 64 # default is 16 subvolumes writeback end-volume volume ra type performance/read-ahead option page-size 2MB option page-count 16 option force-atime-update no subvolumes iothreads end-volume

我正确地认为Slab内存总是物理内存，而且这个数字已经从MemFree的值中减去了吗？

是。

如此多的dentry条目是否正常？ PHP应用程序可以访问大约1.5M的文件，但是其中大部分是归档文件，并且根本没有访问常规的网页stream量。

是的，如果系统没有内存压力。 它必须使用内存来处理某些事情，而且在使用这种特殊模式的时候，这是使用这种内存的最好方法。

有什么可以解释的事实，即cachinginode的数量远远低于cachingdentries的数量，如果他们不相关？

很多目录操作将是最可能的解释。

如果系统遇到内存麻烦，内核是不是应该自动释放一些内存？ 可能是什么原因，这不会发生？

应该的，我想不出有什么理由。 我不相信这是真正的错误。 我强烈build议升级你的内核或进一步增加vfs_cache_pressure。

有什么方法可以“查看”dentrycaching来查看所有这些内存（即，正在caching的path是什么）？ 也许这指向某种内存泄漏，符号链接循环，或者实际上是PHP应用程序做错的事情。

我不相信有。 我会寻找任何目录荒谬的大量条目或非常深的目录结构进行search或遍历。

PHP应用程序代码以及所有资产文件都是通过GlusterFSnetworking文件系统装载的，可能与它有关系吗？

当然，这可能是一个文件系统的问题。 例如，导致文件系统错误不能被释放的可能性是可能的。

确认的解决scheme

对任何人可能遇到同样的问题。 数据中心人员终于明白了这一点。 罪魁祸首是与Libcurl捆绑在一起的NSS（networking安全服务）库。 升级到最新版本解决了这个问题。

描述细节的错误报告在这里：

https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1044666

显然，为了确定某个path是本地还是networking驱动器，NSS正在查找一个不存在的文件，并测量文件系统报告的时间！ 如果你有足够多的Curl请求和足够的内存，这些请求都被caching和堆栈。

我遇到了这个确切的问题，而沃尔夫冈是正确的原因，有一些重要的细节丢失。

  • 此问题会影响使用curl或libcurl或使用mozilla NSS进行安全连接的任何其他软件完成的SSL请求。 不安全的请求不会触发问题。

  • 该问题不需要并发curl请求。 只要curl调用频率足以超过操作系统恢复RAM的努力，就会发生dentry的积累。

  • 新版本的NSS 3.16.0确实包含了一个解决scheme。 但是，您不能通过升级NSS来免费获得修复程序，而且您不必升级所有NSS。 你只需要升级至lessnss-softokn（它对nss-utils具有所需的依赖）。 为了获得好处，您需要为正在使用libcurl的进程设置环境variablesNSS_SDB_USE_CACHE。 该环境variables的存在是允许跳过昂贵的不存在的文件检查。

FWIW，我写了一个更多的背景/细节的博客条目 ，以防万一谁需要它。

不是真正解释你的答案，但作为这个系统的用户，你提供的这些信息： 

 cat /proc/meminfo MemTotal: 132145324 kB ... SReclaimable: 44561644 kB SUnreclaim: 1678736 kB

足以告诉我，这不是你的问题 ，它是系统pipe理员提供足够解释的责任。

我不想听起来粗鲁，但是;

  • 您缺less有关此主机angular色的具体信息。
  • 主机如何优先考虑资源超出了你的范围。
  • 您不熟悉，或在此主机上的存储devise和部署中有任何部分。
  • 由于您不是root用户，因此无法提供某些系统输出。

certificate或解决板坯分配exception是你的系统pipe理员的责任 。 要么你没有给我们一个完整的描述（你坦率地说我不感兴趣），或者你的系统pipe理员以他认为处理这个问题的方式performance得不负责任和/或无能为力。

随意告诉他一些随机的陌生人在互联网上认为他没有认真对待他的责任。

见https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm1/broken-out/vfs-shrinkage-tuning.patch

有数字显示，当vfs_cache_pressure被设置为高于100时，你可以期待一些明显的dentry内存回收。因此，在你的情况下，125可能太低了。