Необычно высокое использование кэша Dentry

Проблема

Несколько дней назад машина CentOS с ядром 2.6.32 и 128 ГБ физической памяти столкнулась с проблемами. Ответственный системный администратор сообщил мне, что приложение PHP-FPM больше не отвечало на запросы своевременно из-за подкачки, и, увидев в free что памяти почти не осталось, он решил перезагрузить машину.

Я знаю, что свободная память может сбивать с толку в Linux, и, возможно, перезагрузка была неправильным решением. Однако упомянутый администратор винит приложение PHP (за которое я отвечаю) и отказывается от дальнейшего расследования.

Что я смог выяснить самостоятельно, так это следующее:

До перезапуска свободной памяти (включая буферы и кеш) было всего пару сотен МБ.
Перед перезапуском /proc/meminfo сообщил об использовании памяти Slab около 90 ГБ (да, ГБ).
После перезапуска объем свободной памяти составлял 119 ГБ, а в течение часа она уменьшилась примерно до 100 ГБ, поскольку рабочие PHP-FPM (около 600 из них) возвращались к жизни, каждый из которых показывал от 30 до 40 МБ в Столбец RES вверху (так было в течение нескольких месяцев и вполне разумно, учитывая характер приложения PHP). В списке процессов нет ничего, что потребляло бы необычный или примечательный объем ОЗУ.
После перезагрузки память Slab составила около 300 МБ.

С тех пор он следил за системой, и в первую очередь память Slab увеличивается по прямой со скоростью около 5 ГБ в день. Свободная память, как сообщает free и /proc/meminfo уменьшается с той же скоростью. Slab в настоящее время занимает 46 ГБ. В соответствии с 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

Замена:

cat /proc/sys/vm/swappiness
0

Я знаю, что неиспользуемая память - это потраченная впустую память, поэтому это не обязательно должно быть плохо (особенно с учетом того, что 44 ГБ показаны как SReclaimable). Тем не менее, очевидно, что у машины все же возникли проблемы, и я боюсь, что то же самое произойдет снова через несколько дней, когда Slab превысит 90 ГБ.

Вопросы

У меня такие вопросы:

Правильно ли я полагаю, что память Slab - это всегда физическая оперативная память, и число уже вычтено из значения MemFree?
Нормально ли такое большое количество зубных вторжений? Приложение PHP имеет доступ примерно к 1,5 M файлам, однако большинство из них являются архивами и вообще не доступны для обычного веб-трафика.
Чем может быть объяснение того факта, что количество кэшированных inodes намного меньше, чем количество кешированных dentries, если они не связаны каким-то образом?
Если в системе возникнут проблемы с памятью, не должно ли ядро автоматически освободить некоторые данные? Что может быть причиной того, что этого не происходит?
Есть ли способ «заглянуть» в кеш-память dentry, чтобы узнать, что это за память (то есть какие пути кэшируются)? Возможно, это указывает на какую-то утечку памяти, цикл символических ссылок или действительно на что-то, что приложение PHP делает неправильно.
Код приложения PHP, а также все файлы ресурсов монтируются через сетевую файловую систему GlusterFS, может ли это иметь какое-то отношение к этому?

Имейте в виду, что я не могу работать с правами root, только как обычный пользователь, и что администратор отказывается помочь. Он даже не будет запускать типичный echo 2 > /proc/sys/vm/drop_caches проверьте, действительно ли память 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

Информация о монтировании:

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

Подтвержденное решение

Всем, кто может столкнуться с той же проблемой. Сегодня ребята из дата-центра наконец-то разобрались с этим. Виновником была библиотека NSS (Network Security Services), связанная с Libcurl. Обновление до последней версии решило проблему.

Отчет об ошибке с подробным описанием находится здесь:

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

Очевидно, чтобы определить, является ли какой-то путь локальным или на сетевом диске, NSS искал несуществующий файл и измерял время, необходимое файловой системе, чтобы отчитаться! Если у вас достаточно большое количество запросов Curl и достаточно памяти, все эти запросы кэшируются и складываются.

Я столкнулся именно с этой проблемой, и хотя Вольфганг прав в отношении причины, некоторые важные детали отсутствуют.

