Re: [HACKERS] posmaster failed under high load - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [HACKERS] posmaster failed under high load
Date
Msg-id 199905041502.AAA02855@ext16.sra.co.jp
Whole thread Raw
In response to Re: [HACKERS] posmaster failed under high load  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: [HACKERS] posmaster failed under high load  (Oleg Bartunov <oleg@sai.msu.su>)
Re: [HACKERS] posmaster failed under high load  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
> > I don't think so unless you increased the shared buffer size using -B
> > option. Stock 6.4.2 is very buggy with the shared memory
> > usage. Probably it's the cause. Try Tom Lane's fix or 6.5b. I have
> > tested 6.5b with 128 backends running and it seems very stable.
> 
> Yes, I used 6.4.2 + LIMIT patch, I'll try 6.5 from cvs

You need Tom Lane's share mem fix patch if you use 6.4.2. 6.5 has the
fix.

> I run postmaster with -B 1024 option - is this too much ?

No. -B 1024 means 8MB shared mem that should be ok on x86/Linux (I
think most x86 based Linux allow 32MB shared mem).

> Thanks a lot, I got several times a problem with file descriptors,
> it looks like every backend opens abot 90 files. I'll try your 
> hints.

But be carefull lower # of file descriptors per backend might cause
lower performance because of the file opening overhead. So you should
increase the file table entries in the system first.

>Why not add your experience how to work with postgres under high
> load to Linux specific FAQ ?

I'm not good at English, that is the reason:-)

BTW, FreeBSD box has more serious problems than Linux since the
default kernel has lower limit of file descriptors (~700). This should
be noted somewhere in the docs too.
---
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Todd Graham Lewis
Date:
Subject: Re: [HACKERS] XIDTAG ???
Next
From: Tom Lane
Date:
Subject: Nasty resource-leak problem in sort code