Out of memory: Kill process (cbq-engine)

Ü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:0kB

Ilyenkor 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       4095

Egyré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

Szerkesztve: 2020. 01. 22., sze - 22:18

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; do 

ps aux | grep "mysqld.sock" | grep -v "grep" | awk '{print $2}' | while read PID; do

#    echo $PID
    echo -1000 > /proc/$PID/oom_score_adj; 

done

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 32, Thinkpad x220

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.

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 32, Thinkpad x220

"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 :)

Nekem elég erős érv a KVM mellett, hogy nagyobb szolgáltatók is használják.

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 32, Thinkpad x220

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.

# lscpu
Architecture:        x86_64
[..]
Model name:          Intel(R) Xeon(R) CPU @ 2.20GHz
[..]
Hypervisor vendor:   KVM
Virtualization type: full

KVM-en fut, viszont tényleg nincs swapja, ahogy mondtad. 

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 32, Thinkpad x220

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.

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.

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!

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.

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.

Szerkesztve: 2020. 01. 23., cs - 17:06

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.

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:

  • nem kell használni, ha nem akarod
  • ha akarod, elég finom beállításokra van lehetőséged
  • és végül az ökölszabály: én elhiszem, hogy sokan sokkal jobban tudják nálam, mi a jó. Ha egy rendszer alapértelmezetten így települ, akkor elfogadom.

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.)