FATAL: the database system is in recovery mode

Jött egy ilyen a postgresql.log-ba:

2015-02-02 10:16:52 CET DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2015-02-02 10:16:52 CET HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2015-02-02 10:16:52 CET FATAL:  the database system is in recovery mode
2015-02-02 10:16:52 CET FATAL:  the database system is in recovery mode
2015-02-02 10:16:52 CET FATAL:  the database system is in recovery mode
2015-02-02 10:16:52 CET FATAL:  the database system is in recovery mode
[...]

Meg még jó néhány soron keresztül. Nosza, olvassunk vissza:

2015-02-02 10:16:50 CET LOG:  server process (PID 10544) was terminated by signal 9: Killed
2015-02-02 10:16:50 CET LOG:  terminating any other active server processes

OOM killer, fuk u!

Konklúzió: Linuxon használni PostgreSQL-t, főleg hash indexekkel kb. egy orosz rulett.

Hozzászólások

Hatalmas hulyeseget irtal.

Sok dolgot okolhatsz emiatt (legfokepp magadat) de sem az OOMKiller sem a linux, mint olyan nem tehet rola. Csak azt csinaltak, amire hivatottak. Ezzel szemben te nem.

Releváns beszélgetés IRC-ről:

<x> "The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do."
<x> valamiert ez ugrott be
<y> ja csak azt felejtik el hogy a bal kez uszkosodik amikor levagja a jobb labat altalaban

Ahol y egy nagyobbacska szerverhostingban admin. Osztom a véleményét.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Rossz a hasonlat. Inkább ahhoz hasonlítanám hogy egy adott területű szobába egyre több ember akar bejönni, és a kidobó nem tehet mást mint hogy mindig dobál ki embereket ahogy jönnének az újak, de senki sem magyarázza el neki hogy milyen algoritmus szerint kellene kidobnia embereket. Csak kidobja, hogy ne szakadjon szét az épület, mert az a cél.

--
arch,centos,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Mert nem a belepessel van a baj. Olvasd mar el legyszives az ide vonatkozo doksikat es ha van konkret kerdesed levegobe nezo hoborgesen kivul, szivesen megvalaszoljuk, megvitatjuk.
Te egy szarul konfiguralt OOM killer aldozata vagy, akar tetszik, akar nem, ez igy van

// Happy debugging, suckers
#define true (rand() > 10)

A hozzáállás térhet el: mi a fontosabb, egy alkalmazás - minden áron, a legvégsőkig történő - kiszolgálása, vagy az OS alatta? (Nyilván árnyalja ezt a képet, hogy alkalmazásból mennyi van az adott OS-re pakolva egyazon node-on, miként vannak konfigurálva, satöbbi...)
------------------------
Program terminated
{0} ok boto
boto ?

Erre próbáltam magam is utalni. Az én elképzelésem szerint (a hardware megfelelő méretezésén felül természetesen) ideális esetben nem a vas a hard limit, hanem az OS maga már védekezik azáltal, hogy az alkalmazásnak nem adja oda a teljes vasat - _és_ emellett az alkalmazás be van konfigurálva a környezetnek megfelelően, nem pediglen "ahogy a csövön kifér", aztán majd lesz, ami lesz - valami megállítja: vagy az OS, vagy elhasal az egész doboz... De mondjuk a Solaris-féle erőforrás-kezelés, amit jobban ismerek, nem említhető egy napon ezzel a "hamar kinyírok valamit"-jellegű eljárással.
------------------------
Program terminated
{0} ok boto
boto ?

OS érdekel a legkevésbé. Alkalmazás meg addig, ameddig nem a(z ügyfelek felé nyújtott) szolgáltatás rogyik le miatta. (Nyilván ehhez általában sok mindennek össze kell játszania, mint ahogy itt is a probléma közvetlen forrása a hash index volt, aminek elkúródását az OOM killer okozta, aminek működését, stb. stb. stb.)

Szerk.: mellesleg, mielőtt valaki túldramatizálná az egészet, reindex után seperc alatt helyre lett pofozva, talán, ha 10-15 percig nem ment emiatt a szolgáltatás bizonyos részei. A blogbejegyzés inkább arról szólt volna, hogy ez is (ebben a formában) _csak_ Linuxon lehet probléma.