Эта проблема влияет на запросы SSL, выполняемые с помощью curl или libcurl, или любого другого программного обеспечения, которое использует Mozilla NSS для безопасного соединения. Незащищенные запросы не вызывают проблемы.
Проблема не требует одновременных запросов curl. Накопление dentry будет происходить до тех пор, пока вызовы curl будут достаточно частыми, чтобы опередить усилия ОС по освобождению RAM.
более новая версия NSS, 3.16.0, включает исправление для этого. однако вы не получите исправление бесплатно, обновив NSS, и вам не нужно обновлять все NSS. вам нужно только обновить как минимум nss-softokn (который имеет обязательную зависимость от nss-utils). и чтобы получить преимущество, вам необходимо установить переменную среды NSS_SDB_USE_CACHE для процесса, использующего libcurl. наличие этой переменной среды позволяет пропустить дорогостоящие проверки несуществующих файлов.

FWIW, я написал запись в блоге немного больше фона / деталей, на случай, если кому-то это понадобится.

Правильно ли я полагаю, что память Slab - это всегда физическая оперативная память, и число уже вычтено из значения MemFree?

Да.

Нормально ли такое большое количество зубных вторжений? Приложение PHP имеет доступ примерно к 1,5 M файлам, однако большинство из них являются архивами и вообще не доступны для обычного веб-трафика.

Да, если система не испытывает нехватки памяти. Он должен использовать память для чего-то, и возможно, что в вашей конкретной схеме использования это лучший способ использовать эту память.

Чем может быть объяснение того факта, что количество кэшированных inodes намного меньше, чем количество кешированных dentries, если они не связаны каким-то образом?

Наиболее вероятным объяснением было бы множество операций с каталогами.

Если в системе возникнут проблемы с памятью, не должно ли ядро автоматически освободить некоторые данные? Что может быть причиной того, что этого не происходит?

Должно быть, и я не могу придумать ни одной причины, по которой это не так. Я не уверен, что именно это пошло не так. Я настоятельно рекомендую обновить ваше ядро или дополнительно увеличить vfs_cache_pressure.

Есть ли способ «заглянуть» в кеш-память dentry, чтобы узнать, что это за память (то есть какие пути кэшируются)? Возможно, это указывает на какую-то утечку памяти, цикл символических ссылок или действительно на что-то, что приложение PHP делает неправильно.

Я не верю, что есть. Я бы стал искать любые каталоги с абсурдно большим количеством записей или очень глубокими структурами каталогов, по которым осуществляется поиск или обход.

Код приложения PHP, а также все файлы ресурсов монтируются через сетевую файловую систему GlusterFS, может ли это иметь какое-то отношение к этому?

Определенно это может быть проблема с файловой системой. Возможна, например, ошибка файловой системы, из-за которой dentries не выпускается.

Видеть 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

Есть числа, показывающие, что вы можете ожидать некоторого заметного восстановления памяти Dentry, когда vfs_cache_pressure установлен намного выше 100. Таким образом, 125 может быть слишком низким, чтобы это произошло в вашем случае.

Это не совсем объяснение вашего ответа, но как пользователь этой системы вы предоставили эту информацию:

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

Достаточно сказать мне, что это не твоя проблема а системный администратор обязан предоставить адекватное объяснение.

Я не хочу показаться здесь грубым, но;

Вам не хватает конкретной информации о роли этого хоста.
То, как хост должен определять приоритеты ресурсов, выходит за рамки вашей компетенции.
Вы не знакомы или не принимали участия в проектировании и развертывании хранилища на этом хосте.
Вы не можете предложить определенный вывод системы, так как вы не root.

Это твое ответственность системных администраторов для обоснования или устранения аномалии размещения плит. Либо вы не предоставили нам полную картину всей саги, которая привела вас к этому (что, честно говоря, меня не интересует), либо ваш системный администратор ведет себя безответственно и / или некомпетентно так, как он думает о решении этой проблемы.

Не стесняйтесь сказать ему, что какой-нибудь случайный незнакомец в Интернете думает, что он не относится к своим обязанностям серьезно.