Re: PG quitting sporadically!!

From: "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com>
To: "Postgres General" <pgsql-general(at)postgresql(dot)org>, gsmith(at)gregsmith(dot)com
Subject: Re: PG quitting sporadically!!
Date: 2008-02-15 00:10:36
Message-ID: e373d31e0802141610w4ff1cb60j2a0e3ae7a400e475@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

Thanks. Comments below. (PS: I am still unable to connect to
postgresql even in SSH! I see this message:

psql: could not connect to server: Connection timed out
Is the server running on host "localhost" and accepting
TCP/IP connections on port 5432?

Yes of course the localhost is running the pgsql server and that port
is allowed!

> You should consider whether that's because a checkpoint is happening at
> that point. You didn't mention anything about your disk+controller
> information to have an idea how likely that is. Consider increasing
> checkpoint_warning=3600 so that you'll always get a note in the logs when
> a checkpoint happens; if those line up with your client disconnects that
> will be telling you something.
>

I am not sure what checkpoint stuff means. But I added that entry, and
now my log has ONLY this:

LOG: test message did not get through on socket for statistics collector
LOG: disabling statistics collector for lack of working socket
LOG: database system was shut down at 2008-02-14 17:53:13 CST
LOG: checkpoint record is at 8/E4BE7CF8
LOG: redo record is at 8/E4BE7CF8; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/296662974; next OID: 89700
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system is ready

> On the logging size, you may want to also enable
> log_min_duration_statement ; around 500 (milliseconds) would be a
> reasonable starting value. That will show you what queries are taking a
> long time to handle.

I have this at 5000. I think I first want to track those that take
more than 5 seconds. But for now, the log is useless as mentioned
above.

> Be aware that when 8.2.3 was released, 8.2 had only been out for two
> months. There's another 11 months worth of accumulated bug fixes in
> 8.2.6, including some that can cause the server to slow or crash. It's
> not a difficult upgrade (no changes to the database) and you should
> consider it. There are plenty of known and already fixed problems in
> 8.2.3 you could be running into.

Thanks, I can do that, but the upgrade process is not very simple or
automated and will take backup of database and all that rigmarole.Last
time I remember, I had to seek help from this forum to do that simple
task, because something had gone remiss.

Is there an easy RPM method of upgrading postgresql without
backingup/restoring etc? I am on CentOS 4.

> > max_connections = 150
> > maintenance_work_mem = 512MB
> > shared_buffers = 330MB
> > work_mem = 100MB
>
> That's a really high setting for work_mem with this many connections; are
> you aware that combination can easily use 15GB of RAM?

I didn't know that, but it had been working for over a year. I have
4GB of RAM. I have changed this now to 10MB, the work_mem, but that
isn't helping.

I'd appreciate any other info. Thanks!

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Cook 2008-02-15 00:15:10 Re: Perceived weaknesses of postgres
Previous Message Jeff Davis 2008-02-15 00:07:42 Re: Strict-typing benefits/costs

Browse pgsql-patches by date

  From Date Subject
Next Message Hiroshi Saito 2008-02-15 00:29:55 Re: Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)
Previous Message Brendan Jurd 2008-02-15 00:09:44 Re: Show INHERIT in \du