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: 4096NUMA - 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?
Hozzászólások
+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.
Nem inkább csak jön az OOM killer, és esetleg kevésbé kesztyűs kézzel lőné ki a memóriafaló processzt, mint ő tenné? (SIGTERM helyett SIGKILL, vagy hasonlóra gondolok.) Kötve hiszem, hogy az egész rendszere lefagyna.
:wq
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).
Egyszer írtam C++-ban egy -bénára sikerült- fa-osztályt, aminek olyan jól sikerült a konstruktora, hogy elég volt egyetlen node-ot létrehozni, és máris a teljes memória fraktálszerűen telelett a fával. :)
Na ezt viszont szépen kezelte az OOM, csak innen ugrott be.
:wq
az OOM killer alapból azt a processzt lövi ki, aki a legtöbb memóriát foglalja.
A swap nem ellenség ám... bekapcsolt swap és 0 swapiness mellett épp az általad jónak tartott hatást éred el.
És ezt hol tudom beállítani?
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
http://hup.hu/node/37739
Köszi! Pont jó nekem! :)
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
+1 (subs)
http://hup.hu/modules.php?name=News&file=article&sid=1976
UFF
Ez mennyiben válasz a problémámra? Mivel az alap dolgokat tárgyaló írást linkeltem feltételezem, hogy felfedeztél valami alap hibát a beállításaimban. Megosztanád velem, hogy mi volt az?
A problémád Te magad vagy.
Az alap tézis az, hogy minden Op.rendszernek szüksége van a Swap-ra.
A stílusod elég érdekes, de ezt most hagyjuk.
http://www.linux.com/news/software/applications/8208-all-about-linux-sw…
subscribe
nehéz ilyenkor szavakat találni
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.
Valszeg high order allocation, try 2.6.38+
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.
No, ha megint halna akkor nézem a buddyinfo-t.
"Sajnos" ez a gép nem a tmpfs-t használja, ezt épp nem állítottam át:
Temporary tables created on disk: 2% (2K on disk / 76K total)
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:
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.
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.
(optional) x összegért megcsinálom a migrációt
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
Nem undorodom, de mint írtam, a környezet adott. Valamit ahogy szintén írtam, még nincs OpenVZ patch az újabb kernelekhez. Legalábbis én nem találtam.
? df -T|grep tmpfs
szorozd meg 2048-al a 695-öt.
1423360, mit nyertem?
> 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.
Jól tudod, nem swapelhető(*). Ám azonnal le is zárolja, amint a foglalás megtörténik, hogy más ne férjen hozzá, tehát nem látszik mint szabad memória.
*) Épp ezért használom
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.
Ú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.
"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."
graph_args --rigid
bookmark :)