Re: initdb fails on Centos 5.4 x64 - Mailing list pgsql-general

From Craig Ringer
Subject Re: initdb fails on Centos 5.4 x64
Date
Msg-id 4BE9017F.7040408@postnewspapers.com.au
Whole thread Raw
In response to Re: initdb fails on Centos 5.4 x64  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 11/05/10 08:04, Tom Lane wrote:
> valentin.hocher@kabelbw.de (Valentin Hocher) writes:
>> [ cPanel's "Shell Fork Bomb Protection" actually does this: ]
>>         ulimit -n 100 -u 20 -m 200000 -d 200000 -s 8192 -c 200000 -v 200000 2>/dev/null
>
> Just to annotate that: some experimentation I did confirms that on
> RHEL5 x86_64, PG 8.4.3 falls over with the mentioned error when run
> under ulimit -v in the vicinity of 200000 (ie 200MB).  It's kind of
> surprising that initdb eats that much virtual memory space, although
> certainly loading all the encoding translation libraries simultaneously
> is a bit of a stress test.  But the actual memory footprint is surely a
> lot less than that.  Apparently there is a good deal of inefficiency in
> address-space consumption when loading a bunch of .so's on this
> platform.  I'd be interested to know if people can reproduce similar
> problems on other Linux variants.

I wouldn't be surprised if prelinking turned out to be the culprit
there. If it's loading shared libraries to pre-selected address ranges
that're globally unique across the system, it might much some
significant address space.

... though come to think of it, each should be an individual mapping
(right?) so it shouldn't really matter where in virtual memory they're
located, just their size. Scratch that idea?

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/

pgsql-general by date:

Previous
From: "A. Kretschmer"
Date:
Subject: Re: Performance issues when the number of records are around 10 Million
Next
From: Craig Ringer
Date:
Subject: Re: peer-to-peer replication with Postgres