From: | "Tomas Vondra" <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks |
Date: | 2014-08-11 16:37:29 |
Message-ID: | a85908074012311423c4f092aefb4bc4.squirrel@sq.gransy.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
So after 83 days, the regression tests on barnacle completed, and it
smells like another memory leak in CacheMemoryContext, similar to those
fixed in 078b2ed on May 18.
Barnacle is one of those machines with -DCLOBBER_CACHE_RECURSIVELY, and
the tests were running with a snapshot from May 19, so the memory leaks
detected with "only" -DCLOBBER_CACHE_ALWAYS should be fixed there.
I have a script in place looking for excessive memory usage of postgres
backends - whenever a backend allocates more than 512MB of VSS, it does
"MemoryContextStats(TopMemoryContext)" on it (from gdb).
The results get logged into the postmaster log, and thus get to the
buildfarm.
See this:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=barnacle&dt=2014-05-19%2011%3A25%3A03
Essentially, it looks like this:
TopMemoryContext: 69984 total in 10 blocks; 6216 free (24 chunks); 63768 used
TopTransactionContext: 8192 total in 1 blocks; 5768 free (23 chunks);
2424 used
...
Relcache by OID: 8192 total in 1 blocks; 592 free (0 chunks); 7600 used
CacheMemoryContext: 301981696 total in 45 blocks; 3701744 free (140
chunks); 298279952 used
...
or like this:
CacheMemoryContext: 1602215936 total in 200 blocks; 497336 free (138
chunks); 1601718600 used
So probably another low-probability memory leak, happening apparently only
in CLOBBER_CACHE_RECURSIVELY.
regards
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-08-11 16:43:09 | Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations |
Previous Message | Robert Haas | 2014-08-11 16:24:47 | Re: Proposal to add a QNX 6.5 port to PostgreSQL |