[Megoldva]Mi és miért eszi a swap-ot?

Debian GNU/Linux

Van egy masina, ami időnként veszettül elkezdi tölteni a swap-ot, és persze olyankor eléggé megcsigul. Fut rajta egy mysq szerver, amit elvileg már bekalapáltam úgy a memóriába, hogy azt nem lehet swap-ba lökni, és elvileg még bőven van helye a hugepages-ben memóriát foglalni: 

# grep -i Hugepa /proc/meminfo 
HugePages_Total:    2058
HugePages_Free:      695
HugePages_Rsvd:      395
HugePages_Surp:        0
Hugepagesize:       2048 kB

# cat  /proc/$(cat /var/run/mysqld/mysqld.pid)/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             unlimited            unlimited            processes 
Max open files            1024                 1024                 files     
Max locked memory         unlimited            unlimited            bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       16382                16382                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

Elég sok találatot kaptam a google-ben arra nézve, hogy a linux kernel (vmm) szereti kidobálni a memóriából a mysql-t. Viszont úgy néz ki, hogy annak ellenére, hogy elvileg a mysql-t már nem tudja kilökdösni, valamit mégis akar. 13:30 után bololndult meg, kikapcsoltam a swap-ot, azért esett le 0-ra. A szabad memória 3G körül volt, és mégis tolta a swap-ot mint az őrült: 

# atsar -rs 12:00

Linux  dantooine  2.6.32-bpo.5-openvz-amd64  #1 SMP Mon Jan 17 19:39:07 UTC 2011  x86_64  08/12/2011

12:00:01  memtot memfree buffers   cached  slabmem      swptot swpfree  _mem_
12:10:01   7991M   1443M    192M    1158M     130M       1903M   1491M
12:20:01   7991M   1425M    194M    1171M     130M       1903M   1491M
12:30:01   7991M   1422M    194M    1174M     131M       1903M   1492M
12:40:01   7991M   1415M    195M    1176M     131M       1903M   1492M
12:50:01   7991M   1401M    196M    1178M     131M       1903M   1492M
13:00:01   7991M   1386M    196M    1181M     131M       1903M   1492M
13:10:01   7991M   1372M    196M    1184M     131M       1903M   1492M
13:20:01   7991M   1364M    197M    1198M     131M       1903M   1493M
13:30:01   7991M   1361M    197M    1200M     131M       1903M   1493M
13:40:14   7991M   3309M     14M      38M     117M       1903M    788M
13:50:01   7991M   2887M     18M      85M      72M        410M      0M
14:00:01   7991M   2350M     41M     230M      79M          0M      0M
14:10:01   7991M   2160M     60M     373M      79M          0M      0M

Az első gondom az az, hogy nem tudom, hogy miért teszi ezt. Látszik, hogy mielőtt megvadult volna, bő 1G memória szabadon volt (+az fs cache és buffers, slab), és elvileg semmi olyan alkalmazás nem fut a gépen, ami ennyit akarhatott volna allokálni.

A második gondom az, hogy oké, valamiért csinálja, de mit dobál ki? A top nem sokat segít, a SWAP oszlopban még most is a mysql vezet 3.9G-val, pedig ki van kapcsolva a swap terület, ezért vannak fenntartásaim ezzel kapcsolatban. 

