MemoryCritical (PostgreSQL)¶

Follow the steps in the general runbook first. This page adds the steps for PostgreSQL.

Why the numbers can differ¶

The alert and the Memory column in the Pods table measure memory in different ways:

• The alert counts only the memory that the database processes use (RSS). It does not count the file cache.
• The Memory column shows the working set. The working set also includes part of the file cache.

PostgreSQL reads a lot of data through the file cache, so the Memory column is often higher than the value the alert uses. A high value in the Memory column alone is not a problem: the operating system frees file cache when the database needs the memory. The alert fires only when the database processes themselves use more than 85% of the limit.

Reduce the memory usage¶

• Connections: each open connection uses memory. Check how many connections are open, and where they come from:

  SELECT usename, application_name, state, count(*)
  FROM pg_stat_activity
  GROUP BY usename, application_name, state
  ORDER BY count(*) DESC;
  

  Close idle connections in your application, and use a connection pool with a fixed size. See PostgreSQLConnectionsCritical for more steps.

• Large queries: big sorts, joins or aggregations use a lot of memory. Many of these queries at the same time use even more. Look for long running queries and improve them, for example with an index:

  SELECT pid, now() - query_start AS duration, state, query
  FROM pg_stat_activity
  WHERE state <> 'idle'
  ORDER BY duration DESC;
  

If the memory usage is expected for your workload, move the instance to a larger compute plan. See Scaling.