Ungewöhnlich hohe Cache-Auslastung

Problem

Ein CentOS-Rechner mit Kernel 2.6.32 und 128 GB physischem RAM hatte vor einigen Tagen Probleme. Der zuständige Systemadministrator teilt mir mit, dass die PHP-FPM-Anwendung aufgrund des Austauschs nicht mehr rechtzeitig auf Anforderungen reagiert hat. Da freefast kein Speicher mehr vorhanden ist, hat er den Computer neu gestartet.

Ich weiß, dass freier Speicher unter Linux ein verwirrendes Konzept sein kann und ein Neustart möglicherweise die falsche Vorgehensweise war. Der erwähnte Administrator beschuldigt jedoch die PHP-Anwendung (für die ich verantwortlich bin) und lehnt es ab, weitere Nachforschungen anzustellen.

Was ich alleine herausfinden konnte, ist Folgendes:

• Vor dem Neustart betrug der freie Speicher (inkl. Puffer und Cache) nur einige hundert MB.
• Vor dem Neustart wurde /proc/meminfoeine Slab-Speichernutzung von ca. 90 GB (ja, GB) gemeldet.
• Nach dem Neustart betrug der freie Arbeitsspeicher 119 GB und ging innerhalb einer Stunde auf etwa 100 GB zurück, als die PHP-FPM-Mitarbeiter (etwa 600 von ihnen) wieder zum Leben erweckten RES-Spalte oben (das ist seit Monaten so und angesichts der Art der PHP-Anwendung durchaus sinnvoll). In der Prozessliste gibt es nichts anderes, das ungewöhnlich viel oder nennenswert viel RAM verbraucht.
• Nach dem Neustart betrug der Slab-Speicher ca. 300 MB

Seitdem wird das System überwacht, und vor allem der Slab-Speicher nimmt geradlinig mit einer Rate von etwa 5 GB pro Tag zu. Freier Speicher, wie von gemeldet, freeund /proc/meminfoverringert sich mit der gleichen Rate. Slab ist derzeit bei 46 GB. Laut den slabtopmeisten wird es für dentryEinträge verwendet:

Freier Speicher:

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  

VFS-Cache-Druck:

cat /proc/sys/vm/vfs_cache_pressure
125

Swappiness:

cat /proc/sys/vm/swappiness
0

Ich weiß, dass ungenutzter Speicher verschwendet wird, daher sollte dies nicht unbedingt eine schlechte Sache sein (vor allem, wenn 44 GB als SReclaimable angezeigt werden). Anscheinend hatte die Maschine dennoch Probleme, und ich befürchte, dass dies in ein paar Tagen wieder vorkommen wird, wenn Slab 90 GB überschreitet.

Fragen

Ich habe folgende Fragen:

• Stimmt es, dass der Slab-Speicher immer physischer RAM ist und die Zahl bereits vom MemFree-Wert abgezogen wurde?
• Ist eine so hohe Anzahl von Einträgen normal? Die PHP-Anwendung hat Zugriff auf ca. 1,5 Mio. Dateien, die meisten davon sind jedoch Archive und werden für den regulären Web-Verkehr überhaupt nicht verwendet.
• Was könnte eine Erklärung dafür sein, dass die Anzahl der zwischengespeicherten Inodes viel geringer ist als die Anzahl der zwischengespeicherten Einträge, sollten sie nicht in irgendeiner Beziehung zueinander stehen?
• Sollte der Kernel einige der Einträge nicht automatisch freigeben, wenn das System Probleme mit dem Arbeitsspeicher hat? Was könnte ein Grund dafür sein, dass dies nicht geschieht?
• Gibt es eine Möglichkeit, in den Dentry-Cache zu "schauen", um zu sehen, was dieser gesamte Speicher ist (dh welche Pfade werden zwischengespeichert)? Vielleicht deutet dies auf eine Art Speicherverlust, eine Symlink-Schleife oder auf etwas hin, was die PHP-Anwendung falsch macht.
• Der PHP-Anwendungscode sowie alle Asset-Dateien werden über das GlusterFS-Netzwerkdateisystem gemountet. Kann das etwas damit zu tun haben?

Bitte beachten Sie, dass ich nicht als Root, sondern nur als regulärer Benutzer ermitteln kann und der Administrator die Hilfe ablehnt. Er wird nicht einmal den typischen echo 2 > /proc/sys/vm/drop_cachesTest durchführen, um festzustellen, ob der Slab-Speicher tatsächlich wiedergewonnen werden kann.

Einsichten darüber, was los sein könnte und wie ich weitere Nachforschungen anstellen kann, wären sehr willkommen.

Aktualisierung

Einige weitere diagnostische Informationen:

Reittiere:

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

Mount info:

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-Konfiguration:

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

Stimmt es, dass der Slab-Speicher immer physischer RAM ist und die Zahl bereits vom MemFree-Wert abgezogen wurde?

Ja.

Ist eine so hohe Anzahl von Einträgen normal? Die PHP-Anwendung hat Zugriff auf ca. 1,5 Mio. Dateien, die meisten davon sind jedoch Archive und werden für den regulären Web-Verkehr überhaupt nicht verwendet.

Ja, wenn das System nicht unter Speicherdruck steht. Der Speicher muss für etwas verwendet werden, und es ist möglich, dass dies in Ihrem speziellen Verwendungsmuster der beste Weg ist, diesen Speicher zu verwenden.

Was könnte eine Erklärung dafür sein, dass die Anzahl der zwischengespeicherten Inodes viel geringer ist als die Anzahl der zwischengespeicherten Einträge, sollten sie nicht in irgendeiner Beziehung zueinander stehen?

Viele Verzeichnisoperationen wären die wahrscheinlichste Erklärung.

