PostgreSQL crash

[Verwijderd]

HELLUP!
Mijn PostgreSQL (op linux 2.4.18) crasht steeds.

<Samenvatting>: Na een tijdje stopt postmaster nieuwe connecties te accepteren via tcp en via unix sockets. De bestaande connecties blijven wel nog uren leven. Na het restarten van postgresql kunnen connecties weer gemaakt worden tot de volgende crash.</Samenvatting>

Ik heb gisteren de harddisk van een bestaande server vervangen. Op deze hdd staat een kopie van een installatie die op een ander systeem al een half jaar crash-vrij is. Sinds ik de serverruimte heb verlaten is PostgreSQL al 20 keer gecrasht of zo. Wat er gebeurt:

Na een tijdje stopt postmaster nieuwe connecties te accepteren zowel via tcp als via unix sockets. De bestaande connecties blijven wel nog uren leven. Als ik weer zie dat het weer zo laat is, moet ik gewoon killall postmaster doen, gevolgd door het commando wat de postgres server weer opstart. Dan vervolgens kan de server weer een paar uur mee.

Ik heb de server al in debugging mode laten draaien, maar daar haal ik ook niet uit waarom de server stopt.

Ik heb al weer wat google pagina'tjes afgezocht, maar ik kan niets vinden. De machine is ook dusdanig belangrijk dat ik niet even 3 weken kan gaan zoeken

Iemand suggesties? Wat kan het zijn? Hoe kan ik beter zien wat voor problemen optreden, want de debug-log is 99% shit?

Wat ik nog vergat: het is het hart van het systeem. Email virtuals, aliases, domein informatie... alles wordt uit deze database geladen. Het aantal queries is toch vrij laag: een keer per minuut worden er honderd queries doorheen geramd, maar die heeft ie binnen 2 seconden allemaal verwerkt. En dan verder maximaal 10 per minuut die allemaal binnen een seconde afgehandeld worden.

Nog wat info:
gemiddelde load: 0.20
geheugen: 1GB
swap beschikbaar: 900MB
postgres versie: 7.2.3 (ook voor het vervangen van de hdd werd deze versie vervangen)

[ Voor 13% gewijzigd door Verwijderd op 29-06-2003 19:19 ]

[xoror]

gokje, vergeten vacuum te draaien na reimport ?

[ACM]

Open je niet gewoon pconnects naar postgresql die je vervolgens niet afsluit? Iig is dit geen crash, maar een vollopende connectielimiet lijkt me.

Start het eens met de logging opties (pg_ctl -l logfile ...) als je dat niet al doet en kijk wat er in de logfiles van postmaster verschijnt.

[ Voor 15% gewijzigd door ACM op 29-06-2003 20:00 ]

[Verwijderd]

xoror schreef op 29 June 2003 @ 19:37:
gokje, vergeten vacuum te draaien na reimport ?

hmmz, kan ik nog proberen... maar de bestanden zijn gewoon 1:1 gekopieerd zonder import export van een unmounted filesystem. Mag niets mis mee zijn volgens mij... ik ga 't even proberen

ACM schreef op 29 June 2003 @ 19:58:
Open je niet gewoon pconnects naar postgresql die je vervolgens niet afsluit? Iig is dit geen crash, maar een vollopende connectielimiet lijkt me.

Start het eens met de logging opties (pg_ctl -l logfile ...) als je dat niet al doet en kijk wat er in de logfiles van postmaster verschijnt.

helaas, connectielimiet denk ik niet. Ik start op met
/usr/local/pgsql/bin/postmaster -S -D datadir -i -h 127.0.0.1 -N 256 -B 512
dat is goed voor 256 connecties. Als ik op een willekeurig moment connecties tel met netstat kom ik nooit boven de 20 uit. Ga wel effe dat loggen proberen. Thanx voor de suggestie.

[Verwijderd]

hmmz, kan ik nog proberen... maar de bestanden zijn gewoon 1:1 gekopieerd zonder import export van een unmounted filesystem. Mag niets mis mee zijn volgens mij... ik ga 't even proberen

vacuum full van de enige database in de server was binnen 5 seconden klaar. We gaan gewoon logging nu even aanzetten, en kijken hoe lang hij dit keer up blijft.

[ACM]

Verwijderd schreef op 29 June 2003 @ 20:55:
vacuum full van de enige database in de server was binnen 5 seconden klaar. We gaan gewoon logging nu even aanzetten, en kijken hoe lang hij dit keer up blijft.

Open es een psql-connectie en op het moment dat ie "gecrashed is", kan je dan nog queries uitvoeren?

Vergeet voor het loggen niet deze twee opties:
log_connections = true
log_timestamp = true


Start postgresql eens met de optie stats_command_string = true en dan kan je via die al eerder genoemde psql-console die openstaat hopelijk zien wat er gebeurt:

code:

acm=# select * from pg_stat_activity;
 datid  | datname | procpid | usesysid | usename | current_query
--------+---------+---------+----------+---------+---------------
 223013 | acm     |   19154 |      100 | acm     | <IDLE>
(1 row)

En als ie "gecrashed is" kijk dan ook naar de output van `ps xaufww` op je console, als het goed is zie je daar iets meer aan kwa aantal postgres-processen.

[ Voor 9% gewijzigd door ACM op 29-06-2003 21:23 ]

[Verwijderd]

ACM schreef op 29 juni 2003 @ 21:20:
[...]

