Re: [VuFind-Tech] Solr/java memory use

[Tod O. <to...@uc...>]

Just to follow up, in case it is useful to anyone:

Further investigation makes us think that the huge footprint in virtual memory was not the JVM exceeding is boundaries, but more likely the result of memory mapping of the index files.  Apparently memory mapping the indexes in Lucene  became the default in Lucene 3.3, and Solr admin > info reports Solr/Lucene version 3.4.0.

So that explains the why top thought the JVM was huge, because memory-mapped files are included in the virtual memory stats.

This instance of VuFind 2.0 was installed from the svn repository, not from the .deb, so that probably explains the more-recent-than-expected version of Solr.

-Tod

On Dec 13, 2011, at 7:35 AM, Demian Katz wrote:

> I haven’t seen the specific problem you describe with Solr overflowing its bounds, but I did write an article on troubleshooting Java memory issues which might be of interest:
>  
> http://blog.library.villanova.edu/libtech/2011/03/31/java-tuning-made-easier/
>  
> I suspect that you are correct that your large index is a factor in the problem.
>  
> It might also be worth bringing this to the attention of the solr-user mailing list (http://lucene.apache.org/solr/mailing_lists.html) if you need more help; there’s more Solr-specific expertise available there.  VuFind 1.2 uses Solr 1.4, which is probably worth mentioning if you do make a post.
>  
> - Demian
>  
> From: Tod Olson [mailto:to...@uc...] 
> Sent: Tuesday, December 13, 2011 6:48 AM
> To: vuf...@li...
> Subject: [VuFind-Tech] Solr/java memory use
>  
> Tech list,
>  
> I have a question about  about Solr memory use. This is about VuFind 1.2 with very minimal modifications: indexing a small local field, pulling out the uniform title as a separate field, and running on Ubuntu 10.4.
>  
> top reports that jetty is using has really bloated up in memory: 
>  
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                          
>   983 byrne     20   0 34.2g 3.4g 1.3g S  100 44.1 320:33.90 java                                                               
>  
> but it looks like it should the throttled to 2GB:
>  
> $ ps -p 983 -f www
> UID        PID  PPID  C STIME TTY      STAT   TIME CMD
> byrne      983     1 42 Dec12 ?        Sl   321:51 /usr/lib/jvm/default-java/bin/java -server -Xms1024m -Xmx2048m -XX:+UseParallelGC -XX:NewRatio=5 -Dsolr.solr.home=/usr/local/vufind/solr -Djetty.logs=/usr/local/vufind/solr/jetty/logs -Djetty.home=/usr/local/vufind/solr/jetty -jar /usr/local/vufind/solr/jetty/start.jar /usr/local/vufind/solr/jetty/etc/jetty.xml
>  
> Have others seen this memory behavior? The JVM is from OpenJDK. Anyone aware of it ignoring the upper bound set by -Xmx2048m?
>  
> This memory bloat seems to come on relatively quickly, the process was just started 12 hours ago. And this is just an in-house demo, so we don't expect lots of user pounding. Unfortunately, this also slows down Solr so much that VuFind thinks the index is offline.
>  
> And just to give an indication of our index sizes, which are rather large (at least I assume 28GB is large for the biblio index):
>  
> $ du -sm solr/*
> 5787  solr/alphabetical_browse
> 4127  solr/authority
> 28420            solr/biblio
>  
> Have others  seen this sort of behavior? Does it seem likely related to the size of our indexes? And any suggestions for how to proceed?
>  
> -Tod
>  
> 
> Tod Olson <to...@uc...>
> Systems Librarian     
> University of Chicago Library
> 
> 
> 
>