Penggunaan cache dentry yang luar biasa tinggi

Masalah

Mesin CentOS dengan kernel 2.6.32 dan 128 GB RAM fisik mengalami masalah beberapa hari yang lalu. Administrator sistem yang bertanggung jawab memberi tahu saya bahwa aplikasi PHP-FPM tidak menanggapi permintaan secara tepat waktu lagi karena bertukar, dan setelah melihat freebahwa hampir tidak ada memori yang tersisa, ia memilih untuk mem-boot ulang mesin.

Saya tahu bahwa memori bebas bisa menjadi konsep yang membingungkan di Linux dan reboot mungkin adalah hal yang salah untuk dilakukan. Namun, administrator yang disebutkan menyalahkan aplikasi PHP (yang saya bertanggung jawab untuk) dan menolak untuk menyelidiki lebih lanjut.

Apa yang bisa saya temukan sendiri adalah ini:

• Sebelum restart, memori bebas (termasuk buffer dan cache) hanya beberapa ratus MB.
• Sebelum memulai ulang, /proc/meminfolaporkan penggunaan memori Slab sekitar 90 GB (ya, GB).
• Setelah restart, memori bebas adalah 119 GB, turun menjadi sekitar 100 GB dalam satu jam, karena pekerja PHP-FPM (sekitar 600 dari mereka) hidup kembali, masing-masing menunjukkan antara 30 dan 40 MB di Kolom RES di atas (yang telah seperti ini selama berbulan-bulan dan sangat masuk akal mengingat sifat aplikasi PHP). Tidak ada hal lain dalam daftar proses yang mengkonsumsi jumlah RAM yang tidak biasa atau perlu diperhatikan.
• Setelah restart, memori Slab sekitar 300 MB

Jika telah memonitor sistem sejak itu, dan terutama memori Slab meningkat dalam garis lurus dengan kecepatan sekitar 5 GB per hari. Kosongkan memori seperti yang dilaporkan oleh freedan /proc/meminfomenurun pada tingkat yang sama. Slab saat ini pada 46 GB. Menurut slabtopsebagian besar digunakan untuk dentryentri:

Memori bebas:

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  

Tekanan cache VFS:

cat /proc/sys/vm/vfs_cache_pressure
125

Swappiness:

cat /proc/sys/vm/swappiness
0

Saya tahu bahwa memori yang tidak digunakan adalah memori yang terbuang, jadi ini seharusnya tidak menjadi hal yang buruk (terutama mengingat bahwa 44 GB ditampilkan sebagai SReclaimable). Namun, tampaknya mesin mengalami masalah, dan saya khawatir hal yang sama akan terjadi lagi dalam beberapa hari ketika Slab melampaui 90 GB.

Pertanyaan

Saya punya pertanyaan ini:

• Apakah saya benar dalam berpikir bahwa memori Slab selalu merupakan RAM fisik, dan jumlahnya sudah dikurangi dari nilai MemFree?
• Apakah jumlah entri gigi yang tinggi itu normal? Aplikasi PHP memiliki akses ke sekitar 1,5 M file, namun kebanyakan dari mereka adalah arsip dan tidak diakses sama sekali untuk lalu lintas web biasa.
• Apa yang bisa menjadi penjelasan untuk fakta bahwa jumlah inode yang di-cache jauh lebih rendah daripada jumlah dent yang di-cache, seandainya mereka tidak terkait entah bagaimana?
• Jika sistem mengalami masalah memori, haruskah kernel tidak membebaskan sebagian gigi palsu secara otomatis? Apa yang bisa menjadi alasan bahwa ini tidak terjadi?
• Apakah ada cara untuk "melihat" cache dentry untuk melihat semua memori ini (yaitu apa jalur yang sedang di-cache)? Mungkin ini menunjuk ke beberapa jenis kebocoran memori, symlink loop, atau memang sesuatu yang salah aplikasi PHP lakukan.
• Kode aplikasi PHP dan juga semua file aset dipasang melalui sistem file jaringan GlusterFS, bisakah itu ada hubungannya dengan itu?

Harap diingat bahwa saya tidak dapat menyelidiki sebagai root, hanya sebagai pengguna biasa, dan bahwa administrator menolak untuk membantu. Dia bahkan tidak akan menjalankan echo 2 > /proc/sys/vm/drop_cachestes khas untuk melihat apakah memori Slab memang dapat dipulihkan.

Setiap wawasan tentang apa yang bisa terjadi dan bagaimana saya bisa menyelidiki lebih jauh akan sangat dihargai.

Pembaruan

Beberapa informasi diagnostik lebih lanjut:

Gunung:

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

Info pemasangan:

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

Konfigurasi 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

Apakah saya benar dalam berpikir bahwa memori Slab selalu merupakan RAM fisik, dan jumlahnya sudah dikurangi dari nilai MemFree?

Iya nih.

Apakah jumlah entri gigi yang tinggi itu normal? Aplikasi PHP memiliki akses ke sekitar 1,5 M file, namun kebanyakan dari mereka adalah arsip dan tidak diakses sama sekali untuk lalu lintas web biasa.

Ya, jika sistem tidak berada di bawah tekanan memori. Itu harus menggunakan memori untuk sesuatu, dan mungkin dalam pola penggunaan khusus Anda, ini adalah cara terbaik untuk menggunakan memori itu.