/proc/sys/vm/block_dump: 0
/proc/sys/vm/dirty_background_bytes: 0
/proc/sys/vm/dirty_background_ratio: 10
/proc/sys/vm/dirty_bytes: 0
/proc/sys/vm/dirty_expire_centisecs: 3000
/proc/sys/vm/dirty_ratio: 20
/proc/sys/vm/dirty_writeback_centisecs: 500
/proc/sys/vm/drop_caches: 0
/proc/sys/vm/hugepages_treat_as_movable: 0
/proc/sys/vm/hugetlb_shm_group: 107
/proc/sys/vm/laptop_mode: 0
/proc/sys/vm/legacy_va_layout: 0
/proc/sys/vm/lowmem_reserve_ratio: 256  256     32
/proc/sys/vm/max_map_count: 65530
/proc/sys/vm/memory_failure_early_kill: 0
/proc/sys/vm/memory_failure_recovery: 1
/proc/sys/vm/min_free_kbytes: 11487
/proc/sys/vm/min_slab_ratio: 5
/proc/sys/vm/min_unmapped_ratio: 1
/proc/sys/vm/mmap_min_addr: 65536
/proc/sys/vm/nr_hugepages: 2058
/proc/sys/vm/nr_overcommit_hugepages: 0
/proc/sys/vm/nr_pdflush_threads: 0
/proc/sys/vm/numa_zonelist_order: default
/proc/sys/vm/odirect_enable: 0
/proc/sys/vm/oom_dump_tasks: 0
/proc/sys/vm/oom_kill_allocating_task: 0
/proc/sys/vm/overcommit_memory: 0
/proc/sys/vm/overcommit_ratio: 50
/proc/sys/vm/page-cluster: 3
/proc/sys/vm/panic_on_oom: 0
/proc/sys/vm/percpu_pagelist_fraction: 0
/proc/sys/vm/scan_unevictable_pages: 0
/proc/sys/vm/stat_interval: 1
/proc/sys/vm/swappiness: 0
/proc/sys/vm/vfs_cache_pressure: 100
/proc/sys/vm/vsyscall: 0
/proc/sys/vm/zone_reclaim_mode: 0

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x6c00ed3d 0          zabbix     666        877448     8                       
0x00000000 655361     mysql      600        14680064   1          dest         
0x00000000 688130     mysql      600        3672113152 1          dest         
0x6800eed9 720899     zabbix     666        8421519    25                      
0x7800eed9 753668     zabbix     666        16777627   25                      
0x7400eed9 786437     zabbix     666        4194702    25                      
0x6700eed9 819206     zabbix     666        7130317    25                      
0x7300eed9 851975     zabbix     666        1258291    25                      

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x7a00ed3d 131072     zabbix     666        7         
0x002fa327 163841     root       666        2         
0x00000000 196610     www-data   600        1         
0x7a00eed9 327683     zabbix     666        7         

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    

/proc/sys/kernel/shmall: 1310720
/proc/sys/kernel/shmmax: 4315938816
/proc/sys/kernel/shmmni: 4096

NUMA - ha jól értem - nem játszik, egy CPU van a gépben.

A gépen fut pár konténer, amik max memóriafoglalása se lenne elég ahhoz, hogy így elbánjon géppel.

Kifogytam az ötletekből, valaki?

( tovis v | 2011. 08. 12., p – 16:33 )

+subscribe

OFF: Ijedtemben belepillantottam a házi szerverem is használ swap -et! Nincs mysql van apache és samba no meg cups. Ja és vagy húsz torrent. Mindez 4G RAM -al. Jó lenne tudni, mi is kerül a swapbe.

* Én egy indián vagyok. Minden indián hazudik.

Ezért kár volna eret vágnod, valamennyi swap használat teljesen normális és előnyös is. A gond akkor van ha a kernel túl sokszor használja a swap területet (a si és so oszlopok a vmstat esetén). Ha azok az számok picik, mondjuk 10 alatt vannak, vagy jobbára 0 az értékük, akkor akár 100G swapot is megehet a gép anélkül, hogy lassulással kéne számolnod.

Én ezért nem adtam swapot a gépnek. Toljon csak mindent a memóriába és ha esetleg elfogyna (4G egyébként), akkor majd felcsatolom a swapfilet és békesség. Eddig 2,5 G fölé sosem ment még akkor se ha Eclipse - NetBeans ment egyszerre meg pár KDE alkalmazás XFCE alatt.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

van egy rossz hírem: ha elszabadul valami, akkor ha lenne swap, akkor azt vennéd észre, hogy ezerrel pörög a diszk, nagyon lassú a géped, és ugyan kurva lassan, de tudsz valami tenni az ügy érdekében (top, aztán kill -9). ha nincs swap, akkor egyszercsak megáll a géped, és lehet nyomni a reset gombot.

Személyes tapasztalatról beszéltem. Hogy miért nem jött neki össze, azt nem tudom, de azt igen, hogy jó pár dolog leállt a gépen, de azokat a processzeket, amiket kellett volna, azokat valahogy nem találta el (ill. 1-2 perc után az ember megunja és megkeresi a reset gombot).

Meglehet, ezért is kértem tanácsot.

Bővebben kifejtve: nem az a gondom, hogy swapol a gép, mert azt már korábban is leírtam, hogy az nem baj. A baj az, hogy bő 1G szabad ram és újabb bő 1G filecache mellett miért kezd el swapolni mint állat.

Az egyik lehetőség, hogy valamelyik alkalmazás ami a gépen fut, az próbál befoglalni 2G+ memóriát, bár az szerintem nem így néz ki.

A másik lehetőség a mysql + sok ram + nagy innodb buffer több esetben előfordult problémája, amire sokféle "megoldást" szültek (swapoff -a ; swapon -a, vagy ramdiskre swapolni), de belátható hogy egyik se életbiztosítás.

Plusz - mint írtam, és a fentiekből látszik is - magát a mysql-t betoltam egy olyan memóriaterületre, ami nem swapolódhat ki (elméletileg), ám valami miatt a gép mégis bebolondul néha.

