Ciao,
sicuramente avrai fatto tutti i controlli del caso e la mia segnalazione ha una
altissima probabilità di essere inutile.
Riporto solo una mia esperienza analoga (ERROR: out of memory) sulla
esecuzione di una query annidata.
Dopo aver smanettato a 1000 sulle configurazioni di memoria il caso si è
risolto valutando attentamente il cast sul campo della query annidata:
WHERE field_id ->> 'pageId' in (SELECT stage.eng_page.identifier::text
Guido
Il giorno 15/gen/2015, alle ore 23:33, Enrico Bianchi
<enrico.bianchi@xxxxxxxxx> ha scritto:
On 01/15/2015 07:06 PM, Chris Mair wrote:
- puoi provare a "semplificare" la query, per vedere se c'e` un punto oltrePosso dirti che, se tolgo l'IN (che, per 64 record, secondo il planner genera
il quale l'errore scompare?
6mln di record)ed uso un solo valore, la query viene eseguita correttamente.
Pero`, gia` se metto 5 dei valori riportati dalla subquery, esplode tutto (il
query plan dice che dovrebbe restituire 336500 record)
- puoi tenere d'occhio top/free/slabtop mentre esegui la query? vedi ilEcco, questo e` un altro punto che non riesco a capire. Per intenderci,
processo worker che continua a crescere, Linux a iniziare a usare swap e poi
il processo scomparire nel momento che hai l'error o e` un altro pattern,
tipo l'error appare subito?
questo e` un vmstat lanciato mentre stava estraendo 336500 record:
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa
st
0 0 0 64467148 16888 996464 0 0 5 1 75 40 5 1 94 0
0
2 0 0 64365252 16888 996464 0 0 0 0 734 167 13 2 82
0 2
1 0 0 63471488 16888 996464 0 0 0 1 1102 176 21 4 75
0 0
1 0 0 62257732 16888 996464 0 0 0 12 1070 160 21 4 74
0 2
1 0 0 60939172 16888 996464 0 0 0 0 1072 158 21 4 75
0 0
1 0 0 59627188 16888 996464 0 0 0 6 1071 161 21 4 75
0 0
1 0 0 58324692 16888 996464 0 0 0 0 1069 152 21 4 75
0 0
1 0 0 57002732 16888 996464 0 0 0 0 1049 133 21 4 75
0 0
1 0 0 55671200 16888 996464 0 0 0 1 1076 152 21 4 75
0 0
1 0 0 54316064 16896 996460 0 0 0 4 1056 140 21 4 75
0 0
1 0 0 52939020 16896 996464 0 0 0 0 1052 140 22 3 75
0 0
1 0 0 51558644 16896 996464 0 0 0 5 1069 156 21 4 75
0 0
1 0 0 50188544 16896 996464 0 0 0 0 1069 156 21 4 75
0 0
0 0 0 64464804 16896 996476 0 0 0 0 557 269 6 7 88 0
0
L'idea che mi sono fatto, ad occhio, e` che va in OOM quando deve *mostrare*
i dati, non quando li estrae
- imagino che il database sia grande | segreto | e` una storia complicataIn teoria non c'e` nulla di segreto, sono dati estratti da pagine di Facebook
altrimenti mi piacerebbe provare a riprodurre l'errore su una mia macchina
(la butto li`...)
e questa query era un primo passo per elaborarli, piu` che altro direi che
sia una storia complicata portarli fuori
Enrico
_______________________________________________
Postgresql-it mailing list
Postgresql-it@xxxxxxxxxxxxx
http://lists.psql.it/mailman/listinfo/postgresql-it
