Thread: Understanding postgresql logs

Understanding postgresql logs

From
igivanoff
Date:
I have a PostgreSQL 9.0/9.2 which from time to time hits some memory issues.
I know the best approach is to monitor the DB performance and activity but
in the log files I see error messages similar to:


TopMemoryContext: 221952 total in 17 blocks; 7440 free (41 chunks); 214512
used
  TopTransactionContext: 8192 total in 1 blocks; 6384 free (0 chunks); 1808
used
    CurTransactionContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
  Type information cache: 24240 total in 2 blocks; 3744 free (0 chunks);
20496 used
  RI compare cache: 24576 total in 2 blocks; 15984 free (5 chunks); 8592
used
  RI query cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used
  TableSpace cache: 8192 total in 1 blocks; 3216 free (0 chunks); 4976 used
  Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks);
12688 used
  MessageContext: 65536 total in 4 blocks; 7200 free (8 chunks); 58336 used
  Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks); 6512
used
  smgr relation table: 57344 total in 3 blocks; 34320 free (10 chunks);
23024 used
  TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0 chunks);
32 used
  Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  PortalMemory: 8192 total in 1 blocks; 8160 free (1 chunks); 32 used
  Relcache by OID: 24576 total in 2 blocks; 11792 free (3 chunks); 12784
used
  CacheMemoryContext: 1359224 total in 23 blocks; 271648 free (1 chunks);
1087576 used
    . . .
    pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1224 free (2 chunks);
1848 used
    pg_foreign_server_name_index: 3072 total in 2 blocks; 1704 free (4
chunks); 1368 used
    pg_attribute_relid_attnam_index: 3072 total in 2 blocks; 1568 free (2
chunks); 1504 used
    pg_conversion_oid_index: 3072 total in 2 blocks; 1704 free (4 chunks);
1368 used
    pg_user_mapping_user_server_index: 3072 total in 2 blocks; 1568 free (2
chunks); 1504 used
    pg_conversion_name_nsp_index: 3072 total in 2 blocks; 1568 free (2
chunks); 1504 used
    pg_authid_oid_index: 3072 total in 2 blocks; 1656 free (3 chunks); 1416
used
    pg_auth_members_member_role_index: 3072 total in 2 blocks; 1568 free (2
chunks); 1504 used
    pg_tablespace_oid_index: 3072 total in 2 blocks; 1656 free (3 chunks);
1416 used
    pg_database_datname_index: 3072 total in 2 blocks; 1656 free (3 chunks);
1416 used
    pg_auth_members_role_member_index: 3072 total in 2 blocks; 1568 free (2
chunks); 1504 used
    pg_database_oid_index: 3072 total in 2 blocks; 1656 free (3 chunks);
1416 used
    pg_authid_rolname_index: 3072 total in 2 blocks; 1656 free (3 chunks);
1416 used
  MdSmgr: 8192 total in 1 blocks; 5440 free (0 chunks); 2752 used
  tokenize file cxt: 0 total in 0 blocks; 0 free (0 chunks); 0 used
  hba parser context: 3072 total in 2 blocks; 512 free (2 chunks); 2560 used
  LOCALLOCK hash: 24576 total in 2 blocks; 13920 free (4 chunks); 10656 used
  Timezones: 83472 total in 2 blocks; 3744 free (0 chunks); 79728 used
  ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
      1 tm:2013-05-18 11:21:58.274 UTC db:VCDB pid:29515 ERROR:  out of
memory
      2 tm:2013-05-18 11:21:58.274 UTC db:VCDB pid:29515 DETAIL:  Failed on
request of size 40.

I've searched around for some documentation/books/posts on that topic but I
failed to find detailed info what's TopMemoryContext, TopTransactionContext,
CurTransactionContext etc. and how those values can be translated.

Can someone point to a book or documentation which might be helpful?

Thanks!



--
View this message in context: http://postgresql.1045698.n5.nabble.com/Understanding-postgresql-logs-tp5757000.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


Re: Understanding postgresql logs

From
Jeff Janes
Date:
On Mon, May 27, 2013 at 6:37 AM, igivanoff <igivanoff@yahoo.com> wrote:
I have a PostgreSQL 9.0/9.2 which from time to time hits some memory issues.
I know the best approach is to monitor the DB performance and activity but
in the log files I see error messages similar to:


TopMemoryContext: 221952 total in 17 blocks; 7440 free (41 chunks); 214512
used
  TopTransactionContext: 8192 total in 1 blocks; 6384 free (0 chunks); 1808
used
    CurTransactionContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
  Type information cache: 24240 total in 2 blocks; 3744 free (0 chunks);
20496 used


You can look for the biggest contexts by copying all of these lines to a file and then sorting it by something like "sort -t: -k2".

The biggest one I see is "CacheMemoryContext: 1359224 total", which is pretty small, so the culprit is probably hidden behind the ellipsis in your message.

      1 tm:2013-05-18 11:21:58.274 UTC db:VCDB pid:29515 ERROR:  out of
memory
      2 tm:2013-05-18 11:21:58.274 UTC db:VCDB pid:29515 DETAIL:  Failed on
request of size 40.

I've searched around for some documentation/books/posts on that topic but I
failed to find detailed info what's TopMemoryContext, TopTransactionContext,
CurTransactionContext etc. and how those values can be translated.

I doubt that most of these are documented anywhere except in the source code.  You don't need to understand all of them, you can isolate just the one which is very large, and grep the source code for it.

Most likely you just set maintenance_work_mem too large.

Cheers,

Jeff