Adalék lehet, hogy ráindítottam egy os + data mentést és egy mysqldump-ot is, hogy mind az fs cache mind a mysql terhelve legyen (közben futott a zabbix is, ami tekerte a db-t, bár ha a msqldump lockolt valamit, akkor az úgyis várni kényszerült), és nem bírtam megdönteni a gépet. Nappal viszont, normál terhelés mellett mégis beőrült, tehát a teszt rossz volt.

Leszedtem a gépről minden olyan futó szolgáltatást ami nélkül még tudunk élni, meglátom, hogy most mi lesz. Lehet, hogy tényleg kevés a memória, de az is lehet, hogy az OpenVZ miatt van halál, vagy valami más próbálja felfalni a memóriát.

Addig is szívesen veszek minden építő ötletet, de ha lehet hanyagoljuk a man mkswap szintű hozzászólásokat.

Végiggondolva az eseményeket ez egész esélyes lehet. Boot után a gép teljesen egészséges, nem lehet ledönteni, de pár nap után - addigra széttöredezik a memória? - gyakorlatilag egy könyvtárváltásba bele tud dőlni.

Viszont csak 2.6.32-ig találtam OpenVZ patch-et, addig amíg lépnek, marad a rambővítés, hátha segít valamennyire.

Illetve az, hogy nagyon gyorsan leköltözöm a konténerekkel a gépről.

Amúgy van valami egyértelmű jele a töredezett memóriának? Valami, amit lehet figyelni, pl. hogy mekkora a legnagyobb lefoglalható, egybefüggő memória?

A /proc/buddyinfo mutatja, hogy a szabad memória mennyire összefüggő.

Esetleg még a mysql temp table jut eszembe, amit már diszkre rak. Ha a tmpfs -t használja erre (pl. /tmp - ami a default), akkor az átmenetileg nagyobb ram+swap használatot okozhat és egy ritka select is triggerelheti.

A rambővítés biztos segíteni fog, ha a kernel kötött, mást nem tudsz tenni.

Esetleg hasznos lehet, hogy van egy ilyen plugin:

http://exchange.munin-monitoring.org/plugins/buddyinfo/details

Magyar fejlesztés, ehe.

Ezt átkalapáltam magamnak, hogy byte-okban rajzolgasson, mert nem tudok fejben számolni, így viszont szépen látszik, hogy miképpen fogy (egyelőre) és/vagy töredezik a memória (később?).

Momentán viszonylag egészségesnek tűnik.

Szerintem nem igazán hasznos a grafikon, mert túl gyorsan változhat a helyzet, a munin grafikon nem elég nagy felbontású ehhez (időben) és az sem látszik rajta, hogy milyen allokációs igények érkeztek.

Ha meg akarsz bizonyosodni arról, hogy egy high order allocation indítja be a swappelést, akkor SystemTap-hoz kell nyúlni, hacsak nem elégedsz meg a kizárásos bizonyítással. A VM alrendszerben van pár hasznos trace a SystemTap-hoz.

Valóban, a rajzból elég kevés látszik akkor, amikor tényleg halál van. Most viszont jól látszik, hogy bő 2 nap uptime után a szabad memória fele 4k-s, másik fele meg 8k-s vagy nagyobb darabokban van, a foglalások viszont jobbára a 8k-s darabokból történnek és teret nyer a sok 4k-s darab. Gyanítom, hogy amint elfogynak az egybefüggő, 8k-s vagy nagyobb területek, na akkor fog a gép fejre állni, amint valakinek 4k+ memória kell.

Azt meg meg tudom tenni, hogy akár másodpercenként elteszem a buddyinfót, utólag lehet majd nézegetni.

Mire ezt begépeltem, tovább romlott a helyzet: 

# cat /proc/buddyinfo
Node 0, zone      DMA      2      2      3      1      2      2      0      0      1      1      3
Node 0, zone    DMA32   8875    134      1      3      0      2      4      2      1      0      0
Node 0, zone   Normal   1368     68      2      2      1      0      1      1      1      0      0

Hát, úgy néz ki, hogy mégse... döglés közben megnéztem a buddyinfo-t, és bőven voltak viszonylag nagy, egybefüggő memóriadarabok, és közben swap in/out is volt. Ha jól értem, akkor swap in-nek nem kellett volna lennie, mert a mm úgy csinált volna egybefüggő területeket, hogy kilökött volna valami (nagyobb?) processzt a memóriából a swap-ba, majd onnét visszakanalazta volna, újbólrendezve a memóriafoglalást. Tehát vagy so vagy si van, de egyszerre nincs a kettő (pláne nem 3G nem használt memória mellett).

Update: mégis? Ehe.

