Обсуждение: Transaction-Overflow
Hi, i've a problem with my postgresql database (v8.1.5-13 on opensuse 10.2). The database transaction limit is running over and postgres does a restart. I do daily a "vacuum verbose analyze" over the hole database. So what I'm doing wrong? The db has restarted itself to prevent a transaction-override. The log ouput says: ... DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden,weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht hat. TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können. WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden,weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht hat. TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können. FATAL: das Datenbanksystem ist im Wiederherstellungsmodus FATAL: das Datenbanksystem ist im Wiederherstellungsmodus FATAL: das Datenbanksystem ist im Wiederherstellungsmodus LOG: alle Serverprozesse beendet; initialisiere neu LOG: Datenbanksystem wurde am 2007-08-07 13:01:19 CEST unterbrochen LOG: Checkpoint-Eintrag ist bei 41/4D06D224 LOG: Redo-Eintrag ist bei 41/4D049AF0; Undo-Eintrag ist bei 0/0; Shutdown FALSE LOG: nächste Transaktions-ID: 114926807; nächste OID: 230334262 LOG: nächste MultiXactId: 1; nächster MultiXactOffset: 0 LOG: Datenbanksystem wurde nicht richtig heruntergefahren; automatische Wiederherstellung läuft LOG: Redo beginnt bei 41/4D049AF0 LOG: Datensatz mit Länge null bei 41/4DCF8A48 LOG: Redo fertig bei 41/4DCF8A20 LOG: Datenbanksystem ist bereit LOG: Grenze für Transaktionsnummernüberlauf ist 1187023047, begrenzt durch Datenbank »isohost« ... The vacuum before this looks fine. The only thing is a max_fsm_pages warning: ... INFO: Free-Space-Map enthält 210922 Seiten in 32 Relationen DETAIL: Es sind insgesamt 200000 Page-Slots in Benutzung (einschließlich Overhead). 391152 Page-Slots werden benötigt, um den gesamten freien Platz verwalten zu können. Aktuelle Begrenzungen sind: 200000 Page-Slots, 100 Relationen, 1180 KB in Benutzung. HINWEIS: Anzahl der benötigten Page-Slots (391152) überschreitet max_fsm_pages (200000) HINT: Erhöhen Sie eventuell den Konfigurationsparameter »max_fms_pages« auf über 391152. VACUUM ... Is this my fault? So is the solution to set max_fsm_pages to aroung 450000? Off Topic: Theres a little fault in the log output (fms instead of fsm!), is this already changed in the actual version? Thanks a lot! Regards, Martin ______________________________________________________________________________ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134
pingu.freak@web.de writes:
> i've a problem with my postgresql database (v8.1.5-13 on opensuse 10.2). Th=
> e database transaction
> limit is running over and postgres does a restart.
I don't read German well, but as far as I can see there is nothing in
what you posted that suggests a transaction wraparound issue. Something
crashed, clearly, but whatever evidence the log might have about why is
up above what you posted --- all of this looks like a standard crash
recovery cycle.
> Theres a little fault in the log output (fms instead of fsm!), is this alre=
> ady changed in the actual
> version?
Seems to be fixed in CVS HEAD, I didn't check the back branches.
regards, tom lane
Hi Tom, thank you for the very fast answer! On the top in the log file is this, do you know why the pid is killed with 11? I'm a little bit confused :(. LOG: Serverprozess (PID 30399) wurde von Signal 11 beendet LOG: aktive Serverprozesse werden abgebrochen WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden, weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht h at. TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können. WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden, weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht h at. The log says also that the max possible xid is 1187023047: LOG: Grenze für Transaktionsnummernüberlauf ist 1187023047, begrenzt durch Datenbank »mydb« And my DB is already on 1076856894: isohost=# SELECT datname, age(datfrozenxid) FROM pg_database; datname | age -----------+------------ postgres | 116395795 template1 | 116395795 template0 | 116395795 mydb | 1076856894 Should this be the problem? What if the max xid is reached, does postgres then do a restart? How can I clean the counter, this should "vacuum analyze" do, or? Is it possible, that vacuum (without full) doesn't freeing any space, if max_fsm_pages are set to low? I've read somethinglike this in the admin-mailinglist. Thanks a lot! Regards, Martin _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
On Tue, Aug 07, 2007 at 05:34:53PM +0200, pingu.freak@web.de wrote: > On the top in the log file is this, do you know why the pid is killed with 11? I'm a little bit confused :(. > > LOG: Serverprozess (PID 30399) wurde von Signal 11 beendet That means that a backend was killed with a signal 11. IIRC, that indicates faulty hardware. -- Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Вложения
pingu.freak@web.de writes:
> On the top in the log file is this, do you know why the pid is killed with =
> 11? I'm a little bit confused :(.
> LOG: Serverprozess (PID 30399) wurde von Signal 11 beendet
SIG 11 (ie SIGSEGV) is pretty much the typical "generic crash"
indication. It most likely means you ran into a software bug or
corrupted data. There is no reason at all to think that it's got
anything to do with transaction ID wraparound --- that message is
only coming out because it always comes out at a database restart.
What you ought to look into is what *did* cause the crash. Did it
produce a core file, and if so can you get a gdb stack trace from
the core?
regards, tom lane
Hi,
first thanks for your answers.
Now I found some ECC-exceptions in the Kernel.:
EDAC MC0: CE page 0xfeb8e, offset 0x0, grain 4096, syndrome 0xb32, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE - no information available: e7xxx CE log register overflow
EDAC MC0: CE page 0xfeb8e, offset 0x0, grain 4096, syndrome 0xb32, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE - no information available: e7xxx CE log register overflow
EDAC MC0: CE page 0xfeb8e, offset 0x0, grain 4096, syndrome 0xb32, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE - no information available: e7xxx CE log register overflow
EDAC MC0: CE page 0xfeb8e, offset 0x0, grain 4096, syndrome 0xb32, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE - no information available: e7xxx CE log register overflow
EDAC MC0: CE page 0xfeb8e, offset 0x0, grain 4096, syndrome 0xb32, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE - no information available: e7xxx CE log register overflow
This is on both servers, production and backup. Right know, I'm updating the Kernel
to 2.6.22.1. Hopefully this helps :/. But I think there is no hope.
There are also Traces in dmesg:
Code: f3 a5 89 c1 f3 a4 eb 21 89 c8 83 f9 07 76 18 89 f9 f7 d9 83 e1 07 29 c8 f3 a4 89 c1 c1 e9 02 83 e0 03 90 f3 a5 89
c1f3 a4 5e 89 <c8> 5f c3 57 85 c9 56 89 c7 89
d6 79 08 0f 0b 0a 03 71 ce 2c c0
EIP: [<c01c3a2c>] __copy_from_user_ll_nozero+0xd7/0xda SS:ESP 0068:dca2fd94
<4>EDAC MC0: CE page 0xb4124, offset 0x0, grain 4096, syndrome 0xfc1, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE page 0xb4124, offset 0x0, grain 4096, syndrome 0xfc1, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE page 0xb4124, offset 0x0, grain 4096, syndrome 0xfc1, row 4, channel 0, label "": e7xxx CE
EDAC MC0: CE page 0xb4124, offset 0x0, grain 4096, syndrome 0xfc1, row 4, channel 0, label "": e7xxx CE
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000002
printing eip:
c01c3a2c
*pde = 2f39e001
Oops: 0000 [#3]
SMP
last sysfs file: /devices/pci0000:00/0000:00:00.0/class
Modules linked in: nfs lockd nfs_acl sunrpc iptable_filter ip_tables x_tables lp parport_pc parport af_packet joydev st
sr_modipv6 button battery ac apparmor aamatch
_pcre loop dm_mod e1000 ide_cd cdrom i2c_i801 e7xxx_edac edac_mc i2c_core ext3 mbcache jbd edd fan sg gdth aic79xx
scsi_transport_spipiix thermal processor sd_mod sc
si_mod ide_disk ide_core
CPU: 0
EIP: 0060:[<c01c3a2c>] Tainted: G U VLI
EFLAGS: 00010206 (2.6.18.2-34-bigsmp #1)
EIP is at __copy_from_user_ll_nozero+0xd7/0xda
eax: e5f17dbc ebx: 00000001 ecx: 00000006 edx: bff0ef9a
esi: 00000000 edi: 01de802f ebp: 00000006 esp: e5f17d94
ds: 007b es: 007b ss: 0068
Process postmaster (pid: 13414, ti=e5f16000 task=e93710b0 task.ti=e5f16000)
Stack: c01a81f2 00000000 00003466 0000000e e5f17dbc 00000000 00000000 00000001
00000002 00000000 ffff0002 c0100000 00000000 b6b86840 b6b85000 c1d9df20
00001000 d4f6ae9c 21741707 46b611a0 c0125770 3b9aca00 00000163 80000000
Call Trace:
[<c01a81f2>] exit_sem+0x58/0x14c
[<c0125770>] current_fs_time+0x4f/0x5b
[<c014ca56>] get_page_from_freelist+0x2f1/0x371
[<c01487f7>] find_lock_page+0x1a/0x77
[<c015f3b5>] shmem_getpage+0x4f2/0x552
[<c0160375>] shmem_nopage+0xa4/0xb6
[<c0154076>] __handle_mm_fault+0x63e/0xb9c
[<c01325aa>] autoremove_wake_function+0x0/0x35
[<c0108567>] sys_ipc+0x5e/0x1bb
[<c0103ddd>] sysenter_past_esp+0x56/0x79
Code: f3 a5 89 c1 f3 a4 eb 21 89 c8 83 f9 07 76 18 89 f9 f7 d9 83 e1 07 29 c8 f3 a4 89 c1 c1 e9 02 83 e0 03 90 f3 a5 89
c1f3 a4 5e 89 <c8> 5f c3 57 85 c9 56 89 c7 89
d6 79 08 0f 0b 0a 03 71 ce 2c c0
EIP: [<c01c3a2c>] __copy_from_user_ll_nozero+0xd7/0xda SS:ESP 0068:e5f17d94
<6>device eth0 left promiscuous mode
The hardware is 5 years old... It was not possible to get new hardware
for this project. :/
Regards,
Martin
-----Ursprüngliche Nachricht-----
Von: Tom Lane <tgl@sss.pgh.pa.us>
Gesendet: 07.08.07 20:41:08
An: pingu.freak@web.de
CC: pgsql-admin@postgresql.org
Betreff: Re: [ADMIN] Transaction-Overflow
pingu.freak@web.de writes:
> On the top in the log file is this, do you know why the pid is killed with =
> 11? I'm a little bit confused :(.
> LOG: Serverprozess (PID 30399) wurde von Signal 11 beendet
SIG 11 (ie SIGSEGV) is pretty much the typical "generic crash"
indication. It most likely means you ran into a software bug or
corrupted data. There is no reason at all to think that it's got
anything to do with transaction ID wraparound --- that message is
only coming out because it always comes out at a database restart.
What you ought to look into is what *did* cause the crash. Did it
produce a core file, and if so can you get a gdb stack trace from
the core?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220
pingu.freak@web.de writes:
> The hardware is 5 years old... It was not possible to get new hardware
> for this project. :/
Disassembling and cleaning the machine has worked for me in similar
cases. You'd be amazed how much dust can build up on a circuit board
... and if the dust is even a little bit conductive, it can be the cause
of misbehavior.
regards, tom lane
> -----Original Message----- > From: pgsql-admin-owner@postgresql.org > [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Tom Lane > Sent: Wednesday, August 08, 2007 9:34 AM > To: pingu.freak@web.de > Cc: pgsql-admin@postgresql.org > Subject: Re: [ADMIN] Transaction-Overflow > > pingu.freak@web.de writes: > > The hardware is 5 years old... It was not possible to get > new hardware > > for this project. :/ > > Disassembling and cleaning the machine has worked for me in > similar cases. You'd be amazed how much dust can build up on > a circuit board ... and if the dust is even a little bit > conductive, it can be the cause of misbehavior. > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > More likely than electrical conduction is the thermal insulating effect of accumulated dust which will can components to overheat.