(Az, hogy mi van beállítva és mi nincs, illetve, hogy kinek a dolga lett volna - megjegyzem, nem az enyém, mivelhogy még mindig szoftverfejlesztő vagyok elsősorban - az meg megint más kérdés. Bár továbbra is kérdés, hogy miért egy olyan beállítás a default, ami adatvesztést okozhat.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

nagyságrendileg most egy sz@rul konfigolt gépről beszélünk. Itt nagyon sokan vagyunk, akiknek a keze alatt 100-as nagyságrendben voltak/vannak Linuxos szerverek, mindenféle feladatra. És igen, mi is belefutottunk abba egyszer-egyszer, hogy valahol beindult az OOM-killer. Ez nem azt jelenti, hogy a Linux szar, hanem azt, hogy mértezési/hangolási probléma adódott, amit kezelni/javítani kell. Nekem volt olyan, hogy az sshd-t is tarkóncsapta az OS (azon a gépen épp Tomcat futott egy rakat baromira sz@rul megírt alkalmazással) - utána be lett állítva egyrészt az ulimit, másrészt az allokáció paraméterezése, és azóta köszöni szépen, nem OOM-ba, hanem ulimitbe veri be a fejét a motyó, ha úgy adódik.
Miért olyan fosch a DB, hogy egy sigkill után széthullanak az indexek? és újraindulás után miért nem rakja rendbe automatice, mielőtt a DB-t elkezdhetnéd használni?

Ismételten megkérdem: miért van by default szarul konfigolva? Hja, várj, talán azért, mert a tisztelt kernelfejlesztők szarnak az userland fejére, őket csak a maguk kis zárt világa érdekli.

"Miért olyan fosch a DB, hogy egy sigkill után széthullanak az indexek?"

Nem hullik szét, csak a hash index. De erre fel is hívja a dokumentáció a figyelmet, mint említettem már többször. btree pl. rendesen WAL-logged, mint ahogy minden más is. Egyébként minden mással megcsinálja a "rendberakást automatice". Nem véletlen írtam, hogy OOM killer ÉS hash index.

(Megjegyzem, nem állt le a postgresql, egy worker lett kilőve alóla, ami épp módosításokat végzett, emiatt visszagörgette a journalt.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

NEKED sz@rul, általános felhasználás esetén meg nincs belőle gond, illetve ami van, az jóval kevesebb, mintha a malloc híváskor már nem kapna az érintett app memóriát. Lehetne, pontosabban lehet azt csinálni, hogy ténylegesen csak akkor kapjon valamely processz memóriát, ha rendelkezésre áll annyi, amennyit kér - ez viszont igencsak pazarló lenne. A te rosszul hangolt, alulméretezett postgresql szervered (ami még más egyebet is csinál) egészen pontosan egy darab kiszolgáló, nem általános userland.

Az, hogy a DB a hash indexet nem teszi rendbe automatice, vagy mást, az irreleváns - összeoomlás után kési matyizást igényel. Attól kezdve, hogy dokumentációban ott van, hogy "vigyázz, ha elborul egy worker, akkor a hash index széthullik" nincs miről beszélni: meg kell oldani, hogy ez a helyzet lehetőleg ne forduljon elő.
Mivel általános beállításokkal elfogyhat a rendelkezésre álló memória, ami akár OOM-killer beindulását is okozhatja, így az üzemeltető felelőssége, hogy úgy állítsa be a gépet, hogy legyen elég RAM+swap, és az overcommit legyen tiltva, és a kritikus folyamatok OOM-killertől legyenek védettek.

Nem tudom, hogy miért ilyen az alapbeállítás, de az részletes indoklás nem is érdekel - tudom, hogy van overcommit, van OOM-killer, tudom, hogy mi a default beállítás, és annak milyen következményei lehetnek, és nagyrészt tudom, hogy hogyan lehet ezeket a dolgokat beállítani, hogy másképp viselkedjen az OS.

A PostgreSQL-t nem szoktatok hangolgatni, mielott az eles app ala toljatok? Ott az nem szokott felmerulni, hogy a CREATE TABLE miert nem hozza letre rogton a legjobb fasza indexeket? Pedig megtehetne, hat milyen fosch mar ez! Erted, letrehozom a tablat, majd nekem, NEKEM kell meg gondot forditanom arra, hogy jo indexek legyenek rajta! Borzaszto! Ez is csak PostgreSQL-en fordulhat elo!
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ha már trollkodsz, trollkodj értelmesen. Mi köze az indexnek a create table-hoz? :)

Egyébként, ha már itt tartunk, de simán lehetne statisztikázni a queryket és az alapján automatikus javaslatokat tenni és/vagy készíteni indexeket. És de, szoktuk finomhangolni a pgsql-t. Az OOM killernek a _LÉTÉVVEL_ van bajom.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mint többször le lett írva, per process (és gyermekei) beállítható, hogy mennyire legyen esélye az OOM-killer áldozatává válni, illetve egy jól irányzott beállítással (echo "-17" > /proc/self/oom-adj) meg lehet tiltani, hogy OOM-killer végezzen vele - igaz, ekkor ha elfogy a memória, akkor meg abba fog beledögleni az adott processz.
Ugyanígy az overcommit (ami szintén teljesen eliminálható) hangolása is hasznos dolog; ezt a kettőt _kell_ jól használni, nem pedig picsogni, hogy next-next-finish feltolt OS-en, a rápakolt szolgáltatásokhoz képest kevés memóriával OOM-ol, és ez postgres-nek, a dokumentációban leírtaknak megfelelően(!) problémát okoz.

Alapvetően még mindig az az alapprobléma, hogy
- létezik egy vagy több process ami az idő során egyre több memóriát eszik (ez kódolási hiba)
ÉS/VAGY
- a rendszer ami alatt az alkalmazás(oka)t futtatjuk, nem rendelkezik elég memóriával.
Tökmindegy hogy milyen megoldást választunk ennek a helyzetnek a kezelésére, valami kárt fog szenvedi.

--
arch,centos,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Nem.

Az első eset lehetséges, van olyan processz, aminek az idővel egyre több memóriára van szüksége. Ez egyáltalán nem kódolási hiba, van ilyen use-case (pl. in-memory adatbázisok, cache-k).
A rendszer hibája, hogy akkor is akar adni a processznek memóriát, amikor sem a C szabvány, sem a POSIX nem írja ezt elő.
Szépen meg kell mondani az appnak, hogy bocs, nincs több memória. Az alkalmazásnak pedig kezelnie kell ezt a dolgot (ez kódolási hiba, ha ez nincs kezelve. A növekvő memóriahasználat nem kódolási hiba).

Ennyire egyszerű az egész: már 40 éve kitalálták erre a megoldást: a memory manager jelzi, hogy nicns több memória, az alkalmazás meg kezeli ezt a helyzetet (kilép, hibaüzenetet dob, bármi). Mit kell ezen a jól működő dolgon még bonyolítani?

Es ez az alkalmazasfejlesztok felelossege. Ha meg az alkalmazas kap memoriat, de egy masik alkalmazas meg (aki jol viselkedik es jol van megirva) meghal az OOM Killer miatt, akkor most megint ki jart jol? A szar programozo.
Nagyon nem kene tamogatni ezt a dolgot. Ha nincs memoria, akkor fogyjon el, es kesz. Ez van. Az eroforrasok korlatosak. A lemez, a memoria, a savszelesseg, a CPU teljesitmenye, mind-mind korlatosak.

A probléma, illetve a döntés onnan jön, hogy az alkalmazások általában a ténylegesen használthoz képest jóval több memóriát kérnek az OS-től, ami, ha a kérés idején lefoglalásra kerülne, pazarlás lenne. Nehéz jó megoldást találni, de épp ezért hangolható a memóriakezelés ezen része is. Hint: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html

Az OOM Killer kilőtt egy pg workert, ami miatt az átment egy rövidke karbantartási modba vegigporgetni a WAL logot. Megis mi az isten nyilat kellene okolnom a pg process haláláért, ha nem az OOM killert? Biztos chemtrail mergezesben halt el.

Mellesleg, maga a Postgresql a rövidke nehany 10 másodperces gondolkodás utan vigan futott tovabb, leszámítva az elcseszodott hash indexeket, de azok sajna ilyenek.

--------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

De miért egy random másik processt kell lelőni? Miért nem azt, ami hízik? Vagy mondok jobbat, miért kell egyáltalán lelőni, miért nem lehet simán OutOfMemoryException-t dobni? (Vagy annak tetszőleges random formáját).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Honnan tudhatná az OOM killer hogy melyik processed leakel, és melyik processed foglal egyre több memóriát azért mert az a normális működése (és nincs elég memóriád hogy futtasd a programot)?

--
arch,centos,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

ezt olvastad mar? man 3 malloc:

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available.

Ami azert akarhonnan is nezem, ordas kretenseg. A default-nak a jozan esz vezereltnek kene lennie: akkor mondom, hogy van memoria, ha valoban van, ha nincs, akkor kezelje le az alkalmazas korrekt modon. Szoval en hiaba ellenorzom, hogy a malloc mit ad vissza, ha a kernel atver...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

A default-nak a jozan esz vezereltnek kene lennie:
oke, csakhogy ezt meg mindig ki tudod kapcsolni -- meg linux szalatt is (/etc/sysctl.conf, /etc/sysctl.d/, /proc/sys/vm/oom_*, /proc/sys/vm/overcommit_*).

hogy ettol fuggetlenul egy komplett rendszert fejleszto es/vagy uzemelteto emberke'k mit csinalnak az egy mas kerdes. a lehetoseg megvan ra. csakhat nyilvan egyszerubb ignoralni az osszes malloc(), realloc(), mmap(), stb hulyeseget mintsem mondjuk jol programozni es rendszert jol beallitani...

szerintem elsiklottal a lenyeg felett: a malloc() Linux alatt *mindig* azt mondja, hogy van memoria (kivancsi vagyok, hany Linux telepites van atallitva a default-rol, hogy ne overcommit-tolja a memoriat). Ezt hogy kezeled le? Es az miert x alkalmazas hibaja, ha az oom killer pont ot oli meg?

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Ezt hogy kezeled le? Es az miert x alkalmazas hibaja, ha az oom killer pont ot oli meg?
Van 1.5 giga ram a gepben ami elott most ulok:


apal@laptop:~$ free
             total       used       free     shared    buffers     cached
Mem:       1545144     942916     602228          0      72708     528408
-/+ buffers/cache:     341800    1203344
Swap:      1935356          0    1935356
apal@laptop:~$ arch
i686

Allokaljunk 2 giga't:


apal@laptop:~$ cat x.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
 void   *p;
 p=malloc(2000*(1024*1024));
 fprintf(stderr,"p=%p\n",p);
 free(p);
 return(0);
}
apal@laptop:~$ gcc -Wall -pedantic -ansi -O3 -D_GNU_SOURCE -fPIC -o x x.c

