I'm using an open source (RHEL 6.2) based machine running SIEM software. When I run the top command, I see postgres and postmaster both with 96% CPU usage. Is there a way to pin-point or see what causing these service to stack up?

  • 2
    "RHCE 6.2"? Do you mean "RHEL 6.2" ? I assume postgress is postgres and you've just copied it by hand. – Craig Ringer Jun 8 '13 at 5:34
  • yeah thanks for correction. – asadz Jun 10 '13 at 15:24
up vote 20 down vote accepted

You can match a specific Postgres backend ID to a system process ID using the pg_stat_activity system table.

SELECT pid, datname, usename, query FROM pg_stat_activity; can be a good starting point.
Once you know what queries are running you can investigate further (EXPLAIN/EXPLAIN ANALYZE; check locks, etc.)

  • is this the exact query, I'm not much familiar with db as im the sec guy working on siem, your select statement, do i have to feed it pid from top command ? – asadz Jun 7 '13 at 21:02
  • 1
    @asadz no, it was truncated (fixed now) -- If you have specific PIDs and want to see what they're running you can isolate them with a WHERE clause, but if you don't have a huge number of PIDs it's just as easy to search through the full output. The Postgres manual has additional detail on what you can get out of pg_stat_activity, as well as the other statistics-collector tables (which can help you if your problem isn't a user query). – voretaq7 Jun 7 '13 at 21:11

I was having the same issue. The postgresql is setup on AWS RDS and it was having 100% cpu utilisation even after increasing the instance. I debugged with the method shown here and one of the method worked for me.

I checked for the query running for the longest time and came to know that certain queries was stuck and was running since more than 3-4 hours. To check since how much time the query is running, run the following command:

SELECT max(now() - xact_start) FROM pg_stat_activity
                               WHERE state IN ('idle in transaction', 'active');

If this is more than an hour, than this is the issue. Kill the long running connection and limit the max age of the connection from application side.

If this is really the postmaster using all that CPU, then you likely have lock contention issues, probably due to very high max_connections. Consider lowering max_connections and using a connection pooler if this is the case.

Otherwise: Details, please. Full output of top -b -n 1 for a start.

  • this make sense ; since the siem is used by analyst to query lot of data back and forth; is there a way i can check on the lock status; or conditions attributed to it; ? – asadz Jun 9 '13 at 7:01

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.