Re: RESOLUTION: pq_recvbuf: unexpected EOF

Hello,

RESOLUTION TO THE PROBLEM:

There was a problem with some memory simms. Memtest spotted it (Great
program, thanks), and then we confirmed it. Similar testing run on
another identical box produced no errors.

Thank you all, Tom, Scott, Alvero, and Joe for amazing support.

--- "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> wrote:
> On Fri, 25 Apr 2003, David Link wrote:
>
> > Hi
> >
> > We went live a months back with very low volumn (so far) on
> > subscription based website. And we are very happy. App built on
> 100%
> > open source toolstack, with PostgreSQL (of course) at it's heart.
> I
> > Can't tell you how pleased I am with Pg (coming from 5 year
> experience
> > with Oracle).
> >
> > I'm writing to discuss some scaling issues. After bombarding the
> > system using HTTPD::Bench::ApacheBench (from CPAN), she starts to
> fail
> > some where around 30-50 concurrent requests, depending on the
> query.
> > See error messages below.
> >
> > Any advice would be helpful.
> > Thanks. David Link, White Plains, NY
> >
> > Specs:
> > h/w: Dual AMD Athalon
> > Red Hat 8.0 / Linux 2.4.7
> > Apache 1.3.27 (w/ mod_perl)
> > PostgreSQL 7.3.1
> > perl 5.8
> >
> > DB Specs:
> > Size: 10 GB
> > tables: 280 / largest: 550,000 tuples / 25,000 relpages (8K)
> > indexes: 650
> >
> > ERROR:
> >
> > [4] LOG: pq_recvbuf: unexpected EOF on client connection
> > [4] LOG: server process (pid 28353) was terminated by signal 11
>
> Sig 11 usually means flakey hardware. Check out www.memtest86.com
> and do
> a couple dozen kernel or postgresql compiles to see if they get sig
> 11s
> while running.
>
> It's not uncommon for an error to be in a relatively unused spot of
> memory, and only show up under heavy load as causing problems.
>

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com