Parhuzamosan (masik terminal, rootkent) jatszunk a /proc/sys/vm/overcommit_memory beallitasaival:


laptop:~# echo 0 > /proc/sys/vm/overcommit_memory
apal@laptop:~$ cat /proc/sys/vm/overcommit_memory
0
apal@laptop:~$ ./x
p=0x3a654008
laptop:~# echo 2 > /proc/sys/vm/overcommit_memory
apal@laptop:~$ cat /proc/sys/vm/overcommit_memory
2
apal@laptop:~$ ./x
p=(nil)
apal@laptop:~$ 

Meg lehet csinalni, nem oly' veszes az. Me'g "szaralinux" alatt is megy ez. Csak akarni kellene.

Azert azert elfelejted, hogy volt swaped bőven, azaz nem 1.5 giga memóriád volt. Ekkor az OOM killer működésbe sem lép, hiszen van még virtuális memória bőven. Allokálj mondjuk 32 GB-ot.

" In mode 2 (available since Linux 2.6), the total virtual address space on the system is limited to (SS + RAM*(r/100)), where SS is the size of the swap space, and RAM is the size of the physical memory, and r is the contents of the file /proc/sys/vm/overcommit_ratio."

A test gep i686 volt, milyen 32G -rol beszelsz ?
32G -t megtagadna a rendszer egyebkent overcommit_memory = 0 -val is. Az max Swap+RAM itt is limit.

overcommit_memory = 1 szinte barmit mallocol, most foglaltam 127TB -t vele laptopon (64bit) :),
mivel malloc nem jelent commitot, az OOM killer -t nem erdekli, ha fel akarnam ebreszetni, akkor 4k tavolsagokban 1 byte irasa a lefoglalt teruleten segithetne.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Pl. adjon vissza hibaüzenetet, aztán a program döntse el, hogy mit tud vele kezdeni. Windowson is futottam már bele abba, hogy kevés volt a ram, mit ad isten, kaptam egy OutOfMemoryException-t a képembe, amivel még lehet kezdeni is valamit.

De sebaj, javaslom szüntessük meg az out of space hibaüzeneteket is azzal, hogy elkezdünk véletlenszerű fájlokat törölni a lemezről, mint ahogy azt már itt más is említette.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Általános célú használat esetén az OOM-killer, illetve az overcommit nem okoz problémát - ha meg olyan a felhasználás, hogy igen, akkor tessék a gépbe ramot pakolni, swap-ot növelni, illetve a per default overcommit-ot tiltani. RDBMS alá egyébként is illendő a kernelt megfelelőre hangolni...
De ahogy szó volt róla, az OOM-killer általi kigyilkolástól védhetőek a folyamatok (-17).

Na de látod, akár hányszor megemlítem az OOM killert bármi negatív kontextusban, egyből nekem esnek.

(Azt teljesen ignorálva, hogy a baj itt az OOM killer + hash index használatából eredt, sajnos a pg hash index implementációja olyan, amilyen. De legalább adatvesztést nem okoz, csak épp a queryk nem mennek :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Na de látod, akár hányszor megemlítem az OOM killert bármi negatív kontextusban, egyből nekem esnek.

Mert nem végezted el a házi feladatod - az OOM killer megismerését - aztán meg háborogsz. Pedig dögivel vannak leírások róla.

Adottság a rendszer, amin dolgozol. Esetedben teljesen irreleváns, hogy rossz ez így defaultként, alkalmazkodsz, jobbat nem tehetsz, nincs igazán beleszólásod. Vagy használsz más OS-t.

My two cents.

Nem, ez egy jo megoldas, hogy a geped ne fekudjon le mert keptelen vagy ertelmesen beallitani. Nem az applikaciod/adataid vedelme a fo szempontja, az elszabadult processzek monitorozasara pedig van megfelelo tool, az oom killer nem erre van.

// Happy debugging, suckers
#define true (rand() > 10)

Nem tudom te eppen kinek az aktualis reinkarnacioja vagy, de amikor még 2.2 kernel volt, valóban ifjonc voltam és talán freebsd ?<3.4? -et használtam. Az elszabadult processz meg egy baromi tág fogalom, ha valami bezabálja a mem-et es egy masik process rendetlenkedik ezen oknal fogva, akkor bizony a masik processz lesz kilove. Itt jon az, hogy szarul konfigoltal, az oom killer meg tette a dolgat

// Happy debugging, suckers
#define true (rand() > 10)

Az adatintegritas erdekeben az eszkoz miert olyan default beallitasokkal jon, ami ez ellen van?
Ez elegge nagy luzerseg.

Magyarazd el peldaul egy magyar szakos bolcseszenk, hogy miert veszett el a szakdolgozata az OOM killer miatt.

Ot ez kurvara nem erdekli. Hasznalni akarja a rendszert, hiszen azt mondtak neki, hogy a Linux jo, felhasznalobarat, kenyelmes es ingyen van.

Lofaszt. A Linux egy kiserleti rendszer, informatika irant melyebben erdeklodoknek. Ezert sem lesz Linux desktop eve sosem.

Mert nem használsz faszkorbácsot* :) (* Gentoo régebbi hardware-en ;))

EDIT: nem szükségszerűen régebbi, hanem gyengébb, és igen, természetesen azt is meg lehetne ettől többféleképpen is védeni, ellenben durrbele üzemmódban bizony ráfut... (ami végső soron ilyenkor bizony PEBKAC)
------------------------
Program terminated
{0} ok boto
boto ?

