Обсуждение: Strange highload on server
Hello,
We have been running our database server without any problem or reboot at all for a year. Yesterday we needed to change servers so we went ahead and installed the same postgresql version (8.2.1), restored the database files, ran some tests offline. Everything was good. As soon as we launch the site and the traffic hits the server, the load is going up to the sky, and the top command lists nothing but postgres processes. Strangely, even if i kill Apache and stop the traffic, somehow the load doesnt cool down, so i thought this might be an issue with postgres processes not timing out or something. But we use a very minimal config and the same config was being used in our other server without any problem.
Server Details:
Dual Intel Xeon 3.20
6 GB Ram
RHEL 4
2.6.9-67.0.22.ELsm x86_64 x86_64 x86_64 GNU/Linux
postgresql.conf
listen_addresses = '192.168.100.58' # what IP address(es) to listen on;
port = 5432 # (change requires restart)
max_connections = 250 # (change requires restart)
shared_buffers = 20MB
max_fsm_pages = 153600
Other values default mostly.
I tried to increase shared buffers, but kernel didnt allow me. And since it was working fine with the exact settings in the other server, which is pretty similar (Dual Opteron 270 / 6 GB ram / Rhel 4). I didnt wanna mess it up really.
During the high load spike, pg_stat_activity shows dozens of queries from the site, and i cant really investigate it, cause it spikes up so fast and if we dont kill the postgres, it goes up to a load of 200 easily.
Any ideas what may be causing this?
Thank you for your replies
Aras Angelo
We have been running our database server without any problem or reboot at all for a year. Yesterday we needed to change servers so we went ahead and installed the same postgresql version (8.2.1), restored the database files, ran some tests offline. Everything was good. As soon as we launch the site and the traffic hits the server, the load is going up to the sky, and the top command lists nothing but postgres processes. Strangely, even if i kill Apache and stop the traffic, somehow the load doesnt cool down, so i thought this might be an issue with postgres processes not timing out or something. But we use a very minimal config and the same config was being used in our other server without any problem.
Server Details:
Dual Intel Xeon 3.20
6 GB Ram
RHEL 4
2.6.9-67.0.22.ELsm x86_64 x86_64 x86_64 GNU/Linux
postgresql.conf
listen_addresses = '192.168.100.58' # what IP address(es) to listen on;
port = 5432 # (change requires restart)
max_connections = 250 # (change requires restart)
shared_buffers = 20MB
max_fsm_pages = 153600
Other values default mostly.
I tried to increase shared buffers, but kernel didnt allow me. And since it was working fine with the exact settings in the other server, which is pretty similar (Dual Opteron 270 / 6 GB ram / Rhel 4). I didnt wanna mess it up really.
During the high load spike, pg_stat_activity shows dozens of queries from the site, and i cant really investigate it, cause it spikes up so fast and if we dont kill the postgres, it goes up to a load of 200 easily.
Any ideas what may be causing this?
Thank you for your replies
Aras Angelo
"Aras Angelo" <araskoktas@gmail.com> writes:
> We have been running our database server without any problem or reboot at
> all for a year. Yesterday we needed to change servers so we went ahead and
> installed the same postgresql version (8.2.1), restored the database files,
> ran some tests offline. Everything was good. As soon as we launch the site
> and the traffic hits the server, the load is going up to the sky, and the
> top command lists nothing but postgres processes. Strangely, even if i kill
> Apache and stop the traffic, somehow the load doesnt cool down, so i thought
> this might be an issue with postgres processes not timing out or something.
> But we use a very minimal config and the same config was being used in our
> other server without any problem.
I suspect you forgot to re-ANALYZE your tables after reloading all the
data.
BTW, running a production site on 8.2.1 borders on negligence. You're
missing more than a year and a half's worth of bug fixes, including at
least one serious risk of data loss.
regards, tom lane