Postgres process - high CPU load

Hey Bob & Barry,

Thanks for your messages.  My reading of this board suggests that high CPU load is that the main indicator of pgsql DB corruption on Sophos UTM (still want to call it Astaro).  Off board reading (maintenance - PostgreSQL Database Data File Integrity Check - Database Administrators and Tracking Down Database Corruption With psql | End Point Blog) suggests it might be possible to pg_dump and pg_restore the database and catch corruption to metadata that way.  However, this would be a fools errand as the primary data is logs, and that log data is okay.  

So the diagnosis is the treatment, i.e. if I rebuild the database and the problem goes away, then it must have been a database corruption.   BTW Barry, I have an quad core Intel Xeon X3470 @ 2.93GHz with 8Gig RAM on a SATA disk.  So disk probably could, and should be upgraded to SAS with higher throughput.  More memory would also be good. Serves about 1500 users.   Database size is 8.3Gig, so definitely does not fit in memory.  

A final thought about reporting: There are only three database configurations; small, medium and large for (2, 4 and 8Gig memory configs respectively).   However given the many to many relationships of relational data of just for instance the user and the url, I would expect the database to grow by at least the square of usage.   So all the biggest changes in database size and performance requirements will be in the larger systems.   Non root tools to monitor size, throughput and cache hit ratio would be especially useful addition - the database equivalent of dumping a routing table in advanced tools.    

In three months when the database has repopulated I can tell you if the rebuild worked w.r.t. performance.   

Thanks again for this thread.

P.S. IMO, Postgresql should live on a ZFS filesystem to ensure disk data integrity.   See most interesting presentation http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/zfslast.pdf


>>>>>>>>>>>>>>>>>>>>>>>
Following rebuild of database database size has dropped from 8.3Gig, to 12Meg as shown by 

du -h /var/log/reporting/pgsql

However it is growing at 6M per busy hour.   So assuming 10 busy hours per day, 5 days per week, then in three months it should be about 4 Gig.... hmmm.   

Performance as shown by

vmstat 5

shows system very happy on performance side.  Little IO wait.  Idle time back in 90% range.  Good. 

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0 1002920 2669720  71804 2271732    0    0     0   384 4594 6555  7  1 89  2  0
 1  0 1002920 2675748  71828 2262716    0    0     0   485 5040 7203 11  3 86  1  0
 0  0 1002920 2676220  71852 2264824    0    0     0   411 3391 6723  6  1 91  1  0
 0  0 1002912 2677316  71936 2264924    0    0     8   229 3321 6190  3  1 94  2  0

Hey Bob & Barry,

Thanks for your messages.  My reading of this board suggests that high CPU load is that the main indicator of pgsql DB corruption on Sophos UTM (still want to call it Astaro).  Off board reading (maintenance - PostgreSQL Database Data File Integrity Check - Database Administrators and Tracking Down Database Corruption With psql | End Point Blog) suggests it might be possible to pg_dump and pg_restore the database and catch corruption to metadata that way.  However, this would be a fools errand as the primary data is logs, and that log data is okay.  

So the diagnosis is the treatment, i.e. if I rebuild the database and the problem goes away, then it must have been a database corruption.   BTW Barry, I have an quad core Intel Xeon X3470 @ 2.93GHz with 8Gig RAM on a SATA disk.  So disk probably could, and should be upgraded to SAS with higher throughput.  More memory would also be good. Serves about 1500 users.   Database size is 8.3Gig, so definitely does not fit in memory.  

A final thought about reporting: There are only three database configurations; small, medium and large for (2, 4 and 8Gig memory configs respectively).   However given the many to many relationships of relational data of just for instance the user and the url, I would expect the database to grow by at least the square of usage.   So all the biggest changes in database size and performance requirements will be in the larger systems.   Non root tools to monitor size, throughput and cache hit ratio would be especially useful addition - the database equivalent of dumping a routing table in advanced tools.    

In three months when the database has repopulated I can tell you if the rebuild worked w.r.t. performance.   

Thanks again for this thread.

P.S. IMO, Postgresql should live on a ZFS filesystem to ensure disk data integrity.   See most interesting presentation http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/zfslast.pdf


>>>>>>>>>>>>>>>>>>>>>>>
Following rebuild of database database size has dropped from 8.3Gig, to 12Meg as shown by 

du -h /var/log/reporting/pgsql

However it is growing at 6M per busy hour.   So assuming 10 busy hours per day, 5 days per week, then in three months it should be about 4 Gig.... hmmm.   

Performance as shown by

vmstat 5

shows system very happy on performance side.  Little IO wait.  Idle time back in 90% range.  Good. 

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0 1002920 2669720  71804 2271732    0    0     0   384 4594 6555  7  1 89  2  0
 1  0 1002920 2675748  71828 2262716    0    0     0   485 5040 7203 11  3 86  1  0
 0  0 1002920 2676220  71852 2264824    0    0     0   411 3391 6723  6  1 91  1  0
 0  0 1002912 2677316  71936 2264924    0    0     8   229 3321 6190  3  1 94  2  0