Nem az OOM-killer miatt fogja elveszteni a szakdolgozatát (Az jobb, ha a szerkesztőprogram nem tud memórát allokálni, és amiatt dől a kardjába?). Tetszőleges normális editorban van autosave lehetőség, ráadásul a normálisabbak ezen felül is képesek összeomlás (vagy összeOOMlás) után helyreállítani valamelyik nem túl régi állapotot.
Normál desktop használat esetén én még nem találkoztam OOM-mal, de lehet, hogy csak én vagyok ilyen szerencsés :-) viszont Tomcat, WebLogic, Oracle motyók, meg más "nagy fogyastók" futtatására szolgáló, nem nagyon hangolgatott gépeken annál inkább. De jól felügyelt/beállított rendszer esetén ott is ritka.
Az, hogy a memóriaallokáció így viselkedik, az a kernel tervezése során alakult így, a pontos részletekért, pro és kontra érvekért szerintem a megfelelő fejlesztői levlista archívumában keresgélj.

És ha az OOM killer azért lövi ki, mert a mentés készítése során nem volt elég ram? :)

"Az, hogy a memóriaallokáció így viselkedik, az a kernel tervezése során alakult így, a pontos részletekért, pro és kontra érvekért szerintem a megfelelő fejlesztői levlista archívumában keresgélj."

Hja értem, szóval fingod nincs, hogy miért jó(?) ez a megoldás, csak így működik a linux és akkor ez biztosan jól van így. Még ha egyetlen másik rendszer se így oldja meg a problémát, pedig van egy-két OS a világon.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az OOM nem normál rendszerállapot, az a "vészkapcsoló", amikor már nincs más eszköz az OS kezében a rendszer működésének legalább részben történő fenntartásához. Anno RDBMS-es témában az volt a mondás, hogy teljesen mindegy, hogy emnnyit swappel a gép, a gond az, hogy egyáltalán swap-et használ. Nálad nem csak swap-et használt, hanem a teljes rendelkezésre álló memórát+swap-et felzabálta. Ez _sem_ normál üzemállapot, erre is illik odafigyelni, és ha kritikus szolgáltatást nyújt a gép (ráadásul olyan szoftverrel, amiről lehet tudni, hogy a használt konfigurációban (hash indexet használva) az indexek integritása nem garantált, ha nem szabályosan áll le az RDBMS), akkor tessék monitorozni, figyelni a terhelést, nem csak a pillanatnyit, hanem a trendeket: hogyan változik napon belül, heti, havi vagy akár éves szinten az erőforrások kihasználtsága.

Igen,. fingom sincs, hogy miért döntöttek így a kernelguruk,d e nem is érdekel az ok - nem vagyok kernelfejlesztő, csak üzemeltetek, ergo A Linux ezen tulajdonságával együtt kell tudni élni - és együtt is lehet, hiszen van rá mód, hogy másképp viselkedjen. Nem mondtam, hogy jó, csak azt, hogy hozzáértőbbek döntötték el, vélelmezem, hogy kellően sok érvet figyelembe véve. (Az biztos, hogy így faék egyszerű, ergo erőforrás-használatban kellően takarékos megoldásról van szó, ami fontos is - gondolkozz el rajta, mikor fut a vizsgálat, hogy OOM van-e, és ki kell-e lőni valakit, és ha igen kit?)

Nálad okosabb, hozzáértőbb emberek döntötték el, hogy így működjön alapértelmezetten a Linux.
És csak ismételni tudom: általános használat esetén nincs ilyen gond, az RDBMS üzemeltetése egészen más memóriakezelési beállításokat igényel, illetve igényelhet.
Illik utánaolvasni, a várható igénybevétel alapján méretezni a gépet (cpu, ram, swap, storage, hálózat), hangolni az OS-t, üzem közben pedig figyelni, hogy a tervezett erőforrások és a valós igények mennyire esnek egybe.

Azt kell látni, hogy saxus szoftverfejlesztőként gondolkozik, ti meg üzemeltetőként. A különbség a következő:
Szoftverfejlesztő: ha valami szar, de finomhangolható, javítsuk meg vagy legalább állítsunk be értelmes alapbeállításokat (pl. opt in legyen az overcommit szerver disztribúciókon ne opt out).
Üzemeltető: ha valami szar, de finomhangolható, akkor állítsuk be magunknak úgy ahogy nekünk tetszik mindig mindenhol.

A magam részéről azt nem értem, hogy az oom killer miért nem tudja azt jelezni a process felé, hogy elfogytak az erőforrások, miért kell mindjárt kill signalt küldeni.

OOME akkor történik, amikor a JVM nem tud a heapen már memóriát allokálni. Ettől még a JVM process számára lehet több elérhető memória, csak éppen limitálva van a heap mérete, mert ugye JVM alatt azt is lehet. Ha meg natív kódban történik egy memóriaelszállás, akkor elszáll a JVM.

Ez is egy lehetséges megoldás, én úgy tudtam (de sajnos most forrást nem találok), hogy az ezekhez szükséges memóriaterület rendelkezésre áll a process teljes életciklusa alatt, így ezeket az objektumokat létre lehet hozni amikor elfogy a memória. Ugyanezt a startégiát alkalmazhatná a linux kernel is.

Bár ha kill signalt tud küldeni, akkor másmilyet miért is nem? :)

A magam részéről azt nem értem, hogy az oom killer miért nem tudja azt jelezni a process felé, hogy elfogytak az erőforrások, miért kell mindjárt kill signalt küldeni.

developers, developers, developers, ... Te is developer lenni, igaz? Koltoi kerdes volt...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Ez mind szep es jo, de az OOM pont a szar programozok ellen valo... illetve pontosabban arra, hogy a szar programozok altal irt ultrafontos program tudjon futni. Egy program fontossaga es a fejlesztoi minosege kozott ugyanis semmifele relacio nem letezik.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Mert nem mindenkinél, sőt, az esetek döntő részénél NEM olyan a workload, hogy az overcommit, illetve a nem letiltott OOM-killer problémát okozna.
Ja, és ha megnézed, az oom_adj nem csak két értéket vehet fel, ergo lehet hangolni, hogy melyik processz (és leszármazottai) milyen esélyt kapjon a túlélésre kritikus memóriahiány esetén.

Ez a te véleményed, akik meg kitalálták, azok szerint meg nem az - ők ott vannak a Linux kernel fejlesztésével kapcsolatos döntésekben - és nem véletlen, hogy ilyen egyszerűen implementálható, erőforrásigényt tekintve nagyon olcsó (kevés cpu, ram és órajelciklus kell hozzá) megoldást adtak a "minden memória elfogyott, mit csináljunk?" probléma feloldására.
Nem hack kell, hanem az OS ismerete és az ahhoz való megfelelő idomulás. Ha valaki ezt nem tudja/akarja megtenni, akkor ne tegye, hanem írja elő, hogy az overcommit lehetősége teljesen legyen kikapcsolva, és legyen a gépben a hasonló felhasználásra összerakott rendszerhez képest (jóval) több memória. Ja, és lehetőleg a copy-on-write is legyen eliminálva a rendszerből, ami azért picit távolabbra vezet - és performacia szempontjából sem biztos, hogy hasznos.