Apa yang bisa menjadi penjelasan untuk fakta bahwa jumlah inode yang di-cache jauh lebih rendah daripada jumlah dent yang di-cache, seandainya mereka tidak terkait entah bagaimana?

Banyak operasi direktori akan menjadi penjelasan yang paling mungkin.

Jika sistem mengalami masalah memori, haruskah kernel tidak membebaskan sebagian gigi palsu secara otomatis? Apa yang bisa menjadi alasan bahwa ini tidak terjadi?

Seharusnya, dan saya tidak bisa memikirkan alasan apa pun. Saya tidak yakin bahwa inilah yang salah. Saya sangat menyarankan untuk meningkatkan kernel Anda atau meningkatkan vfs_cache_pressure lebih lanjut.

Apakah ada cara untuk "melihat" cache dentry untuk melihat semua memori ini (yaitu apa jalur yang sedang di-cache)? Mungkin ini menunjuk ke beberapa jenis kebocoran memori, symlink loop, atau memang sesuatu yang salah aplikasi PHP lakukan.

Saya tidak percaya ada. Saya akan mencari direktori dengan jumlah entri yang sangat besar atau struktur direktori yang sangat dalam yang dicari atau dilalui.

Kode aplikasi PHP dan juga semua file aset dipasang melalui sistem file jaringan GlusterFS, bisakah itu ada hubungannya dengan itu?

Jelas itu bisa menjadi masalah sistem file. Bug filesystem yang menyebabkan gigi palsu tidak akan dirilis, misalnya, adalah suatu kemungkinan.

Solusi yang Dikonfirmasi

Untuk siapa saja yang mungkin mengalami masalah yang sama. Orang-orang pusat data akhirnya menemukan jawabannya hari ini. Pelakunya adalah perpustakaan NSS (Network Security Services) yang dibundel dengan Libcurl. Upgrade ke versi terbaru memecahkan masalah.

Laporan bug yang menjelaskan detailnya ada di sini:

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

Rupanya, untuk menentukan apakah beberapa jalur adalah lokal atau pada drive jaringan, NSS mencari file yang tidak ada dan mengukur waktu yang dibutuhkan sistem file untuk melaporkan kembali! Jika Anda memiliki cukup banyak permintaan Curl dan memori yang cukup, semua permintaan ini di-cache dan ditumpuk.

Saya mengalami masalah ini, dan sementara Wolfgang benar tentang penyebabnya, ada beberapa detail penting yang hilang.

• Masalah ini memengaruhi permintaan SSL yang dilakukan dengan curl atau libcurl, atau perangkat lunak lain apa pun yang menggunakan mozilla NSS untuk koneksi aman. Permintaan yang tidak aman tidak memicu masalah.

• Masalahnya tidak memerlukan permintaan ikal bersamaan. Akumulasi dentry akan terjadi selama panggilan curl cukup sering untuk melampaui upaya OS untuk mendapatkan kembali RAM.

• versi NSS yang lebih baru, 3.16.0, tidak menyertakan perbaikan untuk ini. namun, Anda tidak mendapatkan perbaikan secara gratis dengan memutakhirkan NSS, dan Anda tidak harus memutakhirkan semua NSS. Anda hanya perlu memutakhirkan nss-softokn (yang memiliki ketergantungan yang diperlukan pada nss-utils) minimal. dan untuk mendapatkan manfaatnya, Anda perlu mengatur variabel lingkungan NSS_SDB_USE_CACHE untuk proses yang menggunakan libcurl. kehadiran variabel lingkungan itulah yang memungkinkan pemeriksaan file yang tidak ada yang mahal dilewati.

FWIW, saya menulis entri blog dengan sedikit lebih banyak latar belakang / detail, kalau-kalau ada yang membutuhkannya.

Lihat 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

Sudah ada angka yang menunjukkan bahwa Anda dapat mengharapkan memori dentry yang terlihat kembali saat vfs_cache_pressure diatur lebih tinggi dari 100. Jadi 125 bisa terlalu rendah untuk itu terjadi dalam kasus Anda.

Bukan penjelasan untuk jawaban Anda, tetapi sebagai pengguna sistem ini informasi yang Anda berikan:

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

Cukup untuk memberi tahu saya bahwa ini bukan masalah Anda dan merupakan tanggung jawab sysadmin untuk memberikan penjelasan yang memadai.

Saya tidak ingin terdengar kasar di sini tetapi;

• Anda tidak memiliki informasi spesifik tentang peran tuan rumah ini.
• Bagaimana tuan rumah memprioritaskan sumber daya berada di luar jangkauan Anda.
• Anda tidak terbiasa, atau memiliki bagian dalam desain dan penyebaran penyimpanan di host ini.
• Anda tidak dapat menawarkan output sistem tertentu karena Anda bukan root.

Merupakan tanggung jawab sysadmin Anda untuk membenarkan atau menyelesaikan anomali alokasi slab. Entah Anda belum memberi kami gambaran lengkap dari keseluruhan saga yang mengarahkan Anda ke hal ini (yang sejujurnya saya tidak tertarik) atau sysadmin Anda berperilaku tidak bertanggung jawab dan / atau tidak kompeten dalam cara dia mempertimbangkan menangani masalah ini.

Jangan ragu untuk memberitahunya beberapa orang asing acak di internet berpikir dia tidak menganggap serius tanggung jawabnya.