FATAL: the database system is in recovery mode

 ( saxus | 2015. február 2., hétfő - 12:16 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

/etc/sysctl.conf:
vm.oom-kill = 0

?

KAMI | 神
Firefox OS: https://is.gd/fxoshu Linux Mint: http://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes!

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.

+1, szarul hasznalni mindent lehet, itt tobbszorosen is sikerult


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

ugy erted, Linuxon (1), PostgreSQL (2) es hash indexek (3)? Btw. mindig orom saxus ops kalandjait olvasni ;-)

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

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

+1, egy ilyen hasonlatot kerestem;)


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

Miért kell kidobálni? Miért nem lehet megtagadni a belépést?

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

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)

O annak az aldozata, hogy egyaltalan letezik az OOM killer. Erdekes, hogy csak Linuxon letezik.

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 ?

Ha egy alkalmazást kiszolgálsz, és azzal legyilkolod a rendszer erőforrásait, és emiatt kilősz egy másik alkalmazást, az számomra nem éppen azt jelenti, hogy a kilőtt alkalmazás az OS-sel szemben prioritást élvez.

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 ?

nem említhető egy napon ezzel a

a kifejezes, amit kerestel: egy lapon ;-)

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

Teljesen jogos :D 10q! (természetesen releváns hozzászólás volt ;))

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

tl;dr:

>Nem tudom
>nem is érdekel

Kinőttem abból a korból, hogy "mindent tudni akarok" :)

azert egy on demand paging es a random processt kilovunk kozott van kulonbseg

--
NetBSD - Simplicity is prerequisite for reliability

Ha elsül az OOM killer, akkor már nincs hova kilapozni.

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?

Köszi, igen, ez így egy jó magyarázat. Látszik, hogy Java -ban fejlesztek. :)

--
arch,centos,debian,openelec,android

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

Ahol meg is lehet adni a minimalis heap meretet es a maximalisat is, ami az alkalmazas futasahoz szukseges.

Ja, csak ha elfogy a memoria, akkor altalaban az egesz alkalmazas lep ki kerdes nelkul.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

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

Illetve lehet használni SoftReference-t és WeakReference-t ha az adott feladat megengedi.

+1

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™

Ha nem adsz memóriát meg swap-et eleget a motyó alá, és nem figyeled, hogy hogyan áll a gép memóriával, akkor ne csodálkozz, ha megpróbálja öntevékenyen megóvni magát.

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

Hagyd.

Mintha ezt egy kis akaraterővel nem lehetne monitorozni. Bár továbbra sem látom a logikát amögött, hogy egy random processt lelövünk és ezzel potenciálisan megállítunk mindent.

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

Érdemes megismerni az OOM killer beállításait ezen háborgás előtt.

+1. Az OOM killer nem arra lett kitalálva, hogy az applikációid életben maradjanak


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

Nagyszerű, akkor a Linux sem arra lett kitalálva, hogy a szolgáltatásom életben maradjon. Még mindig nem tudott *senki* értelmes választ adni arra, hogy miért az OOM killer az egyetlen igaz, üdvözítő út.

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

Lovon fordítva ülés esete. Milyen megoldást látsz te az OOM killer helyett, ha már nem adsz elég memóriát/swap-et a gépnek? Mit csináljon a kernel, ha nem tud memóriát adni?

miert is kene adnia mindig memoriat? diszket is mindig ad ha kell? ethernet savszelt is? usb portok is teremnek csak ugy ha kell?

inkabb mondjuk programozni kene megtanulni...

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)

Nem mondja mindig, egyszeru pelda:

malloc(SIZE_MAX);

12 - ENOMEM - Cannot allocate memory

Fregmentalodas miatt is elfordulhat megtagadas, foleg kisebb address spaceu rendszereknel.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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.

Csak hogy szornyulkodhess:
http://en.wikipedia.org/wiki/Sparse_file
http://en.wikipedia.org/wiki/Thin_provisioning


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

RDBMS mellett is megszaladhat egy folyamat. Nem dedikált RDBMS szerverről van szó.

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

RTFM:"oom killer exclude process" És attól, hogy nem dedikáltan RDBMS szerver, attól még a memóriakezelést illendően úgy kell hangolni, úgy kell a gépet bővíteni (ram, swap) hogy megfeleljen erre a célra _is_.

