Re: PG quitting sporadically!! - Mailing list pgsql-general

From Phoenix Kiula
Subject Re: PG quitting sporadically!!
Date
Msg-id e373d31e0802141610w4ff1cb60j2a0e3ae7a400e475@mail.gmail.com
Whole thread Raw
In response to Re: PG quitting sporadically!!  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: PG quitting sporadically!!
Re: PG quitting sporadically!!
Re: PG quitting sporadically!!
List pgsql-general
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!

pgsql-general by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Strict-typing benefits/costs
Next
From: Stephen Cook
Date:
Subject: Re: Perceived weaknesses of postgres