Érdekes, hogy más UNIX rendszerekben nincs OOM killer. Mégis működnek. Mily érdekes.
Igen, nem hack kell, hanem a szoftverek megfelelő kiszolgálása: ha az OS overcommit mellett dönt, akkor swapeléssel oldja is meg. Ha egy program pedig több memóriát kér, mint amennyit a VMM biztosítani tud, szépen mondja meg a szoftvernek, hogy nincs több memória.
Ennyike.

Az OOM akkor sül el, amikor már swap sincs, az overcommit meg arról szól, hogy a valóban rendelkezésre áló memóriánál többet is lehet foglalni - például akkor, amikor egy nagy processz forkol egyet úgy, hogy a rendelkezésre álló szabad ram+swap kevesebb, mint a processz teljes mérete. És mégis működik, sőt, működni is fog, mert belép a copy-on-write, és kiderül, hogy a child (és a szülője is) az esetek döntő többségében csak a számára előjegyzett memória töredékét írja, a nagyobbik részét csak olvassa. Persze abban az esetben, ha az egyikük a memóriát elkezdi erőteljesen írni, akkor kifut a gép a memóriából, és valakit ki kell onnan tessékelni - na ezt csinálja az OOM-killer.

A copy-on-write jó dolog, (a fork futási idejével és memóriával spórol), gyakorlatilag ezt is ki kéne hajítani/át kéne írni, hiszen jórészt értelmét vesztené, ha nem lenne overcommit.

Te azt szeretnéd, hogy ne legyen overcommit, csak annyi memóriát osszon ki a rendszer, amennyi ténylegesen rendelkezésre áll. Ez a működés is beállítható Linuxon, de általános esetben a memória pazarlásához vezet, haszna pedig nagyon kevés - ergo alapbeállításként nem így működik az OS.

Az a baj, hogy az overcommitba nem szabad beleszámolni a swap területét. Mivel ha beleszámoljuk, akkor tényleg igaz az, hogy az OS több memóriát (nem csak fizikait, hanem virtuálisat) adott ki a processzek számára (azaz ígért meg), mint amit teljesíteni tud valójában.
Ugyanis lehet nyugodtan overcommit, de a rendelkezésre álló VM méretnél többet nem szabad kiadni. Például van 300 db 50 MiB memóriát kérő, de csak 20 MiB-ot ténylegesen foglalaló processz egy 4 GB tényleges RAM-mal és 8 GB swap területtel rendelkező gépen.
Ekkor minden processz megkaphatja a maga memóriaterületét nyugodtan, ugyan szabad RAM már nincs (300*20 MiB > RAM mérete), swapelés van (2 GiB), és probléma sincsen (hiszen még van szabad swap terület, amire nem írt még processz), még akkor sem, ha minden process el is kezdi kihasználni a neki megadott 50 MiB-ot - tegyük hozzá, teljes joggal, hiszen ennyit kapott a rendszertől.
Azonban amikor már a swap + ram területénél is több van kiajánlva a processzeknek és azok el is kezdik azt használni, akkor baj van.
Fel kell fogni, hogy minden erőforrásnak van határa, és a kernel feladata azt biztosítani, hogy minden processz élhessen azokkal az erőforrásokkal, amit a kernel neki már biztosított a múltban (és nem a jelenben, azaz fork után stb). Ha ezt nem tudja megtenni, akkor az rossz erőforráskezelés a kernel részéről. Erre nem az OOM killer a jó válasz.

Tehát azt mondod, hogy ne legyen overcommit _soha_ (beállítható), ergo egy fork is csak akkor legyen sikeres, ha a forkolt processz számára allokálttal azonos méretű szabad memória rendelkezésre áll - amiből bőségesen lesz olyan, amit mindkét processz csak olvasni fog, ergo a cow miatt fölösleges duplán lefoglalni - pazaroljuk a memórát, mert abból olyan k. sok van mindíg és minden körülmények között...

Az, hogy mikor és melyik processzre sül el az OOM, az is hangolható, per processz tiltható - mivel általános célra használt OS esetében nem jellemző, hogy üzemszerű működés során "elsülne" az OOM-killer (ellenben a fork-overcommit-cow sorozat rengeteg alkalommal), így akinek az kell, hogy ne így működjön, az tegyen róla, hangolja úgy a futó folyamatok oom_adj értékeit, hogy a védettség a fontossággal arányos legyen.

Ahol cow van, de nincs oom-killer, ott OOM esetén más módon, de tarkónvág az OS egy vagy több processzt - a kiválasztási algoritmus az, ami másképp működik - Linuxon egyébként a select_bad_process() választ (mm/oom_kill.c), azt érdemes megnézni, hogy pontosan mi alapján és hogyan.

A feltétel az volt, hogy csak ténylegesen rendelkezésre álló memóriára számoljon az OS minden esetben. Ha fork esetében ezt nem teszi (azaz a child számára nem garantált, hogy az örökölt memória egészét használhatja r/w), akkor megint oda juthatunk, hogy elfogyhat a memória, miközben a processz azt hiszi, hogy rendelkezésére áll az örökölt méretben.

Igen, egy fork csak akkor legyen sikeres. Mivel a processz (főleg ha nem Linux-specifikus, hanem POSIX) nem ismeri, nem dzabad ismernie a kernel lelkivilágát az API szemantikáján kívül (absztrakció, platformfüggetlenség anyone?), így ha az OS azt mondja, hogy tessék fiam, ez a memória a rendelkezésedre áll, akkor az legyen is így.
Ajánlom elolvasni: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html szépen leírja, hogy a jelen helyzet így miért rossz.

Tegyuk hozza, hogy a preforkot irtani kellene, az ITK az egyetlen erv a lete mellett. Mondjuk en egy hibrid megoldast el tudnek kepzelni, ha kell, indit a usernek egy threadelos forkot, es ha az osszes thread idle, egy elore megadott ido utan kilovi a forkot, koszonjuk.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A felvetés arról szól, hogy a child nem csak "leőjegyezve" kap memóriát, hanem ténylegesen allokál számára a krenel, és maximum annyit oszt ki, amennyi memória a gépben fizikailag elérhető. Hiába a copy-on-write, a memória lefoglalásra kerül a ténylegesen rendelkezésre álló memória terhére, még akkor is, ha annak az érintett processzek (parentés child) csak egy pici részét fogják valójában írni (amit a jelenlegi megoldás esetén ténylegesen allokálni kell a ram-ból).

És pont ezért fogsz sírni, ha az apache/php kombó 12312312G memoriat igenyel, mikozben 2G-vel boven elvan. Meg lehet magyarazni a hulyeseget, de felesleges. Az, hogy overcommit van, teljesen jo dolog. Az, hogy az OOM killer lebassza azt a processzt, amelyik megboritani kivanja a gepet, teljesen jo dolog. Miert lenne ezekkel problema?
Sajnalod a lelott processzedet? Jobb volna ha beborul az egesz gep? Vagy nem tetszik hogy a linux daemonok nepes tabora fork()-ot hasznal, es 5 user helyett par ezret is ki tud szolgalni ha kell?

