Thread: Understanding postgresql logs
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.
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