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!
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 |
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 |