"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."
Itt latszik, hogy nem igazan esett le, az oom killer mire valo.

Még mindig nem tudott *senki* értelmes választ adni arra, hogy miért az OOM killer az egyetlen igaz, üdvözítő út.
hat, mert nem az ;] es/vagy nincs ertelmes valasz.

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.

+1

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

"aztán meg háborogsz"

Mert ez egy fasz, ostoba, hülye megoldás. Akár be van állítva, akár nem.

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

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)

>az elszabadult processzek monitorozasara pedig van megfelelo tool, az oom killer nem erre van

de, erre van

csak te még ifjonc voltál a 2.2-es kernel idejében amikor még valóban így működött (jól)

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)

"Nem az applikaciod/adataid vedelme a fo szempontja"

OMG LOL. Az adatintegritás sokkal fontosabb, mint az, hogy mi van a géppel.

Igen, az adatintegritas megorzese erdekeben celszeru megtanulni, hogy normalisan be kell konfiguralni az eszkozt amit hasznalsz.


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

mondjuk en desktopon meg pont nem talalkoztam oom-mel...

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

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 ?

Egyedileg tákolt rendszer nem ér :-P

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.

"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."
Még jó, hogy a JVM által hasznátl memória korlátozható, de hát tudjuk, csak jól kell beállítani a rendszert....

Ja. Csak az a fránya fork() ne lenne... (egy JVM meg egy JVM az két JVM...) Az ulimit szépen elrendezte a dolgot, miután meg lett mondva, hogy mennyi az annyi.

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

> Illik [...] a várható igénybevétel alapján méretezni a gépet

Hát illeni illik, de ez már inkább utópia. ;) Nem igazán találkoztam még olyan szervezettel, ahol legalább néhányszor ne futottak volna bele az erőforrások határaiba.

Ha nem így lenne, akkor pedig túlköltekeztek volna, mert túl nagy hardvert vettek, és pazarolták a pénzt. Lásd a klasszikus félig üres-félig teli poharad: a mérnök szerint a pohár kétszer akkora, mint amekkorának lennie kellene.

Persze, értem én amúgy mindkét oldal érveit... :)

"Ha nem így lenne, akkor pedig túlköltekeztek volna, mert túl nagy hardvert vettek, és pazarolták a pénzt. "

Mert nem hallottak a virtualizációról. Ne legyen már ez érv 2015-ben sehol...

--
trey @ gépház

Virtualizált erőforrásból is lehet venni túl nagyot. Nem minden szolgáltatóra igaz az, hogy az igények függvényében automatikusan skálázódik a virtuális erőforrás.

Ami egy eleg szomoru teny, tegyuk hozza.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

Az OOM killer letezese is egy szomoru teny.

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.

És mégis milyen módon jelezze akkor, amikor a következő tényleges memóriafoglalást (amikor írni akar egy processz a memóriába) már nem tudja végrehajtani? Egyébként meg maga a folyamat tud az OOM ellen tenni, ha akar :-P http://hup.hu/node/138504

Szerinted a .net runtime és a jvm hogyan dob OutOfMemoryException/Error-t amikor elfogy a memória?

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

Nem teljesen... Hint: overcommit, copy-on-write fork után, és hasonlók. A kill-t nem tudod elfogni, a többit meg igen. És az OOM nem arról szól, hogy "léccilécci", hanem arról, hogy "parancsértettem".

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)

És ezzel azt akarod mondani, hogy...?

Más környezetben érdekes módon ez egy megoldott dolog, tehát biztosan nem lehetetlen megcsinálni rendesen.

Az osszes itt peldakent felhozott kornyezett virtualis gep alapu, tehat irrelevans nativ kodra. Valamit a temahoz?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

te is fejleszto vagy. Es ez most lesujto jelzo akart lenni...

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

Tevedsz, uzemelteto vagyok, csak megprobalom megerteni mindket oldalt. Nem egyszeru, meg kell hozza, tudod, empatia.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

valoban nem egyszeru, de az sem segiti, ha hulyeseget beszelsz...

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

Nativ kodban is van visszateresi erteke a malloc-nak, valamint lehet hasznalni garbage collectort nativ kodban is, lasd Boehm GC. Ott is megadhatod a heap maximalis meretet ( GC_set_max_heap_size hivas).
A szar programozok ellen valoban nem ved semmi.

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
()_()