Open es een psql-connectie en op het moment dat ie "gecrashed is", kan je dan nog queries uitvoeren?

Meestal wel, ja. Bestaande verbindingen blijven dan volledig alive, terwijl niuewe verbindingen worden geweigerd met de melding
psql: could not connect to server: Connection refused
Is the server running on host 127.0.0.1 and accepting
TCP/IP connections on port 5432?
en de welbekende andere 'connection refused' melding wanneer ik de unix socket probeer.

Vergeet voor het loggen niet deze twee opties:
log_connections = true
log_timestamp = true

Thank you very much. Dat is heel nuttig!

Start postgresql eens met de optie stats_command_string = true en dan kan je via die al eerder genoemde psql-console die openstaat hopelijk zien wat er gebeurt:

code:

acm=# select * from pg_stat_activity;
 datid  | datname | procpid | usesysid | usename | current_query
--------+---------+---------+----------+---------+---------------
 223013 | acm     |   19154 |      100 | acm     | <IDLE>
(1 row)

En als ie "gecrashed is" kijk dan ook naar de output van `ps xaufww` op je console, als het goed is zie je daar iets meer aan kwa aantal postgres-processen.[/quote]
Gaan we doen. Even wachten tot ie weer 'gecrashed' is...

[Verwijderd]

Verwijderd schreef op 29 June 2003 @ 20:55:
[...]

vacuum full van de enige database in de server was binnen 5 seconden klaar. We gaan gewoon logging nu even aanzetten, en kijken hoe lang hij dit keer up blijft.

Even een update: Sinds ik gisteren deze vacuum full + reindex heb gedraaid is postgresql netjes connecties blijven accepteren. Het lijkt er dus op dat alles nu weer werkt. Maar we houden het nog even in de gaten of het idd stabiel blijft nu. (aub dus ook nog geen slotje)

Thanx voor de hulp!

[Verwijderd]

helaas... het blijft niet stabiel. Gisteren weer een keer ermee gestopt en ook vandaag weer 2 keer.

Nou heb ik wel tijd gehad om de logs te checken etc. De eerste log was mislukt (onleesbaar veel onzin gelogd), maar de tweede was okay. En wat zie ik: helemaal niets nuttigs. Er is niets super-vreemds gebeurd.

10:51:09 - pq_recvbuf: unexpected EOF on client connection (een paar keer achter elkaar)
10:51:22 - nieuwe connectie
11:11:06 - pq_recvbuf: unexpected EOF on client connection
... Diverse select queries, maar geen nieuwe connecties. Misschien niet nodig geweest?...
11:18:xx - postgresql stopt nieuwe connecties te accepteren. hier wordt GEEN ENKELE melding van gemaakt. Bestaande connecties blijven gewoon alive.

een unexpected EOF is vervelend, maar brengt toch niet de hele server down? of wel soms? En zelfs al zou het gebeuren, waarom wordt het dan niet gelogd? En beter nog, waarom brengt het de hoofdserver down, want alle child postmastertjes blijven leven terwijl de parent gewoon pleite is.

code:

20476 ?        S      0:00 /usr/local/pgsql/bin/postmaster
20477 ?        S      0:00  \_ postgres: stats buffer process
20480 ?        S      0:00  |   \_ postgres: stats collector process
20588 ?        S      0:00  \_ postgres: mydb mydb 217.67.231.179 idle
20589 ?        S      0:00  \_ postgres: mydb mydb 217.67.231.179 idle
20590 ?        S      0:00  \_ postgres: mydb mydb 217.67.231.179 idle
20592 ?        S      0:00  \_ postgres: mydb mydb 217.67.231.179 idle

zoiets dus. Proces 20476 verdwijnt op het moment van een crash, alle childs blijven.

verder echt no clue. Nog andere suggesties?

[xoror]

als je nou eens doet wat ACM zei, dan kan je zien wat de clients doen.
Maar het kan bijv ook hardware/ram probleem zijn. Daar ruikt het een beetje naar
als ik moet gokken. probeer eens memtest oid.

je kan eens proberen op de postgresql mailinglist. lost het probleem zich op als je pg_dump en pg_restore doet van de data ?

anders moet je even kijken of het nog voorkomt in 7.3.3

[Verwijderd]

xoror schreef op 01 July 2003 @ 15:25:
als je nou eens doet wat ACM zei, dan kan je zien wat de clients doen.

heb ik gedaan. word ik helaas niets wijzer uit. Het lijkt wel random te gebeuren.

Maar het kan bijv ook hardware/ram probleem zijn. Daar ruikt het een beetje naar
als ik moet gokken. probeer eens memtest oid.

Ik heb inderdaad gisteren een afspraak gemaakt voor vandaag met de colocatie provider om hardware check uit te gaan voeren. Het vreemde is alleen, het was een werkend systeem, tot ik een andere installatie er op zette. Die installatie komt rechtstreeks uit een andere productiemachine die al sinds de installatie (een half jaar) crashvrij is.

je kan eens proberen op de postgresql mailinglist. lost het probleem zich op als je pg_dump en pg_restore doet van de data ?

Heb ik geprobeerd, maar loste niets op.

anders moet je even kijken of het nog voorkomt in 7.3.3

dan zou het probleem ook op het andere systeem, waar dit systeem nu een kopie van is, moeten voorkomen...

Anyway, thanks voor de suggesties. Vanmiddag even langs, en we zien wel wat het oplevert.