lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 67 - Failure!
Date Thu, 02 Aug 2012 14:33:48 GMT
On Wed, Aug 1, 2012 at 9:17 AM, Robert Muir <> wrote:
> On Wed, Aug 1, 2012 at 4:35 AM, Uwe Schindler <> wrote:
>> Hi Robert,
>> I checked Jenkin's settings and the "ulimit -n" is 8192 by default for jenkins. To
prevent this problem I raised this to 32768.
>> The thing with IBM J9 is that is has several caches for class files (so compiled
class files can be cached in shared memory for parallel JVMs using the same classes), but
I assume this needs more file handles.
> Right I bumped this on charlie cron too and forgot about it, until i
> installed this IBM jre on this machine.
> IBM J9 using a few extra files compared to sun doesnt seem to explain
> to me why SimpleFS/NIOFS use more filehandles than mmap though? And
> that this problem never happens with other JREs....
> I feel like something might be wrong here.

Rob and I dug a bit on this ... the hard open-file limit was 4096 and
the soft limit was 1024, and curiously, it looks like Oracle JVMs
"allow" themselves to go up to the hard limit (likely change the soft
limit on startup), while the IBM JVM uses the soft limit.  Has anyone
heard of JVMs doing this (increasing the soft limit to the hard limit
for open files) before...?  I see this curious "-XX:+MaxFDLimit"
option here:

But it says it's Solaris only ...

If I use ulimit to set the hard and soft limit to 1024 then both
Oracle and IBM JVMs fail TestShardSearching with NIOFSDir due to too
many open files.

But, for some reason if you run the test with MMapDir, far fewer file
descriptors are consumed ...

Mike McCandless

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message