Szar programozó ellen az OOM sem véd, hiszem OOM kill esetén létfontosságú adatod veszhet el, ha valóban ultrafontos a program és OOM kill áldozata lesz. Ezért is ajánlott mindenhol kikapcsolni.

s/mindenhol/ultrafontos programnál/ valahogy pl. így: https://github.com/mikechristie/open-iscsi/blob/master/iscsiuio/src/unix/main.c#L198

Programozói oldalról. De van, amikor a programozó ezt nem kezeli, és az üzemeltetőnek kell kikapcsolni azt, mert a programozó hanyag volt, és nem szeretné az üzemeltető, ha OOM kill esetén elveszne a fontos adat.

Ha nem látod, hogy nem C-nyelven hogyan kell megoldani, akkor nagy baj van...

És ha ezt minden app megcsinálja, akkor mi a létjogosultsága az OOM killernek?

Szoval ezt nekem kellene belepatchelni minden programba?

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

A sajatjaidba nem lenne rossz, mindenesetre :P
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

És akkor mi értelme az OOM killernek, ha minden kód tartalmazza azt, hogy kikapcsolja az OOM killert?

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.

Viszont az általad ajánlott kód szépen két értékre (az OOM kikapcsolására) állítja be azt. Miért várod el a programozótól, hogy ne arra menjen, hogy az ő processze bizony éljen túl?

| milyen esélyt kapjon a túlélésre

Nagyjából összefoglaltad, mi a baj az OOM-mel. Az informatika alapvetően mérnökszakma (kellene, hogy legyen), ott pedig egy ilyen megoldás, hát... elég meredek. Szerintem.

Az informatika mérnökszakma tud lenni, de a Linux egy kísérleti operációs rendszer, kevés előre tervezhetőséggel vagy stabilitással. Kísérleti terepnél meg ne csodálkozzunk, hogy ilyen dolgokat implementálnak.

Mint a duplapost? #verytroll
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

Az informatika mérnökszakma tud lenni, de a Linux egy kísérleti operációs rendszer, kevés előre tervezhetőséggel vagy stabilitással. Kísérleti terepnél meg ne csodálkozzunk, hogy ilyen dolgokat implementálnak.

Ha kritikus a szoftver, akkor a programozónak mondjuk így illene megoldani, ha meg nem oldotta meg, akkor is megoldható - ott van a C-kódban, hogy a procfs-en keresztül hogyan kell csinálni...

De azt már nem a programozó fogja megoldani, hanem az üzemeltető, hiszen az már deployment dolog.

+1. Az oom elleni hack NEM egy random fejleszto feladata. Az oom egy szar koncepcio...

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

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.

ha mar fork, akkor miert kellene (egeszen az irasig) allokalni a szulo memorialapjait a (gyerek szamara)?

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

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.

üzemeltetsz nagy forgalommal webszervert? Megsertodnel ha az apache benyeli a memoria 100%-at a workerek miatt, de igaz ez barmelyik masik forkolos daemonra (randomban valaszthatsz, a legtobb igy mukodik)


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

+1 Miközben a memória döntő részét csak olvasni fogja...

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
()_()

baromi igaz, de ez most inkabb apache specifikus esetedben, viszont nagyon sok masik daemon igy mukodik (aminek meg sok oka van hogy miert)


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

Igen, de keves olyan forkbomb daemon van, ami egyben _ennyire_ memoriazabalo tud lenni.
--
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)

Pont ezt magyarázom én is, hogy persicsb javaslata: "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" ordas nagy anyázásokhoz - és raklapszámra vásárolandó memóriamodulok tömegéhez vezetne.

Igen, kicsit rosszul fejeztem ki magam, csak a gondolatmenetet akartam kifejteni es igy esett ki belolem:)


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

Őszintén szólva számomra a fork() sincs még igazolva, mint a világ legértelmesebb ötlete...

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

nem tudom, de a hozzaszolasaid alapjan mintha feltett szandekod lenne hogy hosszutavon hulyenek nezzunk


// 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
()_()

"ahelyett hogy orulne hogy nem a komplett gepet vitte a halalba.)"

Baszhatom, hogy fut a Linux kernel, ha az OOM Killer elkurha azt, ami a bevételt termeli.

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

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.