Sollte der Kernel einige der Einträge nicht automatisch freigeben, wenn das System Probleme mit dem Arbeitsspeicher hat? Was könnte ein Grund dafür sein, dass dies nicht geschieht?

Es sollte, und ich kann mir keinen Grund vorstellen, warum es nicht so wäre. Ich bin nicht davon überzeugt, dass dies tatsächlich schief gelaufen ist. Ich würde dringend empfehlen, Ihren Kernel zu aktualisieren oder vfs_cache_pressure weiter zu erhöhen.

Gibt es eine Möglichkeit, in den Dentry-Cache zu "schauen", um zu sehen, was dieser gesamte Speicher ist (dh welche Pfade werden zwischengespeichert)? Vielleicht deutet dies auf eine Art Speicherverlust, eine Symlink-Schleife oder auf etwas hin, was die PHP-Anwendung falsch macht.

Ich glaube nicht, dass es das gibt. Ich würde nach Verzeichnissen mit einer absurd großen Anzahl von Einträgen oder sehr tiefen Verzeichnisstrukturen suchen, die durchsucht oder durchlaufen werden.

Der PHP-Anwendungscode sowie alle Asset-Dateien werden über das GlusterFS-Netzwerkdateisystem gemountet. Kann das etwas damit zu tun haben?

Auf jeden Fall könnte es sich um ein Dateisystemproblem handeln. Beispielsweise ist ein Dateisystemfehler möglich, der dazu führt, dass Einträge nicht freigegeben werden.

Bestätigte Lösung

An alle, die möglicherweise auf dasselbe Problem stoßen. Die Leute vom Rechenzentrum haben es heute endlich herausgefunden. Schuld daran war eine mit Libcurl gebündelte NSS-Bibliothek (Network Security Services). Ein Upgrade auf die neueste Version löste das Problem.

Ein Fehlerbericht, der die Details beschreibt, ist hier:

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

Anscheinend hat NSS, um festzustellen, ob ein Pfad lokal ist oder sich auf einem Netzlaufwerk befindet, eine nicht vorhandene Datei gesucht und die Zeit gemessen, die das Dateisystem für die Rückmeldung benötigte! Wenn Sie eine ausreichende Anzahl von Curl-Anforderungen und genügend Arbeitsspeicher haben, werden diese Anforderungen alle zwischengespeichert und gestapelt.

Ich bin auf genau dieses Problem gestoßen, und obwohl Wolfgang bezüglich der Ursache recht hat, fehlen einige wichtige Details.

• Dieses Problem wirkt sich auf SSL-Anforderungen aus, die mit curl oder libcurl oder einer anderen Software ausgeführt werden, die Mozilla NSS für die sichere Verbindung verwendet. Nicht sichere Anforderungen lösen das Problem nicht aus.

• Das Problem erfordert keine gleichzeitigen Curl-Anforderungen. Die Ansammlung von Einträgen erfolgt so lange, wie die Curl-Aufrufe häufig genug sind, um die Bemühungen des Betriebssystems zur Wiederherstellung des Arbeitsspeichers zu übertreffen.

• Die neuere Version von NSS, 3.16.0, enthält eine Korrektur für dieses Problem. Durch ein Upgrade von NSS erhalten Sie jedoch keine kostenlose Lösung, und Sie müssen nicht das gesamte NSS aktualisieren. Sie müssen nur ein Upgrade von nss-softokn (das eine erforderliche Abhängigkeit von nss-utils aufweist) durchführen. und um den Vorteil zu nutzen, müssen Sie die Umgebungsvariable NSS_SDB_USE_CACHE für den Prozess festlegen, der libcurl verwendet. Durch das Vorhandensein dieser Umgebungsvariablen können die kostspieligen nicht vorhandenen Dateiprüfungen übersprungen werden.

FWIW, ich habe einen Blogeintrag mit ein bisschen mehr Hintergrund / Details geschrieben, falls jemand es braucht.

Siehe 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

Es gibt Zahlen, die darauf hinweisen, dass Sie mit einer spürbaren Speicherfreigabe für Einträge rechnen können, wenn vfs_cache_pressure auf einen Wert höher als 100 eingestellt ist. 125 kann daher zu niedrig sein, als dass dies in Ihrem Fall der Fall wäre.

Keine wirkliche Erklärung für Ihre Antwort, aber als Benutzer dieses Systems haben Sie die folgenden Informationen bereitgestellt:

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

Es reicht aus, mir zu sagen, dass dies nicht Ihr Problem ist und es in der Verantwortung des Systemadministrators liegt, eine angemessene Erklärung zu liefern.

Ich möchte hier nicht unhöflich klingen, aber;

• Ihnen fehlen spezifische Informationen zur Rolle dieses Hosts.
• Wie der Host Ressourcen priorisieren soll, liegt nicht in Ihrem Bereich.
• Sie sind mit dem Entwurf und der Bereitstellung des Speichers auf diesem Host nicht vertraut oder hatten keinerlei Einfluss.
• Sie können bestimmte Systemausgaben nicht anbieten, da Sie kein Root sind.

Es liegt in der Verantwortung Ihres Systemadministrators , die Anomalie der Plattenzuordnung zu rechtfertigen oder zu beheben. Entweder haben Sie uns kein vollständiges Bild der gesamten Saga gegeben, die Sie bis dahin geführt hat (was mich ehrlich gesagt nicht interessiert), oder Ihr Sysadmin verhält sich verantwortungslos und / oder inkompetent in der Art und Weise, wie er dieses Problem behandelt.

Zögern Sie nicht, ihm mitzuteilen, dass ein zufälliger Fremder im Internet denkt, dass er seine Verantwortung nicht ernst nimmt.