Re: Out of memory

[Pavel Stehule]

Ahoj

tohle se deje nahodne nebo na nejakem konkretnim dotazu?

Tipoval bych, ze to bude bug v pg, ale nevim o tom, ze by nekdo podobnou chybu vuci 9.4 hlasil. Obycejne to muze byt memory leakem pripadne zmenou provadeciho planu, ktery je pametove narocnejsi.

Dokazal byste pripravit test?

Pavel

2013/4/20 <u...@avast.com>

Zdravim,

po upgrade na 9.2.4 se nam zacla objevoval spousta vyjimek typu "out of memory". Konfigurace zustala stejna (aktualni je v priloze).
Databazovy stroj je 6 jadro (s HT), 32GB RAM. na stroji je cca 9500 tabulek v ruznych schematech, typicky kolem 100 - 200 dotazu za vterinu (cca 50 - 120 spojeni najednou)

Uzivatelska role, ktera je prihlasena ma nastaveny work_mem na 18MB

Nenapadne prosim nekoho cim by to mohlo byt?

Typicky zaznam v logu v pripade chyby je neco jako toto:

TopMemoryContext: 1375320 total in 168 blocks; 6472 free (18 chunks); 1368848 used
  TopTransactionContext: 8192 total in 1 blocks; 7328 free (0 chunks); 864 used
  CFuncHash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  TableSpace cache: 8192 total in 1 blocks; 3216 free (0 chunks); 4976 used
  Type information cache: 24240 total in 2 blocks; 3744 free (0 chunks); 20496 used
  Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used
  MessageContext: 568888 total in 9 blocks; 52672 free (14 chunks); 516216 used
  Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  smgr relation table: 1040384 total in 7 blocks; 387920 free (24 chunks); 652464 used
  TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0 chunks); 32 used
  Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  PortalMemory: 8192 total in 1 blocks; 8160 free (1 chunks); 32 used
  Relcache by OID: 516096 total in 6 blocks; 261232 free (10 chunks); 254864 used
  CacheMemoryContext: 232883248 total in 5251 blocks; 5644000 free (2 chunks); 227239248 used
...

...
    pg_auth_members_role_member_index: 3072 total in 2 blocks; 1568 free (2 chunks); 1504 used
    pg_database_oid_index: 3072 total in 2 blocks; 1656 free (3 chunks); 1416 used
    pg_authid_rolname_index: 3072 total in 2 blocks; 1656 free (3 chunks); 1416 used
  MdSmgr: 253952 total in 5 blocks; 59168 free (0 chunks); 194784 used
  tokenize file cxt: 0 total in 0 blocks; 0 free (0 chunks); 0 used
  hba parser context: 15360 total in 4 blocks; 1872 free (3 chunks); 13488 used
  LOCALLOCK hash: 24576 total in 2 blocks; 9808 free (4 chunks); 14768 used
  Timezones: 83472 total in 2 blocks; 3744 free (0 chunks); 79728 used
  ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-maily, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/groups/opt_out.
 
 

[Tomas Vondra]

On 20.4.2013 19:05, u...@avast.com wrote:
> Zdravim,
>
> po upgrade na 9.2.4 se nam zacla objevoval spousta vyjimek typu "out of

Chválím za upgrade, ale byla by fajn informace ze které verze jste
přešli, jinak nevíme od kdy máme v commit logu hledat ;-)

> memory". Konfigurace zustala stejna (aktualni je v priloze).
> Databazovy stroj je 6 jadro (s HT), 32GB RAM. na stroji je cca 9500
> tabulek v ruznych schematech, typicky kolem 100 - 200 dotazu za vterinu
> (cca 50 - 120 spojeni najednou)

Jak psal Pavel, zkuste odhalit dotazy na kterých to padá. Pokud to padá
hodně často tak by to neměl být zásadní problém.

Zajímavé je že se to začalo dít až po upgrade na 9.2.4 ...

> Uzivatelska role, ktera je prihlasena ma nastaveny work_mem na 18MB

Tohle s největší pravděpodobností nemá význam. Memory leaky tohoto typu
jsou většinou v částech kódu nechráněných work_mem (viz. dále), a i
kdyby tak operací používajících 32MB work_mem, tak by tam muselo být
hodně aby to vedlo k OOM.

