Fórumok
Üdv,
van egy Couchbase Community Edition szerver, 20G RAM-mal (+ 4G swap). A gép egy Xen VM-ben fut, és egy cluster része.
Néha random az OOM kinyírja a cbq-engine-t, mert elfogy a RAM. A logban ez van:
beam.smp invoked oom-killer: gfp_mask=0x24201ca(GFP_HIGHUSER_MOVABLE|__GFP_COLD), nodemask=0, order=0, oom_score_adj=0
beam.smp cpuset=/ mems_allowed=0
CPU: 3 PID: 1048 Comm: beam.smp Not tainted 4.9.0-6-amd64 #1 Debian 4.9.82-1+deb9u3
....
Mem-Info:
active_anon:4649138 inactive_anon:357654 isolated_anon:0
active_file:112 inactive_file:145 isolated_file:0
unevictable:0 dirty:0 writeback:0 unstable:0
slab_reclaimable:4926 slab_unreclaimable:10268
mapped:1386 shmem:51446 pagetables:16139 bounce:0
free:24658 free_pcp:190 free_cma:0
...
51973 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 4194300kB
Total swap = 4194300kB
5242783 pages RAM
0 pages HighMem/MovableOnly
105740 pages reserved
0 pages hwpoisoned
...
Out of memory: Kill process 13773 (cbq-engine) score 319 or sacrifice child
Killed process 13773 (cbq-engine) total-vm:8592000kB, anon-rss:7894568kB, file-rss:0kB, shmem-rss:0kBIlyenkor a top kimenetében ez látszik:
Wed Jan 22 17:50:02 CET 2020
top - 17:50:02 up 224 days, 5:22, 0 users, load average: 25.62, 7.66, 3.17
Tasks: 217 total, 2 running, 214 sleeping, 0 stopped, 1 zombie
%Cpu(s): 5.1 us, 2.5 sy, 0.0 ni, 92.1 id, 0.1 wa, 0.0 hi, 0.0 si, 0.2 st
KiB Mem: 20548172 total, 19533836 used, 1014336 free, 4052 buffers
KiB Swap: 4194300 total, 0 used, 4194300 free. 302696 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11927 couchba+ 20 0 7754484 4.848g 0 S 6.1 24.7 220:55.94 /opt/couchbase/bin/memcached -C /opt/couchbase/var/lib/couchbase/config/memcached.json
24803 wildfly 20 0 4674524 2.650g 0 S 6.1 13.5 505:29.54 java -D[Standalone] -server Duser.timezone=Europe/Budapest -Dfile.encoding=utf-8 -Xms2048m -Xmx2048M -XX:MetaspaceSize=512M XX:MaxMetaspaceSize=512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/if3/wildfly/standalone/log/server.log Dlogging.configuration=file:/opt/if3/wildfly/standalone/configuration/logging.properties -jar /opt/if3/wildfly/jboss-m+
...
total used free shared buffers cached
Mem: 20066 19038 1028 200 3 295
-/+ buffers/cache: 18738 1327
Swap: 4095 0 4095Egyrészt ha van valakinek ötlete, a CB miért zabál ennyi memóriát, és mit lehet ezzel tenni, az most nagyon jól jönne.
Másrészt ott van még 4G swap, azt miért nem használja a rendszer...?
Köszi,
a.
Hozzászólások
MySQL csinált nálam hasonlót.
Ez oldotta meg 15 percenként futtatva. Nem elegáns, de funkcionálisan nem zavart be, a MySQL vígan elélt 100 napokat is így.
#!/bin/bash#pgrep -f "/usr/libexec/mysqld" | while read PID; dops aux | grep "mysqld.sock" | grep -v "grep" | awk '{print $2}' | while read PID; do# echo $PIDecho -1000 > /proc/$PID/oom_score_adj;
doneKöszi a választ - az az igazság, hogy én inkább magára a probléma okára vagyok kíváncsi, és ha az megvan, szeretném azt megoldani :).
Szerintem ez ilyen :D Mármint beírtam a google-be hogy cbq-engine az első találat az volt, hogy Cbq-engine consuming massive memory for simple queries
A másik VPS alatt minek swap ? Sose rakok VPS alá swapot (máshol se láttam defaultban azure,aws,google ...), mert ha elfogy 20G ram akkor pikk pakk elfogy az a pár giga swap is, cserébe meg ledarálja az i/o-t.
Fedora 38, Thinkpad x280
Szerintem a swap itt sem lenne hülyeség. Pl az OOM azért nyírja ki a cbq-engine-t, mert az eszi a legtöbb memóriát. De ha megnézed a syslog tartalmát, akkor ott látod, hogy amúgy a beam.smp akart épp valamennyit allokálni, és lehet, hogy neki csak néhány lap kellett volna - ehelyett az OOM úgy döntött, hogy akkor lelövi azt, aki a legtöbbet zabálja. Nem feltétlen fogyna el a swap (amúgy én inkább a 4G méretet nem értem a 20G mellett... de ezt nem én telepítettem, ez van jelenleg.)
OOM úgy döntött, hogy akkor lelövi azt, aki a legtöbbet zabálja Az oom-killer nem arra van, hogy normál esetbe futkározzon. Kb. bármikor kernel pánikot eredményezhet. Windows esetén pl. nincs is oom-killer, ott jön a kékhalál, bár én Linux esetén is jobb ötletnek tartom a panic on oom bekapcsolását. Ha az oom gyakran futkározik, akkor több ram kell.
Am én sem raknék VM-be swap-et, az normál gépen is kinyírja a rendszert, vm-en meg főleg.
Viszont a MS féle memory-hog-ok (exchange, sql server) képesek megbeszélni egymás közt, hogy "figyu, kevés a szabad ram, szabadítsd fel a cachedet". Láttam ennek végtelenciklusában vergődő vasat.
A felhasználók meg kb a havi záráskor jelezték csak hogy lehetne gyorsabb is.
Adjál neki 32G ramot, láthatóan nem elég a 20G.
Fedora 38, Thinkpad x280
Ez nem rajtam múlik, meglátom, milyen döntést hoz a tulaj.
De a kérdés most - nem pont erre a hozzászólásra, általában - ha van swap, miért nem használja?
A swaptől én is féltem, de aztán beszéltem egy tanult kollégámmal. Sokáig max indikátornak használtam, hogyha a swapon van valami, akkor biztos kicsi a RAM, növelni kell. Téves következtetés volt.
A swapot a linux helyesen kezeli. A ritkán használt lapokat kirakja. Pl. binárisok, adatok, amit betöltött, de ritkán használ. A swap írás nem rossz, ha ritkán megteszi, kint van és csönd van. Ha visszaolvassa, akkor kell neki, az már rosszabb, mert potyára rakta ki. Ha sűrűn írja-olvassa, az azt jelenti, hogy kevés a memória. Na _ezt_ érdemes monitorizni, mert alul van méretezve a rendszer. Ha hébe-hóba kirak valamit, heti 1x visszaolvassa, tök jó. Egy régóta futó rendszernek simán lehet indításkori adat a swapon, és azóta nem nyúlt hozzá. Sok száz MB, GB-nyi adat is lehet swapon, egészséges állapot.
Értelemszerűen a RAM így értékes, dinamikus adatokkal tud foglalkozni.
Ha a kedves ügyfél sokat swapel, azt érdemes mérni és büntetni/korlátozni + jelezni neki, hogy vegyen vissza vagy váltson nagyobb RAM-ot.
B verzió: a kedves ügyfél nem kap swapot, a fenti baxogatást megspórolod, neki összeomlanak a programjai, csomagot emel...vagy nem, mert azt mondja, xar ez a VPS. Ügyfélfüggő.
Azóta mondjuk én luxusnak érzem több hetes inaktív adatot RAM-ban tárolni. Adok kb RAM méretű swapot és muninnal illetvet egyedi nagios pluginnal monitorozom, ami a lapok i/o-ját figyeli és riaszt, ha túl aktív mozgás van.
A KVM virtualizáció tovább megy: ha a guest OS-nek nincs swap, akkor a host OS swapre teszi ki a guest OS régóta inaktív lapjait.
Ezt viszonylag ügyesen teszi, hiszen ugyanaz a swap alrendszer kezeli. Így a host OS-ben újabb kiosztható memória van, akár cache-re.
Mi alapján mondod meg ügyfélnek hogy ne swapoljon ? Saját VPSeinken nem swappelek. Mert jó pár példa volt, hogy lyukas kódok miatt elkezdett darálni a swap, és az olte a tobbi gépet.
Az ügyfélnek templateből tolunk VPS-t amiben alapbol nincsen swap, ha csinal maganak szive joga.
"A KVM virtualizáció tovább megy: ha a guest OS-nek nincs swap, akkor a host OS swapre teszi ki a guest OS régóta inaktív lapjait."
Nekem a virtualizáció az type-1 (bare metal) :P A KVM nálam inkább virtualbox alternativa lehet :D Persze kinek mi. Jahh hypervisorokba se rakok swapet :D
"Azóta mondjuk én luxusnak érzem több hetes inaktív adatot RAM-ban tárolni." Én nem, sajna volt másnál ilyen gépünk amihez ritkán kellett nyúlni, de akkor nagyon, viszont akkor ott homokorázott mig swapből előszedte a dolgait. Szóval kösz nem.
Fedora 38, Thinkpad x280
"Mi alapján mondod meg ügyfélnek hogy ne swapoljon ?"
Az alapján, hogy az átlagos I/O többszörösét eszi meg a virtuális gépe (swapolás miatt) azért, mert ő alulméretezte a bérelt VPS-t. A díjszabás nem ilyen extrém I/O-ra lett kalkulálva.
Ha csinál magának egy swap file-t és azt használja, ugyanaz a szitu, szadizza a diszked. Alulméretezés esetén indokolatlanul.
"akkor ott homokorázott mig swapből előszedte a dolgait"
Most már pár éve swapos vagyok, nem tapasztaltam ilyet. Hasonló a windowsos időkből rémlik, amikor a memória tisztítók kipucolták a windows start menüt is :) Na linuxnál ilyen élményem nem szokott lenni. Főleg, hogy a swap, ha nem is SSD-n van, de vállalható tempójú diszk alrendszeren (100-300Mbyte/s) Persze ettől még előfordulhat, szerencsére nem jellemző. Persze, ha van RAM dögivel, nem érdekes.
"A KVM nálam inkább virtualbox alternativa lehet"
Nem tudom honnan ez a megközelítés, máskor is írtad már:) Nekem elég erős érv a KVM mellett, hogy nagyobb szolgáltatók is használják. Legalább annyira, mint a többit, tehát nálam nem kis pistike szint:) Cloud szolgáltatók motorháztetője alatt is ott duruzsol, pl. az Onapp cloud management felület vmware, xen, kvm hypervisort támogat. Virtualboxot nem :)
Tudomásom szerint a legnagyobbak azure / amazon type-1 hypervisorokat tolnak :>
De mint mondtam ez inkább hitvita stb. Annó 2005/6 táján kezdtem a virtualizációval foglalkozni akkor kb volt a vmware jó pénzért a qemu, és a xen. Így lett a xen ami azóta is stabil gyors stb. Xenserver révén olyan featurek vannak amikrol kvm csak álmodott annó, még talán most is :D promox révén is akár.
Voltak hullámvölgyek mikor a KVM volt jobb, volt mikor a xen stb. de kb izlés kérdése. Amióta van a Xen-Orchestra ráadásul elég fullos management felület is van xenserver/xcp-ng hez, ami akár verheti a proxmot is :>
Nahh mind ez már erősen offtopic lett :D
Fedora 38, Thinkpad x280
Tudomásom szerint a legnagyobbak azure / amazon type-1 hypervisorokat tolnak :>
Csak az archivum kedvéért:
Most volt alkalmam szembetalálkozni egy Google Cloud Platform (GCP) futó virtuális szerverrel.
KVM-en fut, viszont tényleg nincs swapja, ahogy mondtad.
"ahh hypervisorokba se rakok swapet :D"
Juteszembe, a XenServer/XCP-ng is használ swapot dom0-n. Ott is kikapcsolod?
Igen ki :D
Mikor sok sok ram van a fizikai gépben akkor a hypervisor már magának 8G ramot állít be alapból. Ott fölöslegesnek tartom az 512M-1G swapot. Mondjuk a régebbi installok még swapfile-t toltak az új már partíciót :/
Szóval egy Hypervisornak 8G ram elég szokott lenni, xen alatt legalábbis.
Fedora 38, Thinkpad x280
8G? Mit futtatsz te Dom0-ban?
En altalaban valahova 512 es 1024MB koze lovom be a dom0-nak adott memoriat. Ha 512-vel stabil, akkor nem bantom. Ha nem, akkor addig emelem kiserleti alapon, meg stabil nem lesz. Utana meg egy picit adok neki, majd monitorozom munin-bol.
Otthoni nas-on mondjuk ring0-ban alpine fut. Az altalaban eleg friss xen-t szokott szallitani. pendrive-rol berantja a rendszert ram-ba.
Meg avval egyutt is, 768MB-al teljesen stabilan elfut, ugy hogy a / tmpfs, es boot-kor oda rant be mindent az alpine.
meg par aprosag van benne, mint iscsi kliens, nfs kliens, ilyesmik.
A tobbi ram mind megy a domU-knak.
Egy 128GB RAM-nyi szerveren 100-150 VM simán elfut. Na oda jó lehet. Úgy tudom egy ideje a xenserver telepítője is arányosan állította be a dom0 RAM-ját a host gép RAM-hoz képest. Alap 4GB körül volt és egy 128GB RAM-nál már 7.5GB volt.
Ez már bocs, de kb. a szarnak egy pofon.
Workaround. A script 2 éve megy, nagy kiszolgálású SQL. Franc tudja volt-e bug az SQL-ben vagy mi volt az oka, de havi 1-2x ilyen hibával fejreállt bármennyi RAM-ot adtam, neki. A meglévő 8GB után már azt hiszem 20-32-t is kapott a rohadék. Éles környezetben ez azonnal megoldotta a problémát.
Ettól vagy mysql bug javítástól, de 2 éve nincs probléma.
Jó mondjuk ez szinte egyértelmű, hogy néha simán elszált valamiért. Az a baj, hogy ezzel a megoldással valami mást fog kinyírni, ami simán lehet kritikus. Az a mázli, hogy éppen nem olyan volt. Az oom-killer valami biztosan bezár, enélkül nem tud kilépni.
bocs hogy offolok, de tanuljatok mar meg scriptet irni! ps+grep+grep+awk. kesz szerencse hogy cut meg sed nem kellett...
pl grepnel "[m]ysqld.sock" a kereses, es mingya nem talalja meg sajat magat. de ha ilyen processeket keresunk akkor ott a pgrep.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
mi köze a MySQL-nek a Couchbase-hez?
Meg kell nézni leakel-e, ha igen akkor megpróbálni frissíteni. Ha nem leakel, akkor simán több ram kell neki.
Mi alapján döntöd el, hogy leakel vagy sem? Ha a memória használat monoton nő, akkor igen, ha nem, akkor nincs leak?
Mert akkor nem leak-el :).
Kb. igen. Ha leakel akkor szép lassan monoton nő a memória használat (nőhetne gyorsan is, de akkor sokkal gyakoribb probléma lenne). Ha kb. konstans, vagy terhelés függő, akkor simán kevés a ramod.
De ezt akartam jelezni, hogy szerintem ez nem memleak - sokszor van olyan, hogy belépek, és 12-14G van használva "csak". És nem a következő OOM miatti restart (a systemd - gondolom - újraindítja ilyenkor) oldja meg a mem gondot. Van, amikor 1-2 hétig nincs semmi gond.
Szal' szerintem nem leak-el.
Nem feltétlenül leakel egy program, mert nő a memóriahasználata. Például egy cache eleve így működik.
Akkor is lehet oom üres swap mellett, ha nem ki swappelhető a sok ramot evő folyamat.
Így tanultam meg én is, hogy például virtualbox nem támogatja azt, hogy swapet használjon, ha a fejlesztői gépemen futó vm példányok tényleg elkezdik kihasználni a ramot. Emiatt a zram és zswap is csak a többi processt tudta összébb nyomni. Ami már maga is nagy segítség volt mindaddig, míg egy virtualbox vm példány el nem érte a limitet, mert akkor beállt a host, mint a szög és tekerte a háttértárat, s néha eljutott az oom killer-ig is.
Ezen pedig semmi swap vagy ram tömörítési trükközés nem segít, csak a több ram.
https://hup.hu/node/138445 oldthread, jóthread. Még mindig nem tudta nekem senki megmondani, miért jó az OOM killer.
Egyrészt nem akarok (kinem nem inge...) lesüllyedni az átlag fórumozó szellemi szintjére, másrészt nem az általam indított témában :), de szerintem ha ezt így írod, hogy "még mindig nem tudta senki megmondani", akkor (tényleg no offense!) lehet, hogy a fogadókészséggel van inkább gond.
Nyilván mint mindenben, ebbe is bele lehet ölni egy rakás időt megismerni, megérteni, megtapasztalni, kipróbálni, ... használni... Én nem sokat foglalkoztam még vele, de ami lejött:
Jelen esetben szerintem nem az OOM-killer a hibás, nem azt kell kikapcsolni. Lehet, hogy kevés a memória, lehet, hogy "csak" szarul van megírva valami query, lehet, hogy valamelyik komponens leak-el, csak mondjuk időszakosan éled fel... Én azt hittem, hogy valaki már belefutott hasonló hibába, esetleg nagyobb tapasztalata van couchbase területén.
De sajnos itt eddig nagyjából arról volt szó, hogy miért nem kell swap, és mi a gond az OOM-el.
Gondoltam én is leírom már a véleményem... :)
(És bocs, nem feltétlen neked szántam, csak ez a komment volt legalul - tényleg senkit nem akarok megbántani.)