Postgres process - high CPU load

Hi, Matt, and welcome to the User BB!

Normally, users with support should not change anything from the command line as that can void the support contract.  There's been a lot of discussion here about swappiness, and I think most of us have been brought around to the belief that the developers know what they're doing with that.  You may have found something with that cache setting though, but I have to admit to almost-total ignorance about the internals of PostgreSQL.

I'm not seeing this problem at any of my clients.  Did you check the Selfmonitoring and System messages logs to confirm that you don't have a broken PostgreSQL table?  If so, then it would seem that you've made a great discovery and that a developer would be interested in your idea.

Cheers - Bob

Thanks! When I applied the PGSQL fix, I was excited to help anyone out there with the issue. We have near 50 employees working on the internet here, and that has a great deal to do with the high volume of reporting. Any time the system hits disk, you'll run into a bottleneck. Especially when it involves database activity.

I'd imagine that with the Swappiness, it may be just a matter of "there are bigger fish to fry" with the engineers, and they don't have the time to look into such a petty matter. Also, as with that, the more features you enable, like IPS, etc, the more physical memory is used. If you're already close to the physical memory being maxed out, then changing the swappiness may be a bad idea. But in my instance, I'm not even using 50% even with the swappiness change (see attached Mem Usage graph). 

As far as the PostgreSQL, there were no indications of any database corruption. We had engineers galore looking at it and the only thing they could say is to disable Web Security reporting. Turning the detail level down didn't help much. You can see my CPU usage history now (attached). The spikes on the left are while I was working on discovering the issue. You can see once I applied the effective cache size, that the spikes subsided. We have near 50 users, and all are on the internet, as we are a web-based company. I've re-enabled all needed options in reporting with little to no jump in CPU. Quite an awesome feeling! The "Known Issues" say it's fixed in 8.303, but 8.303 isn't out yet (that I can see, my ASG220 is at 8.301, up2date is on, no updates waiting to apply).  (Edit: My Web Security detail level is now 4, btw).

ID19968 8.300 postgres causes high load due to the default websecurity detail level 4
------------------------------------------------------------------------
Description:  On some ASGs the postgres database may cause a highload.
Workaround:   The default websecurity detail level (4) is not usable for
              some installations.
              Please reduce the websecurity detail level to (0)
              (Webadmin: Reporting settings).
Fixed in:     8.303

Best Regards,
Matt
IT Operations - Woodland Direct

Thanks! When I applied the PGSQL fix, I was excited to help anyone out there with the issue. We have near 50 employees working on the internet here, and that has a great deal to do with the high volume of reporting. Any time the system hits disk, you'll run into a bottleneck. Especially when it involves database activity.

I'd imagine that with the Swappiness, it may be just a matter of "there are bigger fish to fry" with the engineers, and they don't have the time to look into such a petty matter. Also, as with that, the more features you enable, like IPS, etc, the more physical memory is used. If you're already close to the physical memory being maxed out, then changing the swappiness may be a bad idea. But in my instance, I'm not even using 50% even with the swappiness change (see attached Mem Usage graph). 

As far as the PostgreSQL, there were no indications of any database corruption. We had engineers galore looking at it and the only thing they could say is to disable Web Security reporting. Turning the detail level down didn't help much. You can see my CPU usage history now (attached). The spikes on the left are while I was working on discovering the issue. You can see once I applied the effective cache size, that the spikes subsided. We have near 50 users, and all are on the internet, as we are a web-based company. I've re-enabled all needed options in reporting with little to no jump in CPU. Quite an awesome feeling! The "Known Issues" say it's fixed in 8.303, but 8.303 isn't out yet (that I can see, my ASG220 is at 8.301, up2date is on, no updates waiting to apply).  (Edit: My Web Security detail level is now 4, btw).

ID19968 8.300 postgres causes high load due to the default websecurity detail level 4
------------------------------------------------------------------------
Description:  On some ASGs the postgres database may cause a highload.
Workaround:   The default websecurity detail level (4) is not usable for
              some installations.
              Please reduce the websecurity detail level to (0)
              (Webadmin: Reporting settings).
Fixed in:     8.303

Best Regards,
Matt
IT Operations - Woodland Direct