Ezek mind kikapcsolhato dolgok, de ha futtatsz eles szolgaltatast es nem csak a hulyeseget probalod megmagyarazni, akkor azokon a szervereken kapcsold ki legyszives. Ha meg nem teszed (megertem az okat), akkor meg ne sirjatok mar fogalom nelkul hogy ez igy szar

// Happy debugging, suckers
#define true (rand() > 10)

Magyarazd el nekem legyszives, hogyan intezed el, hogy egy thread mas user jogosultsagaival rendelkezzen, mint az ot szulo processz. Tegyuk rogton hozza, hogy a setuid()/setgid() processz-szintu, a kernel nem kezel ilyen ertelemben thread-eket.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ha megnezed, ezek a "nem ertem a letjogosultsagat" abbol erednek hogy "nem ertem az egeszet es ezert nem tudom a letjogosultsagat".
Szamomra egyertelmu, hogy egy thread miert nem futhat mas jogosultsaggal mint az azt szulo processz es hogy miert nem masoljuk le az egeszet, saxus megfogalmazasai meg inkabb a hozzaallasabol eredeztethetoek (lasd a topic indito. Nem allitottam be, nem ertek hozza, ezert szar az egesz. Ok-okozatba meg nem gondol bele, sir hogy meghal a processz ahelyett hogy orulne hogy nem a komplett gepet vitte a halalba.)

// Happy debugging, suckers
#define true (rand() > 10)

Nyilvan, de valamennyire az o szempontjai is erthetoek. Viszont en azt gondolom, hogy ezt a vitat nalunk hozzaertobb emberek mar lefutottak, talan nem is egyszer, es tenyleg az a problema, hogy egzakt megoldas nincs, nem is lehet. Talan egy jobban parameterezheto OOM viselkedes, vagy egy jobban konfiguralhato memoriamenedzsment jobb lenne, de meg erre se vennek merget a patikaban.

Off: kezdjunk mar uj szalat, egyre keskenyebb ez a box.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ha bevetel termelo eszkoz es nem egy sajat hasznalatu gep, akkor lehet celszeru megbizni egy hozzaertot aki beallitja normalisan. Ha olcso, hozza nem erto munkaerot alkalmaz az ember, akkor bizony elofordulnak a missconfiguration-bol szarmazo problemak

// Happy debugging, suckers
#define true (rand() > 10)

"Ha olcso, hozza nem erto munkaerot alkalmaz az ember, akkor bizony elofordulnak a missconfiguration-bol szarmazo problemak"

Akkor ismételten megkérdem, nekem, mint a rendszer felhasználójának, miért kellene elfogadnom azt a bullshit indokot, hogy JAJHÁMÉNEMÁLLÍTOTTADBE!, ha van sokkal logikusabb működési módszer? Mert eddig *semmilyen* érvet nem hallottam arra vonatkozóan, hogy miért ez a legjobb megoldás (legalábbis logika azt diktálná, ha már egyszer ez a default) és miért nem az, hogy az utolsó processt gyakja le, ha már nagyon nincs más?

Ehelyett kaptam egy jó adag személyeskedést.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A bacogatást a rendszer hangolását, üzemeltetését végzőnek címezd. Ugyanis lehet úgy is üzemeltetni, hogy nem, vagy csak marha ritkán (és akkor sem a kritikus komponenseket érintve) találkozik az ember OOM-mal.
Hogy miért úgy választ a kernel, ahogy, arra az a válasz, hogy olvasd el, és értsd meg az algoritmust, ami választ. Van sok erről szóló, igaz, angol nyelvű oldal, ahol elmagyarázzák, hogy mi miért és hogyan működik.

Annak az 1%-nak azért nézz utána :-P Nincs sok tapasztalatom, hiszen csak 1994-ben kezdtem Linuxozni (bár azóta nem nagyon volt olyan, hogy néhány Linuxos gépet ne kellett volna tutujgatnom, illetve ne használtam volna Linux-ot), és amikor nagyon-nagyon ritkán OOM-ba futottam, akkor az esetek döntő többségében az derült ki, hogy alkalmazásban van valami elqfva, vagy épp a fejlesztők által megadott memóriaméret legfeljebb a funkcionális tesztekre elég, éles üzemben "picit" több kell. És ez igaz a desktop-jellegű felhasználásra (bár ott nem is emlékszem, hogy lett volna az oom-killer elsüléséig durvult memóriaelfogyás) ugyanúgy, mint kifejezetten kiszolgáló alkalmazások futtatására összerakott gépen.

Azt mondod, hogy "desktopot nem szokás üzemeltetni". Lophact. Már bocsánat. Otthoni, játszós, telepít-letöröl tesztelős, nem baj, ha szétmegy gépet valóban nem - üzletileg kritikus eszközt viszont igen. Legalább annyira, amennyi veszteséget jelent, ha összehányja magát.

Az analfabéta, vagy csak diszlexiás felhasználó meg tökéletes alanya a PEBKAC jelenségnek, ha nem akar tanulni, akkor n+1. alkalommal is pofára fog esni, és n+1 alkalommal is hülyének lesz nézve - méghozzá joggal. Ha meg egy rendszert használni akar, akkor válasszon a saját szintjéhez passzoló valamit, mondjuk egy olyat, ahol egy darab, egész képernyőt betöltő gombot kell eltalálni és rákattintani :-P

http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=…

Linux 1.34%.

" üzletileg kritikus eszközt viszont igen." Az workstation. És azt valóban üzemeltetik, Windows alatt is, OS X alatt is, Linux alatt is. Én is egy központilag üzemeltetett Linux notebookot használok munkában és ez jól van így, mert más ideje megy el az üzemeltetéssel és nem az enyém.

Ad1, ez desktop. Ad2, nagyon nem lehet látni, hogy pontosan mi alapján, hogyan mérték.

Megsúgom, hogy normális helyen a "desktop" gépek üzemeltetésére is odafigyelnek - OS-frissítések, alkalmazások központi telepítése/frissítése, vírusvédelem és más biztonsági megoldások központi felügyelete, szükség esetén mentések/visszatöltések elvégzése, stb.

"és amikor nagyon-nagyon ritkán OOM-ba futottam,"

Jé? Belefutottál OOM-be? BIZTOS NEM KONFIGOLTAD!!!4444 Hülye vagy hozzá, minek használtál Linuxot, ha nem értesz hozzá!!!

Komolyra fordítva: az egész topic még mindig onnan indult, hogy a fenti három dologgal (oom+pg+hash index), belefutottunk egy olyanba, amitől megállt egyszer a rendszer. Azelőtt negyed évig (amióta van hash index kb.) ment. Azelőtt meg vagy nem vettük észre az OOM killer működését vagy nem ment. Gondoltam kirakom, mert másnak hasznos infó lehet és, hogy más előre készülhessen, ha hasonló kombinációt tervez.

Persze, ahogy vártam, jönnek a linux zélóták és egyből elkezdtetek "jajsaxusdevopkodiklololol"-ozni, ahelyett, hogy egy icipicit megpróbálnátok nem csak a saját kis (nekem egyre inkább beszűkültnek tűnő) világotokból szemlélni a dolgotokat, hanem felhasználói oldalról is. Abból meg nem engedek, hogy egyelőre nem én vagyok a rendszerért.