>
> Nenapadne prosim nekoho cim by to mohlo byt?
>
> Typicky zaznam v logu v pripade chyby je neco jako toto:

...

> CacheMemoryContext: 232883248 total in 5251 blocks; 5644000 free (2
> chunks); 227239248 used
> ...

Bohužel jste umazal tu nejzajímavější část :-( Můžete někam umístit
kompletní log z OOM, včetně uzlů pod CacheMemoryContext?

Každopádně tohle říká že (nejspíš) relcache má ~230MB, což je relativně
hodně. Nemáte tam něco co nějak ošahává všechny tabulky (třeba nějaký
skript co prochází pg_class apod.)?

Případně nemáte tam nějaké triggery napsané v pythonu a pověšené na
hodně tabulek? Fix v commitu 308711af by mohl způsobit větší využití
paměti, a při velkém počtu tabulek by to mohl být problém.

T.

[Pavel Stehule]

Ahoj

jen poznamka, vypada to, ze v tom nejste sam :-(

http://www.postgresql.org/message-id/CACffM9F-aSTopQ3G0mZvyWusp=RPZ=MmnPn26MKV...@mail.gmail.com

Pavel

Dne 21. dubna 2013 0:34 Tomas Vondra <t...@fuzzy.cz> napsal(a):

[u...@avast.com]

Zdravim,

test asi pripravit nedokazu, protoze se to nedeje pri konkretnim dotazu, ale prijde mi, ze se to stava pri soubehu nekolika (desitek) dotazu... Nicmene zadny z provadenych dotazu neni extremne narocny (v podstate jednoduche selecty s index scany). ...

Jedine ceho jsem si vsiml, tak se zvysenou pravdepodobnosti se to deje, pokud je spusten pg_dump, kvuli zaloze DB (pak ostatni procesy umiraji) ....

[u...@avast.com]

Zdravim,

moje odpovedi nize...

Diky!

On Sunday, April 21, 2013 12:34:00 AM UTC+2, Tomáš Vondra wrote:

On 20.4.2013 19:05, u...@avast.com wrote:
> Zdravim,
>
> po upgrade na 9.2.4 se nam zacla objevoval spousta vyjimek typu "out of

Chválím za upgrade, ale byla by fajn informace ze které verze jste
přešli, jinak nevíme od kdy máme v commit logu hledat ;-)

Upgrade byl z 9.2.3
 

> memory". Konfigurace zustala stejna (aktualni je v priloze).
> Databazovy stroj je 6 jadro (s HT), 32GB RAM. na stroji je cca 9500
> tabulek v ruznych schematech, typicky kolem 100 - 200 dotazu za vterinu
> (cca 50 - 120 spojeni najednou)

Jak psal Pavel, zkuste odhalit dotazy na kterých to padá. Pokud to padá
hodně často tak by to neměl být zásadní problém.

Zajímavé je že se to začalo dít až po upgrade na 9.2.4 ...

Jak jsem psal Pavlovi, nedeje se to pri konkretnich dotazech, ale spise pri souhre ...
 

> Uzivatelska role, ktera je prihlasena ma nastaveny work_mem na 18MB

Tohle s největší pravděpodobností nemá význam. Memory leaky tohoto typu
jsou většinou v částech kódu nechráněných work_mem (viz. dále), a i
kdyby tak operací používajících 32MB work_mem, tak by tam muselo být
hodně aby to vedlo k OOM.

Take mam pocit ze work_memu se to nejak netyka
 

>
> Nenapadne prosim nekoho cim by to mohlo byt?
>
> Typicky zaznam v logu v pripade chyby je neco jako toto:
...
>   CacheMemoryContext: 232883248 total in 5251 blocks; 5644000 free (2
> chunks); 227239248 used
> ...

Bohužel jste umazal tu nejzajímavější část :-( Můžete někam umístit
kompletní log z OOM, včetně uzlů pod CacheMemoryContext?

Každopádně tohle říká že (nejspíš) relcache má ~230MB, což je relativně
hodně. Nemáte tam něco co nějak ošahává všechny tabulky (třeba nějaký
skript co prochází pg_class apod.)?

Případně nemáte tam nějaké triggery napsané v pythonu a pověšené na
hodně tabulek? Fix v commitu 308711af by mohl způsobit větší využití
paměti, a při velkém počtu tabulek by to mohl být problém.

Log kompletni log dodavam v priloze ( je tam spousta "partitionovanych" tabulek, proto je to tak dlouhe
Trigery v pythonu nemame

 

T.

[Tomas Vondra]

On 21.4.2013 11:23, u...@avast.com wrote:
> Zdravim,
>
> moje odpovedi nize...
>
> Diky!
>

> On Sunday, April 21, 2013 12:34:00 AM UTC+2, Tomďż˝ Vondra wrote:

>
> On 20.4.2013 19:05, u...@avast.com <javascript:> wrote:
> > Zdravim,
> >
> > po upgrade na 9.2.4 se nam zacla objevoval spousta vyjimek typu
> "out of
>

> Chv�l�m za upgrade, ale byla by fajn informace ze kter� verze jste
> p�e�li, jinak nev�me od kdy m�me v commit logu hledat ;-)
>
>
> Upgrade byl z 9.2.3

OK, d�ky - to v�razn� omezuje po�et commit� kter� je pot�eba zkoumat.

D�lali jste p�i tom upgrade je�t� n�co? Nap�. upgrade kernelu?

> > memory". Konfigurace zustala stejna (aktualni je v priloze).
> > Databazovy stroj je 6 jadro (s HT), 32GB RAM. na stroji je cca 9500
> > tabulek v ruznych schematech, typicky kolem 100 - 200 dotazu za
> vterinu
> > (cca 50 - 120 spojeni najednou)

V�cem�n� nesouvisej�c� dotaz - kolik z t�ch spojen� je aktivn�ch? Toti�
v�t�inou se naraz� bu� na CPU bottleneck nebo na disky, tak�e limit
aktivn�ch spojen� se doporu�uje nap�.

po�et CPU + po�et disk� (spindles)

co� je v�t�inou << 50. Samoz�ejm� pokud v�t�ina t�ch spojen� je idle tak
to nen� probl�m - leda �e by kv�li memory leaku pam� ut�kala na �rovni
session (a ne t�eba na �rovni jednotliv�ch dotaz�). To by mohlo
vysv�tlit tu n�hodnost ... a sn�en� by pak bylo do�asn� workaround.

> Jak psal Pavel, zkuste odhalit dotazy na kter�ch to pad�. Pokud to pad�
> hodn� �asto tak by to nem�l b�t z�sadn� probl�m.
>
> Zaj�mav� je �e se to za�alo d�t a� po upgrade na 9.2.4 ...

>
>
> Jak jsem psal Pavlovi, nedeje se to pri konkretnich dotazech, ale spise
> pri souhre ...

Rozum�m. M�te n�jak� testovac� prost�ed� na kter�m byste to zkusili
n�jak nasimulovat? Tak aby se tam dal nap�. sledovat r�st pam�ti v topu,
p�ipojit se tam p�es gdb apod?

> > Nenapadne prosim nekoho cim by to mohlo byt?
> >
> > Typicky zaznam v logu v pripade chyby je neco jako toto:
> ...
> > CacheMemoryContext: 232883248 total in 5251 blocks; 5644000 free (2
> > chunks); 227239248 used
> > ...
>

> Bohu�el jste umazal tu nejzaj�mav�j�� ��st :-( M�ete n�kam um�stit
> kompletn� log z OOM, v�etn� uzl� pod CacheMemoryContext?
>
> Ka�dop�dn� tohle ��k� �e (nejsp�) relcache m� ~230MB, co� je relativn�
> hodn�. Nem�te tam n�co co n�jak o�ah�v� v�echny tabulky (t�eba n�jak�
> skript co proch�z� pg_class apod.)?
>
> P��padn� nem�te tam n�jak� triggery napsan� v pythonu a pov�en� na
> hodn� tabulek? Fix v commitu 308711af by mohl zp�sobit v�t�� vyu�it�
> pam�ti, a p�i velk�m po�tu tabulek by to mohl b�t probl�m.

>
>
> Log kompletni log dodavam v priloze ( je tam spousta "partitionovanych"
> tabulek, proto je to tak dlouhe

OK. Z�klan� info a log jsem p�eposlal do pgsql-general k tomu reportu
kter� pos�lal Pavel. Uvid�me jestli tam na n�co p�ijdou.

T.

[u...@avast.com]

Zdravim,

nejak se to poslalo se spatnou diakritikou ... tak snad jsem dekodoval dobre:

Probehl pouze upgrade PostgreSQL
Pocet "aktivnich" spojeni je v radu desitek
Testovaci prostredi - bohuzel se jedna o interni databazi, nicmene dle toho co sleduji v TOPu, tak se mi moc nezda ze by na serveru byla uplne vyzrana RAM ... pri normalnim stavu je obsazeno cca 10GB ram, v topu se zda ze kolem 20GB ... takze se zda ze se to nekde zasekne... nicmene opravdu nemuzu najit konkretni limit...

Vcera jsem snizil shared_buffers na 4GB a zda ze skoro cely den bez problemu (az k veceru opet OOM)

T.

[Tomas Vondra]

Dne 2013-04-22 09:12, u...@avast.com napsal:

> Zdravim,
>
> nejak se to poslalo se spatnou diakritikou ... tak snad jsem dekodoval
> dobre:
>
> Probehl pouze upgrade PostgreSQL
> Pocet "aktivnich" spojeni je v radu desitek

Takže ta spojení jsou otevřená dlouhodobě?

> Testovaci prostredi - bohuzel se jedna o interni databazi, nicmene
> dle toho co sleduji v TOPu, tak se mi moc nezda ze by na serveru byla
> uplne vyzrana RAM ... pri normalnim stavu je obsazeno cca 10GB ram, v
> topu se zda ze kolem 20GB ... takze se zda ze se to nekde zasekne...
> nicmene opravdu nemuzu najit konkretni limit...

A jak na tu paměť koukáte? Co říká "free"?

Můžete tam nastavit nějaký monitoring který by sledoval množství paměti
(RES v topu)
pro ty backendy?

Stačí primitivní, tj. každou minutu pustit

ps -eo pid,lstart,rsz,vsz,comm,args | grep postgres

a uložit to někam do souboru.

>
> Vcera jsem snizil shared_buffers na 4GB a zda ze skoro cely den bez
> problemu (az k veceru opet OOM)

Hmmmm, to celé zní dost divně a pokud není obsazena paměť tak na chybu
v Postgresu moc nevypadá - spíš mi to přijde že se v 9.2 třeba nepatrně
zvýšil objem paměti a začali jste hitovat nějaký jiný problém.

Nemáte tam náhodou nastavené overcommit_memory=2 ?

T.

[u...@avast.com]

Zdravim,

On Monday, April 22, 2013 1:41:15 PM UTC+2, Tomáš Vondra wrote:

Dne 2013-04-22 09:12, u...@avast.com napsal:
> Zdravim,
>
> nejak se to poslalo se spatnou diakritikou ... tak snad jsem dekodoval
> dobre:
>
> Probehl pouze upgrade PostgreSQL
> Pocet "aktivnich" spojeni je v radu desitek

Takže ta spojení jsou otevřená dlouhodobě?

> Testovaci prostredi - bohuzel se jedna o interni databazi, nicmene
> dle toho co sleduji v TOPu, tak se mi moc nezda ze by na serveru byla
> uplne vyzrana RAM ... pri normalnim stavu je obsazeno cca 10GB ram, v
> topu se zda ze kolem 20GB ... takze se zda ze se to nekde zasekne...
> nicmene opravdu nemuzu najit konkretni limit...

A jak na tu paměť koukáte? Co říká "free"?

Na pamet koukam pres htop, nicmene jsem koukal i pres ipcs, free rika neco jako:

             total       used       free     shared    buffers     cached

Mem:      32829880   32594944     234936          0       2688   25181264

-/+ buffers/cache:    7410992   25418888

Swap:            0          0          0

 

Můžete tam nastavit nějaký monitoring který by sledoval množství paměti
(RES v topu)
pro ty backendy?

Stačí primitivní, tj. každou minutu pustit

   ps -eo pid,lstart,rsz,vsz,comm,args | grep postgres

a uložit to někam do souboru.

Vytvorim a poslu

 

>
> Vcera jsem snizil shared_buffers na 4GB a zda ze skoro cely den bez
> problemu (az k veceru opet OOM)

Hmmmm, to celé zní dost divně a pokud není obsazena paměť tak na chybu
v Postgresu moc nevypadá - spíš mi to přijde že se v 9.2 třeba nepatrně
zvýšil objem paměti a začali jste hitovat nějaký jiný problém.

Nemáte tam náhodou nastavené overcommit_memory=2 ?

Ano overcommit_memory mame nastaveny na 2

vm.overcommit_memory=2

vm.overcommit_ratio=90

nicmene jiz skoro rok ... zaroven pres cron poustime

*/10    *       *       *       *       root    for i in `cat /var/lib/pgsql/9.2/data/postmaster.pid|head -n1` ; do echo -1000 > /proc/$i/oom_adj; done

Radite tedy nastavit overcommit jinak?

 

T.

[Tomas Vondra]

Dne 2013-04-22 13:56, u...@avast.com napsal:

>>
>> A jak na tu paměť koukáte? Co říká "free"?
>
> Na pamet koukam pres htop, nicmene jsem koukal i pres ipcs, free rika
> neco jako:
>
> total used free shared buffers cached
> Mem: 32829880 32594944 234936 0 2688 25181264
> -/+ buffers/cache: 7410992 25418888
> Swap: 0 0 0
>

>> Pokud není obsazena paměť tak na chybu

>> v Postgresu moc nevypadá - spíš mi to přijde že se v 9.2 třeba
>> nepatrně
>> zvýšil objem paměti a začali jste hitovat nějaký jiný problém.
>>
>> Nemáte tam náhodou nastavené overcommit_memory=2 ?
>>
>> Ano overcommit_memory mame nastaveny na 2
>> vm.overcommit_memory=2
>>
>> vm.overcommit_ratio=90

> ne jiz skoro rok ... zaroven pres cron poustime
>
> */10 * * * * root for i in `cat
> /var/lib/pgsql/9.2/data/postmaster.pid|head -n1` ; do echo -1000 >
> /proc/$i/oom_adj; done

Tohle myslím není správně. Validní hodnoty oom_adj jsou -17 až 15.
Hodnota -1000
se používá až pro novější variantu oom_score_adj a nevím jak to bude
fungovat při
tomhle nastavení do oom_adj (jestli vůbec nebo jestli se to přeloží na
-17).

>
> Radite tedy nastavit overcommit jinak?

To nevím. Nastavení na overcommit_memory=2 a overcommit_ratio=90 mi
přijde OK,
ale vybavuji si že jsem se s podobnými problémy před časem potýkal, byť
na
daleko menším systému. Také neměl swap a tenkrát pomohlo ho přidat (byť
malý)
a nastavit swappiness (=10).

T.

[u...@avast.com]

Zdravim.

no s tim OOM jsem vsude videl -1000, tak jsem to zmenil z puvodnich -17, vratil jsem zpet.

Nicmene vcera jsem snizil shared_buffers na 4GB a zda se zatim vse funguje... Jeste budu muset zkusit full dump, ktery je naplanovan na sobotu, pak se uvidi zda vse je v poradku...

T.

[Tomas Vondra]

Dne 2013-04-23 09:24, u...@avast.com napsal:

> Zdravim.
>
> no s tim OOM jsem vsude videl -1000, tak jsem to zmenil z puvodnich
> -17, vratil jsem zpet.

No ono pro oom_adj je minimum -17, pro oom_score_adj -1000.

> Nicmene vcera jsem snizil shared_buffers na 4GB a zda se zatim vse
> funguje... Jeste budu muset zkusit full dump, ktery je naplanovan na
> sobotu, pak se uvidi zda vse je v poradku...

Ještě se zeptám na hodnotu kernel.shmall. Totiž opakovaně se mi stalo
že
tam byla příliš nízká hodnota - PostgreSQL v pohodě najel ale další
služby
na tom stroji ne a občas to házelo dost podivné OOM chyby.

T.

[u...@avast.com]

Zdravim.

kernel.shmmax = 68719476736

kernel.shmall = 4294967296

[Tomas Vondra]

Dne 2013-04-24 10:05, u...@avast.com napsal:

> Zdravim.
>
> kernel.shmmax = 68719476736
>
> kernel.shmall = 4294967296

No a není tohle ten problém? Totiž shmmax říká kolik paměti (v bytech)
může mít jeden segment,
a shmall říká ve stránkách kolik mohou mít segmenty dohromady.

Vy v podstatě říkáte "jeden segment může mít 68GB" a "všechny dohromady
mohou mít 16GB". Sice
se mi nezdá že by to mohlo způsobit ty OOM chyby, ale je to zvláštní.

T.

[u...@avast.com]

Hmm, mozna to bude tim, toto nastaveni nam pravdepodobne zustalo z predchoziho stroje, ktery mel 16GB RAM....

Takze teoreticky kdyby se obe hodnoty zvedly na 2x tolik, vse by melo byt v poradku a stroje by mozna vydychaly i shared_buffers na vice nez 4GB (coz je nastavene ted a vse se zda ze funguje)

Chapu to dobre?

[Tomas Vondra]

Dne 2013-04-25 15:38, u...@avast.com napsal:

> Hmm, mozna to bude tim, toto nastaveni nam pravdepodobne zustalo z
> predchoziho stroje, ktery mel 16GB RAM....
>
> Takze teoreticky kdyby se obe hodnoty zvedly na 2x tolik, vse by melo
> byt v poradku a stroje by mozna vydychaly i shared_buffers na vice nez
> 4GB (coz je nastavene ted a vse se zda ze funguje)
>
> Chapu to dobre?

No já bych rozhodně nezvedal oboje na 2x tolik, protože problém je
právě
poměr a ten se zvýšením obou mezmění. Platí že by mělo být

shmall >= shmmax

a oboje by mělo být menší než RAM. Vy aktuálně máte 32GB RAM, a přitom
máte nastaveno shmmax 64GB (tj. 2x RAM) a shmall 16 GB (tj. 4x méně než
shmmax).

Rozumné hodnoty bych viděl tak např. takhle

shmmax = 10GB
shmall = 16GB

a shared_buffers = 8GB.

Pokud by vám to padalo na OOM tak se přes "ipcs -m" podívejte jaké
shared
memory segmenty tam máte (a jak velké).

T.

[u...@avast.com]

No,

pri nastaveni shmall = 16GB a shared_buffers=8GB nam to v podstate porad hazelo OOM ... zkusil jsem nastavit shmall=28GB a jakmile bude mozne restartovat samotne PSQL tak zkusim prenastavit shared_buffers zpet na 8GB z momentalnich 4GB a uvidime. 

Kazdopadne diky za rady, jeste napisu jak to vypada...

[u...@avast.com]

Hmm,

tak ted jsem uplne zmateny :D

mame getconf PAGE_SIZE

4096

Nastavil jsem

sysctl -w kernel.shmmax=30064771072

sysctl -w kernel.shmall=7340032

Takze na jeden segment muze mit 28GB

Zaroven je celkem k dispozici 7340032 po 4096 bytech, takze celkem 28GB ...

Chtel jsem dosahnout shmall=shmmax... je to tak spravne? 

[Tomas Vondra]

Dne 2013-04-25 17:09, u...@avast.com napsal:

> Hmm,
>
> tak ted jsem uplne zmateny :D
>
> mame getconf PAGE_SIZE
> 4096
>
> Nastavil jsem
>
> sysctl -w kernel.shmmax=30064771072
> sysctl -w kernel.shmall=7340032
>
> Takze na jeden segment muze mit 28GB
> Zaroven je celkem k dispozici 7340032 po 4096 bytech, takze celkem
> 28GB ...
>
> Chtel jsem dosahnout shmall=shmmax... je to tak spravne?

Ano, já myslím že je to tak správně.

T.

[u...@avast.com]

Hmm,

tak se nam zacly opet objevovat OOM a pritom ...

ipcs -m

------ Shared Memory Segments --------

key        shmid      owner      perms      bytes      nattch     status

0x0052e2c1 1605632    postgres   600        5173788672 137

[Tomas Vondra]

A mate nejake ty logy s utilizaci pameti?

T.

Dne 2013-04-26 10:01, u...@avast.com napsal:

> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.
> Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily
> e-maily, zašlete e-mail na adresu
> postgresql-c...@googlegroups.com.
> Další možnosti najdete na adrese

> https://groups.google.com/groups/opt_out [1].
>
>
>
> Links:
> ------
> [1] https://groups.google.com/groups/opt_out

[u...@avast.com]

Zdravim,

mam k dispozici pouze grafy, nemam textove, bude stacit?

On Saturday, April 20, 2013 7:05:07 PM UTC+2, u...@avast.com wrote:

Zdravim,

po upgrade na 9.2.4 se nam zacla objevoval spousta vyjimek typu "out of memory". Konfigurace zustala stejna (aktualni je v priloze).

Databazovy stroj je 6 jadro (s HT), 32GB RAM. na stroji je cca 9500 tabulek v ruznych schematech, typicky kolem 100 - 200 dotazu za vterinu (cca 50 - 120 spojeni najednou)

Uzivatelska role, ktera je prihlasena ma nastaveny work_mem na 18MB

Nenapadne prosim nekoho cim by to mohlo byt?

Typicky zaznam v logu v pripade chyby je neco jako toto:

TopMemoryContext: 1375320 total in 168 blocks; 6472 free (18 chunks); 1368848 used
  TopTransactionContext: 8192 total in 1 blocks; 7328 free (0 chunks); 864 used
  CFuncHash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  TableSpace cache: 8192 total in 1 blocks; 3216 free (0 chunks); 4976 used
  Type information cache: 24240 total in 2 blocks; 3744 free (0 chunks); 20496 used
  Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used
  MessageContext: 568888 total in 9 blocks; 52672 free (14 chunks); 516216 used
  Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  smgr relation table: 1040384 total in 7 blocks; 387920 free (24 chunks); 652464 used
  TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0 chunks); 32 used
  Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  PortalMemory: 8192 total in 1 blocks; 8160 free (1 chunks); 32 used
  Relcache by OID: 516096 total in 6 blocks; 261232 free (10 chunks); 254864 used

  CacheMemoryContext: 232883248 total in 5251 blocks; 5644000 free (2 chunks); 227239248 used
...

[Tomas Vondra]

On 26.4.2013 10:47, u...@avast.com wrote:
> Zdravim,
>
> v textove podobe bohuzel ne, nicmene v priloze posilam graf z
> monitorovaciho nastroje
>
> Pocet aktivnich konekci byl zhruba kolem 80
>
> T.

Ne, z toho bohu�el nic nepozn�m krom� toho �e v�m tam narostl po�et
spojen� a procento "cached" pam�ti. Pro� k tomu doch�z� (nap�. jestli za
to m�e jeden ten proces nebo co) z toho samoz�ejm� poznat nejde.

K tomu je pot�eba v�c ne� grafy - zkuste se tam alespo� p�ihl�sit v dob�
kdy OOM killer za�ne ��dit a poslat v�stup topu (jestli tam t�eba nen�
n�jak� dal�� �rout) a obsah /proc/meminfo.


Ka�dop�dn� kdy� o tom tak p�em�l�m, tak vy m�te 80 konex�, p�itom ka�d�
si vezme 220MB na relation cache (informace o tabulk�ch, partitions,
indexech atd.). To je dohromady 80 x 232 MB = 18.5GB.

K tomu m�te 4GB (resp. 8GB) shared buffers, tak�e jsme na 23GB (27GB).
No a to u� je samoz�ejm� velk� ��st pam�ti.

M� po��d nen� jasn� pro� tam proboha m�te tolik konex� - vsadil bych se
�e pokud jich tam nech�te nap�. 20 (mo�n� poolovan� p�es pgbouncer) tak
se t�chle probl�m� zbav�te a p�itom v�kon bude �pln� stejn�. A kdy� to
ud�l�te p�es pgbouncer s transaction-aware poolingem tak to aplikace ani
nemusďż˝ poznat.


BTW v jednom z p�edchoz�ch mail� jsem doporu�oval p�idat tam alespo�
mali�k� swap (a n�zkou hodnotu vm.swappiness, t�eba 10). To by taky pomohlo.

T.

[u...@avast.com]

zdravim,

meli jsme chvili klid, a nyni se nam zase ve vetsim mnozstvi objevuje OOM (i po upgrade 9.2.4), a zaroven se mi konecne podarilo ziskat otisky systemu pri OOM 

- oom.log - log postgres

- mem.log - cat /proc/meminfo

- ps.log - ps auxf

- all_settings_pg - aktivni nastaveni pg

Diky za odpoved

T.

[u...@avast.com]

Zdravim,

tak to vypada asi na jeste neco jineho, vypozoroval jsem ze OOM se nam deje jen na serverech kde je vice jak 8000 tabulek a zatim co jsem zjistil tak to vypada na nejake spatne uvolnovani pameti pri persistentnich spojenich do DB.

Vypada to takto:
Zapneme DB, aplikace zacne vytvaret spojeni a casem (rychlost zavisit nastaveni work_mem a shared_buffers) se takrka uplne zaplni RAM (pritom aplikace drzi pocet konekci omezen na max 128) a pak dojde k OOM.

Nicmene pokud ve fazi, kdy je temer cela RAM obsazena, v aplikaci vsechna spojeni zrusime (odpojime se z DB), dojde k tomu, ze okamzite klesne obsazena RAM na necely 1GB (zase v zavislosti na nastaveni).

Takze dle me to vypada na nejaky problem s backendy a alokaci RAM ...

Tusite neco v tomto smyslu? Jen doplnim ze mame 9.2.4

Pokud budete mit zajem tak muzu dodat vypis z TOPu, /proc/meminfo, postgresql.conf apod. z doby pred a po odpojeni

S pozdravem

Tomas Uko

[Pavel Stěhule]

Dne středa, 20. listopadu 2013 15:46:50 UTC+1 u...@avast.com napsal(a):

Zdravim,

tak to vypada asi na jeste neco jineho, vypozoroval jsem ze OOM se nam deje jen na serverech kde je vice jak 8000 tabulek a zatim co jsem zjistil tak to vypada na nejake spatne uvolnovani pameti pri persistentnich spojenich do DB.

Vypada to takto:
Zapneme DB, aplikace zacne vytvaret spojeni a casem (rychlost zavisit nastaveni work_mem a shared_buffers) se takrka uplne zaplni RAM (pritom aplikace drzi pocet konekci omezen na max 128) a pak dojde k OOM.

Nicmene pokud ve fazi, kdy je temer cela RAM obsazena, v aplikaci vsechna spojeni zrusime (odpojime se z DB), dojde k tomu, ze okamzite klesne obsazena RAM na necely 1GB (zase v zavislosti na nastaveni).

Takze dle me to vypada na nejaky problem s backendy a alokaci RAM ...

Tusite neco v tomto smyslu? Jen doplnim ze mame 9.2.4

to by to mohly delat interni systemove cache

kazda session si drzi v lokalni cache systemova data o tabulkach a atributech, ktere se pouzily - a pouzivaji se pro opakovany pristup ke slovniku. Je to sada jednoduchych hash tabulek, ktere se cisti pouze pri zmene struktury schematu nebo tim, ze se uzavre session. Rizeni cache je zamerne jednoduche, aby si nevynucovalo zamykani. Pokud vim, tak tam nejsou zadne limity - coz je chyba. Pokud mate vetsi pocet tabulek a sahate na kazdou a mate vetsi pocet session, tak si dovedu predstavit, ze tyto lokalni cache mohou byt vyznamne velke.

Mozna by stalo za uvahu to reportovat - teoreticky by se dalo pri dosazeni urcite velikosti tyto cache resetovat - anebo pro Vas inteligentne vyuzivat session, tak aby pokud mozno opakovane pouzivane sesion pristupovaly ke stejne sade tabulek.

Pavel
 

[u...@avast.com]

Zdravim, 

podle by to stalo za report... navrh s "inteligentnim rizenim" spojeni asi u nas v soucasne dobe neni uskutecnitelny, je pro nas jednodussi udelat automaticke obnovovani spojeni po 15 minutach 

T.

[Pavel Stehule]

Dne 21. listopadu 2013 7:44 <u...@avast.com> napsal(a):

Zdravim, 

podle by to stalo za report... navrh s "inteligentnim rizenim" spojeni asi u nas v soucasne dobe neni uskutecnitelny, je pro nas jednodussi udelat automaticke obnovovani spojeni po 15 minutach 

to mne taky napadlo, session zabijet driv - myslim si, ze poolovani ma smysl k tomu, abych nevytvarel 1000 session za vterinu, ale pokud nastavim zivotnost 10 sec (v zavislosti na delce dotazu), tak tam uz rezie spojena s vytvarenim session nebude asi hrat vyznamnou roli.

Pavel

 

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-maily, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Další možnosti najdete na adrese https://groups.google.com/groups/opt_out.