Re: postgresql 8 abort with signal 10

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: Alexandre Biancalana <biancalana(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: postgresql 8 abort with signal 10
Date: 2005-05-03 17:08:49
Message-ID: 1115140128.13303.1486.camel@state.g2switchworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 2005-05-03 at 11:36, Alexandre Biancalana wrote:
> >>You need to find out what's triggering that. Turning on query logging
> >>would be a good way of investigating.
>
> Which directives can I use to enable this ?
> debug_print_parse ? debug_print_rewritten ? debug_print_plan ?
> debug_pretty_print ?
>
>
> >>Rather large, shared buffers for a machine with only 1 gig of ram. 640
> >>Meg of RAM means the kernel is basically double buffering everything.
> >>have you tested with smaller settings and this setting was the best?
>
> I had 256 of RAM then I increase to 1GB thinking this could be a
> problem of out of memory or a buggy memory...... After this "upgrade"
> I increase the numbers of shared buffers,etc
>
> It's important to say that the max memory usage reach to only 80%.
>
> What values do you suggest ?

Generally 25% of the memory or 256 Megs, whichever is less. In your
case, they're the same. The Reasoning being that the kernel caches,
while postgresql only really holds onto data as long as it needs it,
then frees it, so having a really huge buffer space lets postgresql
flush the kernel cache, then the next access, after postgresql has freed
the memory that was holding the data, now has to go to disk.

The kernel is generally a lot better at caching than most apps.

So, 32768 is about as big as i'd normally go, and even that may be more
than you really need. Note that there's overhead in managing such a
large buffer as well. With pgsql 8.x and the new caching algorithms in
place, such overhead may be lower, and larger buffer settings may be in
order. But if testing hasn't shown them to be faster, i'd avoid them
for now and see if your signal 10 errors start going away.

If they do, then you've likely got a kernel bug in there somewhere. If
they don't, I'd suspect bad hardware.

> >>You might want to look in your signal man page on BSD and see what
> >>signal 10 means. On solaris it's a bus error. Not a clue what it is in
> >>FreeBSD myself though.
>
> FreeBSD man page say: 10 SIGBUS
>
> The system does not generate core dump file for this error.....

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2005-05-03 17:10:23 Re: Deep integration of PostgreSQL with Apache
Previous Message Michael Fuhr 2005-05-03 17:06:27 Re: postgresql 8 abort with signal 10