Problem
Maszyna CentOS z jądrem 2.6.32 i fizyczną pamięcią RAM 128 GB miała kilka dni temu kłopoty. Odpowiedzialny administrator systemu powiedział mi, że aplikacja PHP-FPM nie reaguje na żądania w odpowiednim czasie z powodu zamiany, a widząc, freeże prawie nie zostało już pamięci, postanowił zrestartować komputer.
Wiem, że wolna pamięć może być mylącą koncepcją w systemie Linux, a ponowne uruchomienie może być niewłaściwą rzeczą. Jednak wspomniany administrator obwinia aplikację PHP (za którą jestem odpowiedzialny) i odmawia dalszego zbadania.
To, czego mogłem się dowiedzieć, to:
- Przed ponownym uruchomieniem wolna pamięć (w tym bufory i pamięć podręczna) wynosiła zaledwie kilkaset MB.
- Przed ponownym uruchomieniem
/proc/meminfozgłoszono użycie pamięci Slab na poziomie około 90 GB (tak, GB). - Po ponownym uruchomieniu wolna pamięć wynosiła 119 GB, aw ciągu godziny spadła do około 100 GB, ponieważ pracownicy PHP-FPM (około 600) wracali do życia, każdy z nich miał od 30 do 40 MB w Kolumna RES na górze (która jest taka od miesięcy i jest całkowicie rozsądna, biorąc pod uwagę charakter aplikacji PHP). Na liście procesów nie ma nic, co zużyłoby nietypową lub godną uwagi ilość pamięci RAM.
- Po ponownym uruchomieniu pamięć płyty wynosiła około 300 MB
Jeśli do tej pory monitorowałem system, a przede wszystkim pamięć Slab rośnie w linii prostej z szybkością około 5 GB dziennie. Wolna pamięć zgłaszana przez freei /proc/meminfomaleje z tą samą szybkością. Płyta ma obecnie 46 GB. Według slabtopwiększości jest on używany do dentrywpisów:
Wolna pamięć:
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
Płyta:
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
Ciśnienie pamięci podręcznej VFS:
cat /proc/sys/vm/vfs_cache_pressure
125
Swappiness:
cat /proc/sys/vm/swappiness
0
Wiem, że nieużywana pamięć to zmarnowana pamięć, więc niekoniecznie musi to być zła rzecz (zwłaszcza biorąc pod uwagę, że 44 GB jest pokazywane jako SReclaimable). Najwyraźniej jednak maszyna napotkała problemy i obawiam się, że to samo wydarzy się za kilka dni, kiedy płyta przekroczy 90 GB.
pytania
Mam te pytania:
- Czy mam rację sądząc, że pamięć Slab jest zawsze fizyczną pamięcią RAM, a liczba jest już odejmowana od wartości MemFree?
- Czy tak duża liczba wpisów dentystycznych jest normalna? Aplikacja PHP ma dostęp do około 1,5 mln plików, jednak większość z nich to archiwa i nie ma do nich dostępu w przypadku zwykłego ruchu w sieci.
- Co może być wyjaśnieniem faktu, że liczba buforowanych i-węzłów jest znacznie niższa niż liczba buforowanych pamięci podręcznych, czy nie powinny być one w jakiś sposób powiązane?
- Jeśli w systemie wystąpią problemy z pamięcią, to czy jądro nie powinno automatycznie uwolnić niektórych z nich? Co może być przyczyną, że tak się nie dzieje?
- Czy jest jakiś sposób, aby „zajrzeć” do pamięci podręcznej dentysty, aby zobaczyć, co to za pamięć (tj. Jakie ścieżki są buforowane)? Być może wskazuje to na jakiś wyciek pamięci, pętlę dowiązań symbolicznych lub coś, co aplikacja PHP robi źle.
- Kod aplikacji PHP oraz wszystkie pliki zasobów są montowane za pośrednictwem sieciowego systemu plików GlusterFS. Czy to może mieć coś z tym wspólnego?
Należy pamiętać, że nie mogę badać jako root, tylko jako zwykły użytkownik i że administrator odmawia pomocy. Nie uruchomi nawet typowego echo 2 > /proc/sys/vm/drop_cachestestu, aby sprawdzić, czy pamięć płyty rzeczywiście można odzyskać.
Docenione zostaną wszelkie spostrzeżenia na temat tego, co się dzieje i tego, w jaki sposób mogę to zbadać.
Aktualizacje
Kilka dalszych informacji diagnostycznych:
Wierzchowce:
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
Informacje o montażu:
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
Konfiguracja 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
cat /proc/self/mountsi (być może dość długi)cat /proc/self/mountinfo.cat /etc/nfsmount.conf. Czy masz również katalogi zawierające wiele plików w jego bezpośrednim katalogu?Odpowiedzi:
Tak.
Tak, jeśli system nie jest pod presją pamięci. Musi do czegoś użyć pamięci i możliwe jest, że w twoim określonym schemacie użytkowania jest to najlepszy sposób na wykorzystanie tej pamięci.
Wiele operacji katalogowych byłoby najbardziej prawdopodobnym wyjaśnieniem.
Powinien i nie mogę wymyślić żadnego powodu, dla którego by tego nie zrobił. Nie jestem przekonany, że to właśnie poszło nie tak. Zdecydowanie sugeruję dalszą aktualizację jądra lub zwiększenie vfs_cache_pressure.
Nie wierzę, że tak jest. Szukałbym wszelkich katalogów z absurdalnie dużą liczbą pozycji lub bardzo głębokimi strukturami katalogów, które są przeszukiwane lub przeglądane.
Zdecydowanie może to być problem z systemem plików. Możliwy jest na przykład błąd systemu plików, który powoduje, że dyski nie są uwalniane.
źródło
Potwierdzone rozwiązanie
Do każdego, kto może napotkać ten sam problem. Faceci z centrów danych w końcu się zorientowali. Winowajcą była biblioteka NSS (Network Security Services) dołączona do Libcurl. Aktualizacja do najnowszej wersji rozwiązała problem.
Raport o błędzie opisujący szczegóły znajduje się tutaj:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1044666
Najwyraźniej, aby ustalić, czy dana ścieżka jest lokalna, czy na dysku sieciowym, NSS szukał nieistniejącego pliku i mierzył czas, jaki upłynął, zanim system plików się zgłosił! Jeśli masz wystarczająco dużą liczbę żądań Curl i wystarczającą ilość pamięci, wszystkie te żądania są buforowane i zestawiane.
źródło
Natrafiłem na ten konkretny problem i chociaż Wolfgang ma rację co do przyczyny, brakuje pewnych ważnych szczegółów.
Ten problem wpływa na żądania SSL wykonane przy użyciu curl lub libcurl lub dowolnego innego oprogramowania używającego Mozilla NSS do bezpiecznego połączenia. Niezabezpieczone żądania nie wyzwalają problemu.
Problem nie wymaga równoczesnych żądań zwijania. Nagromadzenie uzębienia nastąpi, dopóki wywołania zwijania są wystarczająco częste, aby wyprzedzić wysiłki systemu operacyjnego mające na celu odzyskanie pamięci RAM.
nowsza wersja NSS, 3.16.0, zawiera naprawę tego. jednak nie otrzymujesz poprawki za darmo, aktualizując NSS i nie musisz aktualizować całego NSS. musisz tylko zaktualizować nss-softokn (który ma wymaganą zależność od nss-utils) co najmniej. Aby uzyskać korzyści, należy ustawić zmienną środowiskową NSS_SDB_USE_CACHE dla procesu używającego libcurl. obecność tej zmiennej środowiskowej pozwala pominąć kosztowne nieistniejące kontrole plików.
FWIW, napisałem wpis na blogu z nieco większą ilością tła / szczegółów, na wypadek, gdyby ktoś tego potrzebował.
źródło
nss-softokenRPM ORAZ ustawićNSS_SDB_USE_CACHE=YESenv var, aby curl połączenia https przestały zalewać pamięć podręczną dentysty.Zobacz 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
Istnieją liczby wskazujące, że można spodziewać się zauważalnego odzyskania pamięci dentystycznej, gdy vfs_cache_pressure jest ustawiony na wartość wyższą niż 100. Zatem 125 może być zbyt niskie, aby mogło się to zdarzyć w twoim przypadku.
źródło
vfs_cache_pressurepowyżej100ma sens tylko wtedy, gdy nie masz wystarczającej ilości pamięci RAM do obciążenia. W takim przypadku wartość o wartości powyżej 100 (np. 10000) zwolni część pamięci RAM. To jednak spowoduje gorsze IO.Nie tak naprawdę wyjaśnienie twojej odpowiedzi, ale jako użytkownik tego systemu podałeś następujące informacje:
Wystarczy mi powiedzieć, że to nie jest twój problem, a sysadmin odpowiada za odpowiednie wyjaśnienie.
Nie chcę tu brzmieć niegrzecznie, ale;
Twoim obowiązkiem sysadmin jest uzasadnienie lub usunięcie anomalii przydziału płyt. Albo nie dałeś nam pełnego obrazu całej sagi, która doprowadziła cię do tego (do czego szczerze nie jestem zainteresowany), albo twój sysadmin zachowuje się w sposób nieodpowiedzialny i / lub niekompetentny w sposobie, w jaki rozważa poradzenie sobie z tym problemem.
Powiedz mu, że jakiś przypadkowy nieznajomy w Internecie myśli, że nie bierze poważnie swoich obowiązków.
źródło