Az ilyen hozzáállás miatt nincs a Linux elterjedtsége 1% felett. Ugyanis desktopot nem szokás üzemeltetni. Az "just works". És ott a felhasználó nem akar és nem is fog semmi olvasni, sem angolul, sem magyarul. Használni akarja a szoftvereket, működjenek.

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=10&qpcustomd=0

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.

Mondjuk most pont nem desktopról van szó, de amúgy igen, működjenek.

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

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)

És mi akadályozta meg a rendszergazdát abban, hogy az oom_adj értékét -17-re állítsa be? 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...

"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™

tartottalak annyira értelmesnek hogy érted miről írok

pl. a sete*id() hivasokkal?

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

Nah, itt latszik hogy tudsz dolgokat, viszont nem erted egeszeben.


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

?

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

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)

Ki beszélt itt threadekről? Csupán arról beszéltem, hogy nem vagyok meggyőződve a fork()-ról, hogy az lenne az egyetlen létező legjobb megoldás azokra a problémákra, amit megoldani próbál.

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

es errol beszeltem, hogy nem erted a rendszer egeszet, ezert nem erted. De kar ezt a vonalat tobb szalon is megerositened

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.

Ezzel az a baj, hogy ha az overcommit addig terjed ameddig van fizikai ram, akkor mar nincs ertelme az overcommit-nak mert az meg pont errol szol ezt a hatart ertelmesen at lehessen lepni.


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

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)

Ehhez az kellene, hogy az OS-t is, meg az alkalmazasokat is te irjad. IMHO.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

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
()_()

added

bookmarkolsz, hatha tanulsz vegre valamit?


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

A -17-tel vigyázni kell, mert öröklődik, úgyhogy például az sshd-t nem célszerű így felpimpelni :)

+1

NAME
leaks -- Search a process's memory for unreferenced malloc buffers

OS X, 2001

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. Ismerve a FOSS minőséget, mi nem leakel?

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

Olvasd tovább a hozzászólásom ;-)

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.

Ellenben az OpenBSD él és virul… (ha már a halott rendszereknél tartunk)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

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/6/html/Resource_Management_Guide/ch-Using_Control_Groups.html
http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
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.

"Harmadrészt, hash indexeket is hasznaltatok vagy csak btree?"
Nem emlékszem rá.

--
arch,centos,debian,openelec,android

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

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

#bancsakalinuxot

--
NetBSD - Simplicity is prerequisite for reliability

Mit javasolsz?

KAMI | 神
Firefox OS: https://is.gd/fxoshu Linux Mint: http://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes!

Például az OOM killer teljes mellőzését. Annak mi értelme van, hogy létezik, de a legtöbben úgyk ezdik, hogy kikapcsolják a működését, mert nem jó, amit csinál és ami miatt létezik?

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

De ha engem kérdeztek: [...]
+1. igy kene csinalni.

kerdes marcsak az hogy a javaban implementalt python interpreterek kora'ban (amik pl 128g rammal megaldott gepeken userkent futtatva ugy fagyasztja'k csontta' a rendszert hogy csak zeng) ez mennyire lesz kovetendo" pelda...

> kerdes marcsak az hogy a javaban implementalt python interpreterek kora'ban...

Ja, kérem, hát akkor lép be a 3b pont. :)

csak az a gáz, hogy ez a döntő többség - fejlesztői elv: CPU és RAM az van bőven.

vagy forditva: alapertelmezetten kikapcs - oszt ha valaki tudja hogy mit csinal es/vagy rohadtul ra'e'r es/vagy nincs jobb dolga es/vagy szeret kockazatosan elni, na akkor maximum bekapcsolja.

Talalos kerdes:
Ha egy 64G memoriaval rendelkezo gepen egy 32G memoriat hasznalo process fork() -t hiv. Akkor mennyi a memoria igenye ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Elméletikeg 32+32, a tehén miatt jóval kevesebb :)

pontosan. fork() utan ugyanugy 32g marad a memoriaigeny. ez jol tervezheto.

Egészen addig, amíg akár a parent, akár a child nem ír valahova, mert akkor jön a tehén (Copy-On-Write). Azért azt tegyük hozzá, hogy a child számára előjegyzi a 32G memóriát, csak nem foglalja le.

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.