Postgres process - high CPU load

My guess is that you have one or more broken PostgreSQL database(s).  If you have Astaro Support on the 120, you should ask your reseller to submit a support request.

If you don't have support, or, if you don't mind losing your history (reporting and logs), you could copy an unencrypted configuration backup into the root directory of a USB memory stick, do a factory reset and reboot the 120 with the USB memory stick inserted.

Cheers - Bob

I have Astaro Support on the 120, but it is good chance to try recovery procedure [:)] Thanks a lot guys!

I did a few things to fix the CPU usage. When I logged into the Shell, and ran 'top' I noticed that postgresql was consuming a good majority of CPU. So, doing a lot of research, I noticed that when I disabled "Web Security" on the reporting settings, the CPU spikes subsided. But this is unacceptable, as it needs to be enabled in order to receive the filtering reports on the Executive report (one of the reasons we went with the ASG220 was for the reporting). Anyway, the CPU was spiking to 60-80% and staying there for 6-8 minutes, and it'd drop for only a few minutes and back at it again. Looked like a fine toothed comb on the CPU usage chart. Anyway, I also noticed the RAM sitting at about 24% and the swap sitting at 10%.

  So my first order was to try to reduce disk I/O. As root in the shell, I executed 'sysctl -w vm.swappiness=10'. After which, I executed 'swapoff -a', followed by 'swapon -a'. Which effectively flushed the swap. My memory usage increased, but this should help extend the disk life too. It wasn't the CPU usage solution, but did ease my mind some. I don't like to swap to disk if the memory is available. (Edit: The original swappiness was set at the Linux default of 60).

  Anyway, next course, I edited the postgres config file located at /var/storage/pgsql/data/postgresql.conf, and at the bottom of the file, I added the line 'effective_cache_size = 192MB'. Now on my ASG220, 192MB is approximately 10% of the total system memory, you may want to adjust this down if your memory is less. But I saved the file, and restarted Postgresql (/etc/init.d/postgresql restart). It spiked for the initial startup, but after which, I've not seen a spike yet. I've even re-enabled Web Security, and even set the reporting detail level back to "3 levels of URL" and no spikes! AWESOME! Perhaps Astaro/Sophos can roll this out as a permanent patch. It The swappiness isn't necessary, but the effective cache size seems to be the fix. We have the ASG220 v8.301 with 4 multi-pathed internet connections totalling >70Mbps in inbound bandwidth.

I'm a happy camper again! Woot!

Matt
IT Operations

Hi Matt,

... I added the line 'effective_cache_size = 192MB' ...  and restarted Postgresql (/etc/init.d/postgresql restart). ...

chances are that the restart of Postgres fixed your problem, not the line you added to the config. Up to Version 8.910 the postgres autovacuum analyzer runs only after about 20% of a table have been changed (inserted/updated/deleted). We found out that this  threshold is way to high and might give the query planner statistics which are of by several orders of magnitude for "today" querys (which are - unfortunately - the most common querys), resulting in quite bad query execution and really low performance.

This issue is tracked as Mantis ID #20713 and has been fixed with the last beta release (UTM-V9 8.920).

Cheers,
Kai

Hi Matt,

... I added the line 'effective_cache_size = 192MB' ...  and restarted Postgresql (/etc/init.d/postgresql restart). ...

chances are that the restart of Postgres fixed your problem, not the line you added to the config. Up to Version 8.910 the postgres autovacuum analyzer runs only after about 20% of a table have been changed (inserted/updated/deleted). We found out that this  threshold is way to high and might give the query planner statistics which are of by several orders of magnitude for "today" querys (which are - unfortunately - the most common querys), resulting in quite bad query execution and really low performance.

This issue is tracked as Mantis ID #20713 and has been fixed with the last beta release (UTM-V9 8.920).

Cheers,
Kai

The restarting of Postgres was not what resolved the issue, as I had restarted Postgres several times, with prior changes (making a change, restart Postgres, wait 10 or so minutes to see if the CPU spiked, when it did, revert the change, then try the next thing), prior to landing on this change. This change was probably the 5th or 6th thing tried, that finally worked. It is still working to this day. [H]

Matt,

for what it is worth - I think you were right. I was experiencing the exact same behavior with constant high CPU load caused by the progres process. I tried all suggested fixes of reducing data retention time etc. etc. but nothing worked. 

Multiple system restarts did also not do the trick (in case anybody still wants to hang on to that one).

After I applied your suggested 'effective_cache_size = 192MB' setting to postgresql.conf and then restarted the entire system the CPU usage went back to normal.

Interesting thing is that I did not have any issues with high CPU load until I upgraded to v8.301 and then to v8.302. The only other changes that coincided with these "firmware" upgrades was that I started using web proxy filters with active directory SSO (kerberos). Previously I did not use SSO.

Anyway - there is definitely something wrong with the progres setup. I run a small home use installation with two internet uplinks and a handful of family members as users - nothing big or complex, yet my CPU utilization for progres went up to 87%!