"vagy épp a fejlesztők által megadott memóriaméret legfeljebb a funkcionális tesztekre elég, éles üzemben "picit" több kell."

Erre meg már ezerszer elmondtam a magam véleményét: adaptív működés kell. Az, hogy minden kis piszlicsáré konfig opciót valaki kézzel konfigolgasson az két okból nem fog működni:
- egyrészt nem hatékony (nem skálázódik az aktuális terheléshez)
- másrészt tapasztalatom alapján az ilyen konfigolgatások inkább reaktív, mint proaktív módon szoktak történni.

Harmadik indok, hogy növeli az üzemeltetési igényeket (ezáltal a költségeket is), ami megrendelő/felhasználói oldalról ellenérdekelt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A problema az, hogy te eszkalaltad a problemat. Igen, sajnaljuk, hogy ilyen szopasba beleszaladtal, gyere, es sirj a vallunkon, megvigasztalunk, ne felj. Az viszont, hogy utana elkezdted ekezni, hogy "miert igy mukodik, mikor mukodhetne ugy is", abban vagy nem ereztetted elegge, hogy a kerdes pusztan koltoi, vagy pedig nem koltoi kerdesnek szantad. Ennekokan en nem gondolom, hogy csodalkozni kell azon, hogy radszabadult a trollok es kevesbe trollok tobbsege. Foleg miutan elkezdtel dolgokat ugy osszehordani, hogy mint bebizonyosodott, keves volt a tudasod a vitahoz. Nem hibaztatlak erte, az enyem is keves lett volna, de en nem hajtottam volna ennyire a sajat igazamat szel elleneben, mikor mar tobbedszerre bizonyitjak be, hogy ugy itelek, hogy nem megfelelo a tudasom szintje. Te viszont a becsuleteden esett serelemnek vetted, es betamadtal. Most pedig itt vagyunk.

Szerintem hasznos lenne most lehiggadni, atgondolni, utanaolvasni a dolgoknak, es utana, tiszta fejjel nekiugrani a vitanak - ha meg van ertelme.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

" Az viszont, hogy utana elkezdted ekezni, hogy "miert igy mukodik, mikor mukodhetne ugy"

Persze, hogy elkezdem ekezni, hogy miert ez a default, ha egy masik rendszerben sincs ilyen, hogy random másik processt lő ki. És ha picit visszaolvasol, itt sem hangzott el senkitől sem egyetlen egy érv vagy link sem arra, hogy miért ez a legjobb megoldás, csak az, hogy jajmértnemnézelutána. Utánanéztem. Annak is, hogy máshol mi a helyzet. Valahogy egy nagyságrenddel kevesebbet volt téma más rendszereknél az OOM helyzete, mint a Linux OOM killer. Biztos azért, mert csak én vagyok az egyetlen a világon, aki vitatni meri a működését

"Szerintem hasznos lenne most lehiggadni, atgondolni, utanaolvasni a dolgoknak"

