From: | Laszlo Nagy <gandalf(at)shopzeus(dot)com> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | rebellious postgres process |
Date: | 2008-11-04 07:42:44 |
Message-ID: | 490FFCF4.2050500@shopzeus.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
This is what I see in "top" since two days:
last pid: 95702; load averages: 2.48, 2.69,
2.75
up 3+02:08:49 10:27:58
257 processes: 3 running, 246 sleeping, 8 zombie
CPU states: 15.5% user, 0.0% nice, 22.1% system, 1.3% interrupt, 61.1%
idle
Mem: 864M Active, 6028M Inact, 512M Wired, 254M Cache, 214M Buf, 211M Free
Swap: 10G Total, 500K Used, 10G Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
COMMAND
677 pgsql 1 107 0 22396K 5460K CPU3 6 52.4H 99.02%
postgres
The processi is using 100% CPU for 52 hours! Here it is:
%ps axl | grep 677
70 677 666 757 107 0 22396 5460 select Rs ?? 3144:50.88
postgres: stats collector process (postgres)
Is this normal? Fortunately, we have more processors in this system and
it is not causing slow-down. But I really need to know what is happening
here. I believe it is not the way it should work.
Yesterday the system was restarted suddenly, and this process might be
the reason for this. After the restart, the process is doing the same
thing again:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
COMMAND
904 pgsql 1 105 0 22396K 5332K CPU3 3 386:05 99.22%
postgres
Here is some more info:
Hardware: Two Quad Xeon 2.5GHz processors, 8GB RAM, RAID with 2GB cache
and BBU, 10 SATA2 disks in RAID 1+0 OS: FreeBSD 7.0 amd64
Postgresql: 8.3
Databases: two bigger ones, total database size on disk is about 10GB,
used mostly read-only, but some smaller tables updated frequently.
I don't think that it needs stat collection continuously.
Thanks,
Laszlo
From | Date | Subject | |
---|---|---|---|
Next Message | sathiya psql | 2008-11-04 12:25:51 | epqa; postgres performance optimizer support tool; opensource. |
Previous Message | Kevin Neufeld | 2008-11-04 00:29:22 | many tables vs large tables |