Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)
Date: 2014-05-17 21:25:06
Message-ID: 5377D3B2.1010200@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17.5.2014 23:09, Andres Freund wrote:
> Hi,
>
> On 2014-05-17 22:33:31 +0200, Tomas Vondra wrote:
>> Anyway, the main difference between the analyze snapshot seems to be this:
>>
>> init: CacheMemoryContext: 67100672 total in 17 blocks; ...
>> 350MB: CacheMemoryContext: 134209536 total in 25 blocks; ...
>> 400MB: CacheMemoryContext: 192929792 total in 32 blocks; ...
>> 500MB: CacheMemoryContext: 293593088 total in 44 blocks; ...
>> 600MB: CacheMemoryContext: 411033600 total in 58 blocks; ...
>
> Hm, so something is definitely leaking memory inside CacheMemoryContext
> itself. Is that happening constantly or just with individual tests?

I think it's happening constantly - I've been eyeballing the VM for some
time, and the backends usually hoover around ~220 MBs, executing SELECTs
etc. And then it executes CREATE INDEX and it starts growing.

Attached is a log for a CREATE INDEX session at the monent it had ~1.3GB
allocated (create-index-5.log.gz). It has ~217k copies of

pg_attrdef_adrelid_adnum_index: 3072 total in 2 blocks; 1968 free (0
chunks); 1104 used

And also another log (AFAIK from another CREATE INDEX session), with
~11k copies of

pg_namespace_oid_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used

>> Not sure if there's something wrong with the SELECT memory context. It
>> has ~1500 of nested nodes like these:
>>
>> SQL function data: 24576 total in 2 blocks; ...
>> ExecutorState: 24576 total in 2 blocks; ...
>> SQL function data: 24576 total in 2 blocks; ...
>> ExprContext: 8192 total in 1 blocks; ...
>>
>> But maybe it's expected / OK.
>
> I'd guess that's a recursive function call. Any chance you know what's
> been executing at that point? I'd bet it's been the 'errors' check. That
> has:
> -- Check that stack depth detection mechanism works and
> -- max_stack_depth is not set too high
> create function infinite_recurse() returns int as
> 'select infinite_recurse()' language sql;
> \set VERBOSITY terse
> select infinite_recurse();
> ERROR: stack depth limit exceeded
>
> which'd pretty much produce a tree of executions like yours.

Yeah, I was thinking it's something like that. I'm not sure what tests
were running at that that particular moment, so maybe it really was the
'errors' check.

Tomas

Attachment Content-Type Size
create-index.log.gz application/gzip 3.8 KB
create-index-5.log.gz application/gzip 67.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2014-05-17 21:26:59 uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
Previous Message Tom Lane 2014-05-17 21:23:58 Re: btree_gist macaddr valgrind woes