On 11/05/10 08:04, Tom Lane wrote: > valentin.hocher@xxxxxxxxxx (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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general