異常に高いDentryキャッシュ使用量
問題
カーネル2.6.32と128 GBの物理を備えたCentOSマシンRAM数日前に問題が発生しました。担当のシステム管理者から、PHP-FPMアプリケーションが要求にタイムリーに応答していなかったとのことです。スワッピングによる方法で、メモリがほとんど残っていないことをfreeで確認したので、彼はマシンの再起動を選択しました。
Linuxでは空きメモリが混乱を招く概念になる可能性があることを知っています。ただし、上記の管理者は、PHPアプリケーション（私が担当））を非難し、さらに調査することを拒否します。
私が自分で見つけることができるのはこれです：
- 再起動前は、空きメモリ（バッファとキャッシュを含む）は数百MBしかありませんでした。
- 再起動する前に、
/proc/meminfoは約90 GB（はい、GB）のスラブメモリ使用量を報告しました。 - 再起動後の空きメモリは119 GBでしたが、1時間以内に約100 GBに減少しました。これは、PHP-FPMワーカー（そのうちの約600人）が復活し、それぞれに30〜40 MBが表示されたためです。上部のRES列（これは何ヶ月もこの方法であり、PHPアプリケーションの性質を考えると完全に合理的です）。プロセスリストには、異常なまたは注目に値する量を消費するものは他にありません。羊。
- 再起動後、スラブメモリは約300 MBでした
それ以来システムを監視している場合、最も顕著なのは、スラブのメモリが1日あたり約5 GBの速度で直線的に増加していることです。 freeおよび/proc/meminfoによって報告された空きメモリは、同じ割合で減少します。スラブは現在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 --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
VFSキャッシュ圧力：
cat /proc/sys/vm/vfs_cache_pressure
125
Swappiness：
cat /proc/sys/vm/swappiness
0
未使用のメモリは無駄なメモリであることを知っているので、これは必ずしも悪いことではありません（特に44 GBがSReclaimableとして表示される場合）。しかし、どうやらこのマシンで問題が発生したようです。スラブが90 GBを超えると、数日後に同じことが再び起こると思います。
ご質問
私はこれらの質問があります：
- スラブメモリは常に物理RAMであり、その数はMemFree値から既に差し引かれていると私は思っていますか？
- このような多数の歯科エントリは正常ですか？ PHPアプリケーションは約1.5 Mのファイルにアクセスできますが、それらのほとんどはアーカイブであり、通常のWebトラフィックではまったくアクセスされません。
- キャッシュされたiノードの数が、キャッシュされたエントリの数よりもはるかに少ないという事実は、どういうわけかそれらが関連付けられていないのではないでしょうか？
- システムでメモリの問題が発生した場合、カーネルはいくつかのエントリを自動的に解放しないでください。これが起こらない理由は何でしょうか？
- デントリキャッシュを「調査」して、このメモリが何であるか（つまり、キャッシュされているパスは何か）を確認する方法はありますか？おそらくこれは、何らかのメモリリーク、シンボリックリンクループ、または実際にPHPアプリケーションが間違っていることを示しています。
- PHPアプリケーションコードとすべてのアセットファイルはGlusterFSネットワークファイルシステムを介してマウントされていますが、何か関係があるのでしょうか？
Rootとして調査することはできず、通常のユーザーとしてのみ調査すること、および管理者が支援を拒否することを覚えておいてください。彼は典型的なecho 2 > /proc/sys/vm/drop_cachesテストも実行せず、スラブメモリが本当に再利用可能かどうかを確認しません。
何が起こっているのか、そして私がさらに調査する方法についての洞察があれば、大歓迎です。
アップデート
その他の診断情報：
マウント：
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
マウント情報：
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
GlusterFS構成：
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
スラブメモリは常に物理RAMであり、その数はMemFree値から既に差し引かれていると私は思っていますか？
はい。
このような多数の歯科エントリは正常ですか？ PHPアプリケーションは約1.5 Mのファイルにアクセスできますが、それらのほとんどはアーカイブであり、通常のWebトラフィックではまったくアクセスされません。
はい、システムにメモリの負荷がかかっていない場合。それは何かのためにメモリを使用する必要があり、特定の使用パターンでは、これがそのメモリを使用する最良の方法である可能性があります。
キャッシュされたiノードの数が、キャッシュされたエントリの数よりもはるかに少ないという事実は、どういうわけかそれらが関連付けられていないのではないでしょうか？
多くのディレクトリ操作が最も可能性の高い説明です。
システムでメモリの問題が発生した場合、カーネルはいくつかのエントリを自動的に解放しないでください。これが起こらない理由は何でしょうか？
それはそうあるべきであり、私がそれをしない理由を考えることはできません。これが実際にうまくいかなかったと私は確信していません。カーネルをアップグレードするか、vfs_cache_pressureをさらに増やすことを強くお勧めします。
デントリキャッシュを「調査」して、このメモリが何であるか（つまり、キャッシュされているパスは何か）を確認する方法はありますか？おそらくこれは、何らかのメモリリーク、シンボリックリンクループ、または実際にPHPアプリケーションが間違っていることを示しています。
あるとは思わない。検索またはトラバースされる、非常に多数のエントリまたは非常に深いディレクトリ構造を持つディレクトリを探します。
PHPアプリケーションコードとすべてのアセットファイルはGlusterFSネットワークファイルシステムを介してマウントされていますが、何か関係があるのでしょうか？
間違いなく、それはファイルシステムの問題である可能性があります。たとえば、dentriesがリリースされない原因となっているファイルシステムのバグが考えられます。
確認済みのソリューション
同じ問題に遭遇する可能性のあるすべての人に。データセンターの関係者は、ついにそれを理解しました。犯人は、LibcurlにバンドルされているNSS（Network Security Services）ライブラリでした。最新バージョンにアップグレードすると問題が解決しました。
詳細を説明するバグレポートはこちらです：
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1044666
明らかに、一部のパスがローカルまたはネットワークドライブ上にあるかどうかを判断するために、NSSは存在しないファイルを検索し、ファイルシステムがレポートを返すのにかかる時間を測定していました。十分な数のCurlリクエストと十分なメモリがある場合、これらのリクエストはすべてキャッシュされ、スタックされます。
私はこの正確な問題に遭遇しました、そして、Wolfgangは原因について正しいですが、いくつかの重要な詳細が欠けています。
この問題は、curlやlibcurl、またはたまたまセキュアな接続にmozilla NSSを使用する他のソフトウェアで行われたSSLリクエストに影響します。安全でないリクエストは、問題を引き起こしません。
この問題では、同時curl要求は必要ありません。デンタルの蓄積は、RAMを再利用しようとするOSの取り組みを上回るほど頻繁にcurl呼び出しが行われる限り発生します。
nSSの新しいバージョンである3.16.0には、これに対する修正が含まれています。ただし、NSSをアップグレードしても無料で修正を入手することはできず、NSS全体をアップグレードする必要もありません。少なくとも、nss-softokn（nss-utilsに必要な依存関係があります）をアップグレードするだけで済みます。また、メリットを得るには、libcurlを使用しているプロセスの環境変数NSS_SDB_USE_CACHEを設定する必要があります。その環境変数の存在により、コストのかかる存在しないファイルチェックをスキップできます。
FWIW、誰かがそれを必要とする場合に備えて、私は ブログエントリ をもう少し背景/詳細とともに書きました。
Vfs_cache_pressureが100よりも高い値に設定されている場合、いくつかの顕著なデントリーメモリの再利用が期待できることを示す数値があります。そのため、125が低すぎて、発生しない場合があります。
あなたの答えに対する実際の説明ではなく、このシステムのユーザーとして提供したこの情報：
cat /proc/meminfo
MemTotal: 132145324 kB
...
SReclaimable: 44561644 kB
SUnreclaim: 1678736 kB
これはあなたの問題ではないことであり、適切な説明を提供するのはsysadminの責任であると私に伝えるのに十分です。
ここで失礼な言い方をしたくはありませんが、
- このホストの役割に関する具体的な情報が不足しています。
- ホストがリソースに優先順位を付ける方法は範囲外です。
- このホストでのストレージの設計と導入に慣れていないか、関与していません。
- Rootでないため、特定のシステム出力を提供できません。
スラブ割り当ての異常を正当化または解決するのはあなたのsysadminsの責任です。あなたがこれに至るまでのサガ全体の完全な写真を提供していない（正直言って私は興味がありません）か、システム管理者が無責任にまたは無能にこの問題の処理を検討しているようです。
インターネット上のランダムな見知らぬ人が、彼が自分の責任を真剣に受け止めていないと考えていることを遠慮なく彼に言ってください。