Haldoklás közben adtam még 20G swap-ot, de természetesen az nem segített, csak a gép icipicit reszponzívabb volt, több felé tudta osztani a disk i/o-t.

Utána felszabadítottam 58db HugePage-et ami bő 100M, de 3.5G szabad ram mellett nyilván nem jelentős mennyiség, és a gép _azonnal_ észhez tért. Ez a 100M ugye szép nagy, egybefüggő terület (volt, ehe).

Ez mind-mind közvetett bizonyíték, de nekem elég, most lökdösöm le az utolsó konténert, sajnos ez van a legjobban teletömve mindennel.

( kirsa74 | 2011. 08. 12., p – 16:43 )

próbáld ki freebsd-vel is ilyen-e, ha nem: problem solved

A mysql kapcsán felmerült swap probléma pl. solaris esetén nem jön elő. Viszont a környezett adott, és lehet, hogy a linux ilyen béna, de az is lehet, hogy én nézek be valamit.

Tüneti kezelésnek rendeltem még memóriát, mert olcsó, ám félek, hogy ezzel csak elodázódik a probléma, és nem oldódik meg.

( Nyosigomboc v | 2011. 08. 13., szo – 03:40 )

Nem tudnad legalabb a debug idejere logolni hogy mit csinal az a mysql?
Lehet, hogy valami nagyon benezett lekerdezes fut rajta, akkor meg hiaba nezelodsz a swap kornyeken.
Esetleg megnezheted meg, hogy a solarisos geped mysql konfigja miben ter el ettol.
Gondolom postgres csere nem jatszik.

--
Tudod te, mennyi lóvé fér egy Alstom-kocsi dobozába? :)) - laspalmas, VB

Nincs solarisos gépem, azt a freebsd-s ötletre írtam,hogy más rendszereket ez a jellegű probléma nem jön elő.

A nagyon benézett lekérdezés túl tud lépni a mysql beállított limitjein? Illetve okoz-e nagy mértékű swap foglalást 2G felhasználható ram mellett?

Marad még dap javaslata, a kernelcsere. Bár mivel a ram úgyis megjön kb. kedden, lehet hogy megvárom míg Debiánék pattintanak új kernelt, még ha az lesz vagy egy év is.

Ha nem undorodsz az Ubuntutól, akkor Natty alatt már 38-as kernel van, és elvileg mindent ami debianos el tudsz rajta futtatni, bár az áttérés nem tudom mennyire szívás. (Cserébe viszont az Ubuntura sokkal hamarabb vannak új dolgok a jövőben is, de akár a régieket is megtarthatod LTS-el.)

cat /proc/version:
Linux version 2.6.38-10-generic (buildd@yellow) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 201

( dikki | 2011. 08. 13., szo – 12:15 )

12:00:01  memtot memfree buffers   cached  slabmem      swptot swpfree  _mem_
12:10:01   7991M   1443M    192M    1158M     130M       1903M   1491M
12:20:01   7991M   1425M    194M    1171M     130M       1903M   1491M
HugePages_Free:      695
Hugepagesize:       2048 kB

szorozd meg 2048-al a 695-öt.

> 1423360, mit nyertem?

Szerintem zároltad a szabad memória ekkora részét (~1.4G) az OS elől. Tudtommal hugepage terület az nem swap-pelhető, és a normál helyfoglalás sem használhatja fel. Olyan szabad terület, ami mégiscsak foglalt, ezért igazából le kéne vonni a memfree-ből.

( log69 | 2011. 08. 14., v – 12:49 )

Ha nem találod meg itt a választ és feldobod a kérdést külföldi levlistára, akkor ha tudod, majd légyszíves írd meg mire jutottál. Köszi.

( Fisher v | 2011. 08. 18., cs – 10:12 )

Úgy néz ki, hogy a megoldás az új kernel lett:

kép

Szépen látszik a piros sáv térnyerése, gondolom akkor rámolt át pár memóriablokkot, hogy legyenek jobban egybefüggő darabok. A szabad memória megugrása intenzív NFS forgalom után volt (napi mentés, meg én tesztelgettem, hogy mivanmá').

Az nem nagyon látszik a grafikonon, hogy az új kernel előtt sose volt szabadon 4k-s blokk, most viszont mindig van valamennyi. Közben megjött a memória, van beépítem ma délután vagy ha nem lesz rá időm akkor majd a jövő héten, és akkor hátha lesz szebb diagramom.

Ps.: miért nem tudom rávenni az rrdgraph-ot hogy magasabb képet rajzoljon? Megadtam a --height=400 paramétert a munin pluginben és nem veszi figyelembe. Az --only-graph pl. működött, csak ez nem.