Megtörtént, nem találtam értelmes választ. Ezután konzultáltam még másokkal, akik OS-t fejlesztenek, de úgy néz ki, ők is hülyék, mert szerintük is fasság, hogy random másik processt lő ki.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ez a default, de nem az alapértelmezett beállítás a hülye, már bocsánat, hanem az, aki a _dokumentáltan_ veszélyes állapotban hagyja. (mert valahol mintha írtad volna, hogy a hash index mellett nem jó ötlet kill szignállal megküldeni a pg processzeket.
Ilyenkor nem a post mortem anyázás a megoldás, hanem az, hogy tanul az admin belőle, és vagy rakat még memóriát a gépbe (mert láthatóan kevés, nagyon-nagyon kevés), ad hozzá swap-ot, ÉS jól -17-re állítja a pg indítóscriptjének némi kiegészítésével az oom_adj értékét, oszt' jónapot :-P

Nem tudom, mit fejlesztenek az ismerőseid, de a "random processzt lő ki" de facto marhaság - talán én is adtam linekt a megfelelő kódrészletre, ami kiválasztja, hogy melyik processz legyen a "szerencsés". Véletlenül sem random, de gondolom ennek sem néztél (és ők sem néztek) utána.

Mint ahogy a kekhalalt sem ertik meg a userek, de idonkent elofordul. OOM killerrel pedig kevesebbet talalkoztam mint kekhalallal. Nem teljesen ertem sem a threades, sem a forkos, sem a mallocos csipogast, de aki nem erti ezeknek a mikentjet, hat, nah...

// Happy debugging, suckers
#define true (rand() > 10)

"Bár egy jól méretezett gépen azért az OOM ha nem is a fehér holló, de azt megközelítő gyakorisággal előforduló jelenség..."

Eleve nem értem, hogy honnan haluztátok be, hogy rendszeresen OOM killerekbe futunk, főleg miután szerintem írtam is már valahol, hogy x hónap után most futottunk bele ebbe. Csak nektek egyszerűbb előbb fikázni és utána informálódni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Senki nem irta hogy lepten nyomon OOM killerbe futsz. Mi csupan erre reagaltunk:
"OOM killer, fuk u!"
Mert ez olyan, mint amikor idegbol belerugsz a falba es lehulyezed, hogy miert ilyen kemeny. Szerinted ki a hulye? Ne valaszolj, koltoi kerdes, a te allaspontodat nagyon jol tudjuk a keskeny dobozkakbol kiindulva

// Happy debugging, suckers
#define true (rand() > 10)

Apropó, hol írtam olyat a fork()-ra, hogy "nem ertem a letjogosultsagat"? Azt mondtam, hogy nem a legértelmesebb ötletnek tartom.

Az OOM killerre se írtam, hogy a létjogosultságát nem érteném, hanem a működését vitatom.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A setgid/setuid nem fog tokeletes megoldast jelenteni. Egyreszt nem tudod threadekre alkalmazni, masreszt mindig lesz kapcsolata az eredetileg futtato userrel (ha root az, akkor azzal). Ahhoz, hogy a "dropping privileges" kategoria tokeletes osszejojjon, egy double fork kelleni fog

// Happy debugging, suckers
#define true (rand() > 10)

Szerintem persicsb arra gondolt hogy az overcommit a rendelkezésre álló memória + swap space méretéig legyen elérhető. Így ha hirtelen az összes process teleírja az összes rendelkezésre álló memóriaterületét, akkor még pont nincs szükség OOM killerre. Swap space növelésével bármikor növelheted a virtuálisan rendelkezésre álló memória méretét, miközben a gyakorlatban akár a fizikai memóriában is elférhet az összes valóban használt memória.

Különböztessük meg a fizikailag és logikailag elérhető memóriát. Fizikailag van pl. 4GB ramom, de betolok alá még 8GB swap space-t, akkor logikailag 12GB memóriám van. Persze a fene sem akar ezen a gépen 4GB-nál több memóriát használni, de nem is kell mert az overcommit miatt úgysincs kihasználva a teljes lefoglalt memória. Viszont ha hirtelen az összes process úgy dönt, hogy márpedig teleírja a kapott memóriaterületét, akkor sem fog kifutni a rendszer a rendelkezésre álló logikai memóriából, igaz 8GB-ot swap space-ből fog biztosítani.

egyreszt ez nem (csak) az en velemenyem, hanem tobbeke is. Masreszt nem arrol van szo, hogy en nem ismerem (ezt) az os-t, hanem arrol, hogy a koncepcio (=mindig azt kamuzom, hogy van memoria, aztan ha mar nyakig er a kaki, akkor kinyirok par processzt, jobb a bekesseg alapon) maga egy nagy kalap kaki. A helyes megoldas tehat az, ha adsz az alkalmazas ala eleg (fizikai) memoriat, aztan ha mar nincs tobb (kioszthato) memoria, akkor azt az *alkalmazas* mindenfele hack nelkul korrekt modon tudja kezelni. Te erted ezt a kulonbseget?

Btw. a cow nem linux-specifikus feature, van ahol overcommit nelkul is meg tudtak oldani (pazarlas nelkul)...

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Linus már több ízben kifejtette, hogy szarik az userlandra, őt csak a maga kis elefántcsonttornya érdekli. Szóval bocs, hogy nem adok a véleményére. Egyelőre úgy vagyok vele, hogy az OS legyen értem, ne én az OS-ért.

BSD-kben is van overcommit, nem az overcommittal van baj. Hanem azzal, hogy egy totál random programot fog legyilkolni az OOM killer. Érdekes módon, BSD-kben és Windowsban valamiért azt a megoldást választották, hogy az utolsó process húzza a rövidebbet, mert a tapasztalat az, hogy általában az a helyes megoldás. OSX meg felajánlja, hogy mit lőjj ki (oké, ezt desktopon lehet max megcsinálni.)

Ezzel szemben a Linux meg olyan, hogy ha elkezd üszkösödni a láb, akkor levágja először a két lábat, a fejet majd a másik lábat...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Linuxon mondjuk konfiguralhato lehetne, hogy mit oljon meg alapbol, ilyen nagy generikus opcioval (= kernelparameter), az overcommittalo appot, az utolsot, vagy csak ugy random. Egy csomo esetben ugyanis hasznos a haracsolokat megolni, egy csomo esetben meg az ingyenelo tomeget erdemes gyilkolaszni.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

>Egyfelől ez igaz, másfelől elgondolkodtam, hogy egy OOM határhelyzetében álló rendszerben nem okozna-e még nagyobb szívást, ha elkezdünk leak után vizsgálódni.

bárcsak lenne egy pentium 1-em, ami már elég gyors az ilyen Kompleksz Műveletekhez!

(a nagyonfontos drupálpéhápék és myiszap adatbaze kverik szüneteiben)

Kiloves helyett lehet sok swapet hasznalni es amiatt lesz a rendszer elerhetetlen, hogy `csak` swappel.
Ilyenkor elofordul, hogy `tul lassu` -rol hamarabb jon egy alert, mint hogy az OOM killer aktivalodna.

Nincs tokeltes strategia az aldozat kivalasztasara. Ha mondasz egyet ami mukodott volna pont a te estedben es meg nem is kerul sokba, mas esetben
roszat valasztana.
ulimit-el vagy cgroups-al lehet limitalni, hogy egy-egy process vagy process csoport mennyit ehet max. Es az aldozat az a process lesz vagy abbol a csoportbol kerul ki (SIG11).

OOM killer rendszerint nem akkor jon amikor a memoria alokolva lett, hanem amikor commitolodna, vagy vissza jone swapbol vagy hasonlo. Az alkalmazas nem sok mindent tehetne egy `csokentsd a memoriat` keresre random helyen ill. a kernel sem szamithat arra, hogy az alkalmazas jo fiu lesz es vissza ad memoriat.

Lassan szivargo memoriat lehet monitorizni es megfelelo lepest megteni, egyszeru all-in-one rendszernel pl. monit is hasznalhato automatikus ujra inditasra is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Fejlesztettem - üzemeltettem alkalmazást Linuxon (évekig) ami PostgreSQL -t használt, soha semmi ehhez mérhető problémája nem volt. Vagy valamit elrontottam.

--
arch,centos,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Probléma az, hogy az OOM Killer nem azt fogja meg, ami elszabadul, hanem valami mast. Chris tudna meg mesélni neked errol sokat, pl. mikor megszakadt az általuk üzemeltetett cucc, aztán elkezdett az OOM Killer maga korul szepen mindent lelőni, majd vegul abba pusztult bele a leakelo program, hogy az OOM Killer kilőtte alóla a MySQL-t.

Harmadrészt, hash indexeket is hasznaltatok vagy csak btree?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

# Limit process memory:
$ ulimit -v 100000
$ python -c 'a=" " * 100000000'
Traceback (most recent call last):
File "", line 1, in
MemoryError

$ ulimit -u 1024
$ :()(:|:);: # Fork bomb do not try it

bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: No child processes
bash: fork: Resource temporarily unavailable
Terminated

# system still alive

See also:
http://linux.die.net/man/5/limits.conf
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
http://www.freedesktop.org/software/systemd/man/systemd.resource-contro…
http://www.freedesktop.org/software/systemd/man/systemd.exec.html
http://www.psce.com/blog/kb/how-to-adjust-oom-score-for-a-process/

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

osszefoglalom: oom killa nagyon jo es kell, mert csak tudni kell konfigolni (ti. kikapcsolni)

#bancsakalinuxot

--
NetBSD - Simplicity is prerequisite for reliability

Így legalább el lehet mondani, hogy aki tudja megfelelően kezelni a SELinuxot, az ért az OOM Killerhez is. ;)

De ha engem kérdeztek:
1. Az alkalmazás szeretne kérni egy kis memóriát, de nincs
2. Az oprendszer visszaszól, hogy ácsi.
3. Az alkalmazás lekezeli a helyzetet.
3b. Ha az alkalmazás fejlesztője egy kontár, és nem kezelte le a helyzetet, akkor az alkalmazás összeomlik, de csak az, nem egy ártatlan processz, amit random választ az OS.

Mennyi swap ill. RAM volt a gepben, volt -e SSD ?

Most eppen egy kollegammal sorozok es az o problemaja, hogy az OOM killer nem ebred fel, hagyja rendszert vergodni I/O -ra varva (nincs SSD a laptopjaban).

8 GB memoriaja van, 6G tempfs -be tett hogy egy jatek gyorsabban toltson wine alatt, ill 1G swapje van.
Valahol a hataron lehet.

Szeretne valamit ami memori pressure , vagy free+cache size alapjan kiirtana, a legnagyobb memoriaju processt es a rendszer responsive maradna.

Valami C/Go deamonon gondolkusink, ami peridikusan nezne valami erteket procban.
A kerdes az hogy melyiket, es mi volna a jo treshold a pre OOM killre.

szerk:
https://github.com/rfjakob/earlyoom .. talan.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.