Tom Lane wrote:
>Joe Maldonado <jmaldonado@webehosting.biz> writes:
>
>
>>I have these messages on my 7.4.7 database log...
>>TopMemoryContext: 87494704 total in 10676 blocks; 179400 free (61
>>chunks); 87315304 used
>>TopTransactionContext: 57344 total in 3 blocks; 648 free (5 chunks);
>>56696 used
>>DeferredTriggerXact: 0 total in 0 blocks; 0 free (0 chunks); 0 used
>>...
>>
>>
>
>What's at the top and bottom of that?
>
>
Above this there is just a few expected error messages about a table
already existing, unfortunately this log happened between logrotates and
the log filled the logs partition to 100% so I do not have the post dump
messages.
The last entry in the log is ...
pg_temp_1486707604: 1024 total in 1 blocks; 640 free
>PG prints out a memory stats dump like this when it runs out of memory.
>The dump itself isn't much use to anyone but a developer; what you want
>to look into is what triggered it. The error message appearing just
>after (or maybe just before, I forget) should be relevant.
>
>
>
>>followed by about 16GB of the following type of entries...
>>pg_temp_1486707494: 2048 total in 1 blocks; 768 free (0 chunks); 1280 used
>>
>>
>
>Could you have been trying to vacuum a ridiculously large number of
>tables, or some such?
>
>
At first I suspected vacuum to be the culprit of the 16G of data though
this db is being vacuumed by pg_autovacuum with (-s 900 -d 3 -S 0 -A 0
-V 0) as options and it has recently undergone a vacuum full and reindex
operation.
> regards, tom lane
>
>
One other data point is that the shared buffers are very high
max_connections = 512
shared_buffers = 100000
though there are no other high memory consumers on that machine and it
has 4G of physical RAM
-Joe
