Re: Too many open files - lots of sockets
Are you running trunk and have auto-commit enabled? Then disable auto-commit. Even if you increase ulimits it will continue to swallow all available file descriptors. On Wed, 14 Mar 2012 10:13:55 +, Colin Howe co...@conversocial.com wrote: Hello, We keep hitting the too many open files exception. Looking at lsof we have a lot (several thousand) of entries like this: java 19339 root 1619u sock0,7 0t0 682291383 can't identify protocol However, netstat -a doesn't show any of these. Can anyone suggest a way to diagnose what these socket entries are? Happy to post any more information as needed. Cheers, Colin -- Markus Jelsma - CTO - Openindex http://www.linkedin.com/in/markus17 050-8536600 / 06-50258350
Re: Too many open files - lots of sockets
Currently using 3.4.0. We have autocommit enabled but we manually do commits every 100 documents anyway... I can turn it off if you think that might help. Cheers, Colin On Wed, Mar 14, 2012 at 10:24 AM, Markus Jelsma markus.jel...@openindex.iowrote: Are you running trunk and have auto-commit enabled? Then disable auto-commit. Even if you increase ulimits it will continue to swallow all available file descriptors. On Wed, 14 Mar 2012 10:13:55 +, Colin Howe co...@conversocial.com wrote: Hello, We keep hitting the too many open files exception. Looking at lsof we have a lot (several thousand) of entries like this: java 19339 root 1619u sock0,70t0 682291383 can't identify protocol However, netstat -a doesn't show any of these. Can anyone suggest a way to diagnose what these socket entries are? Happy to post any more information as needed. Cheers, Colin -- Markus Jelsma - CTO - Openindex http://www.linkedin.com/in/**markus17http://www.linkedin.com/in/markus17 050-8536600 / 06-50258350 -- Colin Howe @colinhowe VP of Engineering Conversocial Ltd conversocial.com
Re: Too many open files - lots of sockets
I had the same problem, without auto-commit. I never really found out what exactly the reason was, but I think it was because commits were triggered before a previous commit had the chance to finish. We now commit after every minute or 1000 (quite large) documents, whatever comes first. And we never optimize. We haven't had this exceptions for months now. Good luck! -Kuli Am 14.03.2012 11:22, schrieb Colin Howe: Currently using 3.4.0. We have autocommit enabled but we manually do commits every 100 documents anyway... I can turn it off if you think that might help. Cheers, Colin On Wed, Mar 14, 2012 at 10:24 AM, Markus Jelsma markus.jel...@openindex.iowrote: Are you running trunk and have auto-commit enabled? Then disable auto-commit. Even if you increase ulimits it will continue to swallow all available file descriptors. On Wed, 14 Mar 2012 10:13:55 +, Colin Howeco...@conversocial.com wrote: Hello, We keep hitting the too many open files exception. Looking at lsof we have a lot (several thousand) of entries like this: java 19339 root 1619u sock0,70t0 682291383 can't identify protocol However, netstat -a doesn't show any of these. Can anyone suggest a way to diagnose what these socket entries are? Happy to post any more information as needed. Cheers, Colin -- Markus Jelsma - CTO - Openindex http://www.linkedin.com/in/**markus17http://www.linkedin.com/in/markus17 050-8536600 / 06-50258350
Re: Too many open files - lots of sockets
After some more digging around I discovered that there was a bug reported in jetty 6: https://jira.codehaus.org/browse/JETTY-1458 This prompted me to upgrade to Jetty 7 and things look a bit more stable now :) On Wed, Mar 14, 2012 at 10:26 AM, Michael Kuhlmann k...@solarier.de wrote: I had the same problem, without auto-commit. I never really found out what exactly the reason was, but I think it was because commits were triggered before a previous commit had the chance to finish. We now commit after every minute or 1000 (quite large) documents, whatever comes first. And we never optimize. We haven't had this exceptions for months now. Good luck! -Kuli Am 14.03.2012 11:22, schrieb Colin Howe: Currently using 3.4.0. We have autocommit enabled but we manually do commits every 100 documents anyway... I can turn it off if you think that might help. Cheers, Colin On Wed, Mar 14, 2012 at 10:24 AM, Markus Jelsma markus.jel...@openindex.io**wrote: Are you running trunk and have auto-commit enabled? Then disable auto-commit. Even if you increase ulimits it will continue to swallow all available file descriptors. On Wed, 14 Mar 2012 10:13:55 +, Colin Howeco...@conversocial.com wrote: Hello, We keep hitting the too many open files exception. Looking at lsof we have a lot (several thousand) of entries like this: java 19339 root 1619u sock0,7 0t0 682291383 can't identify protocol However, netstat -a doesn't show any of these. Can anyone suggest a way to diagnose what these socket entries are? Happy to post any more information as needed. Cheers, Colin -- Markus Jelsma - CTO - Openindex http://www.linkedin.com/in/markus17http://www.linkedin.com/in/**markus17 http://www.linkedin.**com/in/markus17http://www.linkedin.com/in/markus17 050-8536600 / 06-50258350 -- Colin Howe @colinhowe VP of Engineering Conversocial Ltd conversocial.com
Re: Too many open files - lots of sockets
Ah, good to know! Thank you! I already had Jetty under suspicion, but we had this failure quite often in October and November, when the bug was not yet reported. -Kuli Am 14.03.2012 12:08, schrieb Colin Howe: After some more digging around I discovered that there was a bug reported in jetty 6: https://jira.codehaus.org/browse/JETTY-1458 This prompted me to upgrade to Jetty 7 and things look a bit more stable now :)
Re: Too many open files - lots of sockets
Colin: FYI, you might consider just setting up the autocommit (or commitWithin if you're using SolrJ) for some reasonable interval (I often use 10 minutes or so). Even though you've figured it is a Tomcat issue, each commit causes searcher re-opens, perhaps replication in a master/slave setup, increased merges etc. It works, but it's also resource intensive... FWIW Erick On Wed, Mar 14, 2012 at 6:40 AM, Michael Kuhlmann k...@solarier.de wrote: Ah, good to know! Thank you! I already had Jetty under suspicion, but we had this failure quite often in October and November, when the bug was not yet reported. -Kuli Am 14.03.2012 12:08, schrieb Colin Howe: After some more digging around I discovered that there was a bug reported in jetty 6: https://jira.codehaus.org/browse/JETTY-1458 This prompted me to upgrade to Jetty 7 and things look a bit more stable now :)
Re: Too many open files exception related to solrj getServer too often?
Off the top of my head, i don't know hte answers to some of your questions, but as to the core cause of the exception... : 3. server.query(solrQuery) throws SolrServerException. How can concurrent : solr queries triggers Too many open file exception? ...bear in mind that (as i understand it) the limit on open files is actually a limit on open file *descriptors* which includes network sockets. a google search for java.net.SocketException: Too many open files will give you loads of results -- it's not specific to solr. -Hoss
Re: Too many open files exception related to solrj getServer too often?
Just pushing up the topic and look for answers. -- View this message in context: http://lucene.472066.n3.nabble.com/Too-many-open-files-exception-related-to-solrj-getServer-too-often-tp2808718p2867976.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Too Many Open Files
This probably means you're opening new readers without closing old ones. But that's just a guess. I'm guessing that this really has nothing to do with the delete itself, but the delete is what's finally pushing you over the limit. I know this has been discussed before, try searching the mail archive for TooManyOpenFiles and/or File Handles You could get much better information by providing more details, see: http://wiki.apache.org/solr/UsingMailingLists?highlight=(most)|(users)|(list) Best Erick On Mon, Jun 28, 2010 at 11:56 AM, Anderson vasconcelos anderson.v...@gmail.com wrote: Hi all When i send a delete query to SOLR, using the SOLRJ i received this exception: org.apache.solr.client.solrj.SolrServerException: java.net.SocketException: Too many open files 11:53:06,964 INFO [HttpMethodDirector] I/O exception (java.net.SocketException) caught when processing request: Too many open files Anyone could Help me? How i can solve this? Thanks
Re: Too Many Open Files
Hi Anderson, If you are using SolrJ, it's recommended to reuse the same instance per solr server. http://wiki.apache.org/solr/Solrj#CommonsHttpSolrServer But there are other scenarios which may cause this situation: 1. Other application running in the same Solr JVM which doesn't close properly sockets or control file handlers. 2. Open files limits configuration is low . Check your limits, read it from JVM process info: cat /proc/1234/limits (where 1234 is your process ID) Cheers, Michel Bottan On Mon, Jun 28, 2010 at 1:18 PM, Erick Erickson erickerick...@gmail.comwrote: This probably means you're opening new readers without closing old ones. But that's just a guess. I'm guessing that this really has nothing to do with the delete itself, but the delete is what's finally pushing you over the limit. I know this has been discussed before, try searching the mail archive for TooManyOpenFiles and/or File Handles You could get much better information by providing more details, see: http://wiki.apache.org/solr/UsingMailingLists?highlight=(most)|(users)|(list)http://wiki.apache.org/solr/UsingMailingLists?highlight=%28most%29%7C%28users%29%7C%28list%29 Best Erick On Mon, Jun 28, 2010 at 11:56 AM, Anderson vasconcelos anderson.v...@gmail.com wrote: Hi all When i send a delete query to SOLR, using the SOLRJ i received this exception: org.apache.solr.client.solrj.SolrServerException: java.net.SocketException: Too many open files 11:53:06,964 INFO [HttpMethodDirector] I/O exception (java.net.SocketException) caught when processing request: Too many open files Anyone could Help me? How i can solve this? Thanks
Re: Too Many Open Files
Thanks for responses. I instantiate one instance of per request (per delete query, in my case). I have a lot of concurrency process. Reusing the same instance (to send, delete and remove data) in solr, i will have a trouble? My concern is if i do this, solr will commit documents with data from other transaction. Thanks 2010/6/28 Michel Bottan freakco...@gmail.com Hi Anderson, If you are using SolrJ, it's recommended to reuse the same instance per solr server. http://wiki.apache.org/solr/Solrj#CommonsHttpSolrServer But there are other scenarios which may cause this situation: 1. Other application running in the same Solr JVM which doesn't close properly sockets or control file handlers. 2. Open files limits configuration is low . Check your limits, read it from JVM process info: cat /proc/1234/limits (where 1234 is your process ID) Cheers, Michel Bottan On Mon, Jun 28, 2010 at 1:18 PM, Erick Erickson erickerick...@gmail.com wrote: This probably means you're opening new readers without closing old ones. But that's just a guess. I'm guessing that this really has nothing to do with the delete itself, but the delete is what's finally pushing you over the limit. I know this has been discussed before, try searching the mail archive for TooManyOpenFiles and/or File Handles You could get much better information by providing more details, see: http://wiki.apache.org/solr/UsingMailingLists?highlight=(most)|(users)|(list)http://wiki.apache.org/solr/UsingMailingLists?highlight=%28most%29%7C%28users%29%7C%28list%29 http://wiki.apache.org/solr/UsingMailingLists?highlight=%28most%29%7C%28users%29%7C%28list%29 Best Erick On Mon, Jun 28, 2010 at 11:56 AM, Anderson vasconcelos anderson.v...@gmail.com wrote: Hi all When i send a delete query to SOLR, using the SOLRJ i received this exception: org.apache.solr.client.solrj.SolrServerException: java.net.SocketException: Too many open files 11:53:06,964 INFO [HttpMethodDirector] I/O exception (java.net.SocketException) caught when processing request: Too many open files Anyone could Help me? How i can solve this? Thanks
Re: Too Many Open Files
Other question, Why SOLRJ d'ont close the StringWriter e OutputStreamWriter ? thanks 2010/6/28 Anderson vasconcelos anderson.v...@gmail.com Thanks for responses. I instantiate one instance of per request (per delete query, in my case). I have a lot of concurrency process. Reusing the same instance (to send, delete and remove data) in solr, i will have a trouble? My concern is if i do this, solr will commit documents with data from other transaction. Thanks 2010/6/28 Michel Bottan freakco...@gmail.com Hi Anderson, If you are using SolrJ, it's recommended to reuse the same instance per solr server. http://wiki.apache.org/solr/Solrj#CommonsHttpSolrServer But there are other scenarios which may cause this situation: 1. Other application running in the same Solr JVM which doesn't close properly sockets or control file handlers. 2. Open files limits configuration is low . Check your limits, read it from JVM process info: cat /proc/1234/limits (where 1234 is your process ID) Cheers, Michel Bottan On Mon, Jun 28, 2010 at 1:18 PM, Erick Erickson erickerick...@gmail.com wrote: This probably means you're opening new readers without closing old ones. But that's just a guess. I'm guessing that this really has nothing to do with the delete itself, but the delete is what's finally pushing you over the limit. I know this has been discussed before, try searching the mail archive for TooManyOpenFiles and/or File Handles You could get much better information by providing more details, see: http://wiki.apache.org/solr/UsingMailingLists?highlight=(most)|(users)|(list)http://wiki.apache.org/solr/UsingMailingLists?highlight=%28most%29%7C%28users%29%7C%28list%29 http://wiki.apache.org/solr/UsingMailingLists?highlight=%28most%29%7C%28users%29%7C%28list%29 Best Erick On Mon, Jun 28, 2010 at 11:56 AM, Anderson vasconcelos anderson.v...@gmail.com wrote: Hi all When i send a delete query to SOLR, using the SOLRJ i received this exception: org.apache.solr.client.solrj.SolrServerException: java.net.SocketException: Too many open files 11:53:06,964 INFO [HttpMethodDirector] I/O exception (java.net.SocketException) caught when processing request: Too many open files Anyone could Help me? How i can solve this? Thanks
RE: Too many open files
I had extremely specific use case; about 5000 documents-per-second (small documents) update rate, some documents can be repeatedly sent to SOLR with different timestamp field (and same unique document ID). Nothing breaks, just a great performance gain which was impossible with 32GB Buffer (- it caused constant index merge, 5 times more CPU than index update). Nothing breaks... with indexMerge=10 I don't have ANY merge during 24 hours; segments are large (few of 4Gb-8Gb, and one large union); I have merge explicitly only, at night, when I issue commit. Of course, it depends on use case, for applications such as Content Management System we don't need high remBufferSizeMB (few updates a day sent to SOLR)... -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: October-23-09 5:28 PM To: solr-user@lucene.apache.org Subject: Re: Too many open files 8 GB is much larger than is well supported. Its diminishing returns over 40-100 and mostly a waste of RAM. Too high and things can break. It should be well below 2 GB at most, but I'd still recommend 40-100. Fuad Efendi wrote: Reason of having big RAM buffer is lowering frequency of IndexWriter flushes and (subsequently) lowering frequency of index merge events, and (subsequently) merging of a few larger files takes less time... especially if RAM Buffer is intelligent enough (and big enough) to deal with 100 concurrent updates of existing document without 100-times flushing to disk of 100 document versions. I posted here thread related; I had 1:5 timing for Update:Merge (5 minutes merge, and 1 minute update) with default SOLR settings (32Mb buffer). I increased buffer to 8Gb on Master, and it triggered significant indexing performance boost... -Fuad http://www.linkedin.com/in/liferay -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: October-23-09 3:03 PM To: solr-user@lucene.apache.org Subject: Re: Too many open files I wouldn't use a RAM buffer of a gig - 32-100 is generally a good number. Fuad Efendi wrote: I was partially wrong; this is what Mike McCandless (Lucene-in-Action, 2nd edition) explained at Manning forum: mergeFactor of 1000 means you will have up to 1000 segments at each level. A level 0 segment means it was flushed directly by IndexWriter. After you have 1000 such segments, they are merged into a single level 1 segment. Once you have 1000 level 1 segments, they are merged into a single level 2 segment, etc. So, depending on how many docs you add to your index, you'll could have 1000s of segments w/ mergeFactor=1000. http://www.manning-sandbox.com/thread.jspa?threadID=33784tstart=0 So, in case of mergeFactor=100 you may have (theoretically) 1000 segments, 10-20 files each (depending on schema)... mergeFactor=10 is default setting... ramBufferSizeMB=1024 means that you need at least double Java heap, but you have -Xmx1024m... -Fuad I am getting too many open files error. Usually I test on a server that has 4GB RAM and assigned 1GB for tomcat(set JAVA_OPTS=-Xms256m -Xmx1024m), ulimit -n is 256 for this server and has following setting for SolrConfig.xml useCompoundFiletrue/useCompoundFile ramBufferSizeMB1024/ramBufferSizeMB mergeFactor100/mergeFactor maxMergeDocs2147483647/maxMergeDocs maxFieldLength1/maxFieldLength -- - Mark http://www.lucidimagination.com -- - Mark http://www.lucidimagination.com
RE: Too many open files
Thanks for pointing to it, but it is so obvious: 1. Buffer is used as a RAM storage for index updates 2. int has 2 x Gb different values (2^^32) 3. We can have _up_to_ 2Gb of _Documents_ (stored as key-value pairs, inverted index) In case of 5 fields which I have, I need 5 arrays (up to 2Gb of size for each) to store inverted pointers, so that there is no any theoretical limit: Also, from the javadoc in IndexWriter: * p bNOTE/b: because IndexWriter uses * codeint/codes when managing its internal storage, * the absolute maximum value for this setting is somewhat * less than 2048 MB. The precise limit depends on * various factors, such as how large your documents are, * how many fields have norms, etc., so it's best to set * this value comfortably under 2048./p Note also, I use norms etc...
RE: Too many open files
Mark, I don't understand this; of course it is use case specific, I haven't seen any terrible behaviour with 8Gb... 32Mb is extremely small for Nutch-SOLR -like applications, but it is acceptable for Liferay-SOLR... Please note also, I have some documents with same IDs updated many thousands times a day, and I believe (I hope) IndexWriter flushes optimized segment instead of thousands delete and single insert in many small (32Mb) files (especially with SOLR)... Hmm - came out worse than it looked. Here is a better attempt: MergeFactor: 10 BUF DOCS/S 32 37.40 80 39.91 120 40.74 512 38.25 Mark Miller wrote: Here is an example using the Lucene benchmark package. Indexing 64,000 wikipedia docs (sorry for the formatting): [java] Report sum by Prefix (MAddDocs) and Round (4 about 32 out of 256058) [java] Operation round mrg flush runCnt recsPerRunrec/s elapsedSecavgUsedMemavgTotalMem [java] MAddDocs_8000 0 10 32.00MB8 800037.401,711.22 124,612,472182,689,792 [java] MAddDocs_8000 - 1 10 80.00MB - - 8 - - - 8000 - - 39.91 - 1,603.76 - 266,716,128 - 469,925,888 [java] MAddDocs_8000 2 10 120.00MB8 800040.741,571.02 348,059,488548,233,216 [java] MAddDocs_8000 - 3 10 512.00MB - - 8 - - - 8000 - - 38.25 - 1,673.05 - 746,087,808 - 926,089,216 After about 32-40, you don't gain much, and it starts decreasing once you start getting to high. 8GB is a terrible recommendation.
RE: Too many open files
This JavaDoc is incorrect especially for SOLR, when you store raw (non tokenized, non indexed) text value with a document (which almost everyone does). Try to store 1,000,000 documents with 1000 bytes non-tokenized field: you will need 1Gb just for this array. -Original Message- From: Fuad Efendi [mailto:f...@efendi.ca] Sent: October-24-09 12:10 PM To: solr-user@lucene.apache.org Subject: RE: Too many open files Thanks for pointing to it, but it is so obvious: 1. Buffer is used as a RAM storage for index updates 2. int has 2 x Gb different values (2^^32) 3. We can have _up_to_ 2Gb of _Documents_ (stored as key-value pairs, inverted index) In case of 5 fields which I have, I need 5 arrays (up to 2Gb of size for each) to store inverted pointers, so that there is no any theoretical limit: Also, from the javadoc in IndexWriter: * p bNOTE/b: because IndexWriter uses * codeint/codes when managing its internal storage, * the absolute maximum value for this setting is somewhat * less than 2048 MB. The precise limit depends on * various factors, such as how large your documents are, * how many fields have norms, etc., so it's best to set * this value comfortably under 2048./p Note also, I use norms etc...
Re: Too many open files
On Sat, Oct 24, 2009 at 12:18 PM, Fuad Efendi f...@efendi.ca wrote: Mark, I don't understand this; of course it is use case specific, I haven't seen any terrible behaviour with 8Gb If you had gone over 2GB of actual buffer *usage*, it would have broke... Guaranteed. We've now added a check in Lucene 2.9.1 that will throw an exception if you try to go over 2048MB. And as the javadoc says, to be on the safe side, you probably shouldn't go too near 2048 - perhaps 2000MB is a good practical limit. -Yonik http://www.lucidimagination.com
RE: Too many open files
Hi Yonik, I am still using pre-2.9 Lucene (taken from SOLR trunk two months ago). 2048 is limit for documents, not for array of pointers to documents. And especially for new uninverted SOLR features, plus non-tokenized stored fields, we need 1Gb to store 1Mb of a simple field only (size of field: 1000 bytes). May be it would broke... frankly, I started with 8Gb, then by some reason I set if to 2Gb (a month ago), I don't remember why... I had hardware problems and I didn't want frequent loose of ram buffer... But again: why it would broke? Because int has 2048M different values?!! This is extremely strange. My understanding is that buffer stores processed data such as term - document_id values, _per_field_array(s!!!); so that 2048M is _absolute_maximum_ in case if your SOLR schema consists from _single_tokenized_field_only_. What about 10 fields? What about plain text stored with document, term vectors, uninverted values??? What are reasons on putting such check in Lucene? Array overflow? -Fuad http://www.linkedin.com/in/liferay -Original Message- From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik Seeley Sent: October-24-09 12:27 PM To: solr-user@lucene.apache.org Subject: Re: Too many open files On Sat, Oct 24, 2009 at 12:18 PM, Fuad Efendi f...@efendi.ca wrote: Mark, I don't understand this; of course it is use case specific, I haven't seen any terrible behaviour with 8Gb If you had gone over 2GB of actual buffer *usage*, it would have broke... Guaranteed. We've now added a check in Lucene 2.9.1 that will throw an exception if you try to go over 2048MB. And as the javadoc says, to be on the safe side, you probably shouldn't go too near 2048 - perhaps 2000MB is a good practical limit. -Yonik http://www.lucidimagination.com
RE: Too many open files
when you store raw (non tokenized, non indexed) text value with a document (which almost everyone does). Try to store 1,000,000 documents with 1000 bytes non-tokenized field: you will need 1Gb just for this array. Nope. You shouldn't even need 1GB of buffer space for that. The size specified is for all things that the indexing process needs to temporarily keep in memory... stored fields are normally immediately written to disk. -Yonik http://www.lucidimagination.com -Ok, thanks for clarification! What about term vectors, what about non-trivial schema having 10 tokenized fields? Buffer will need 10 arrays (up to 2048M each) for that. My understanding is probably very naive... -Fuad http://www.linkedin.com/in/liferay
RE: Too many open files
If you had gone over 2GB of actual buffer *usage*, it would have broke... Guaranteed. We've now added a check in Lucene 2.9.1 that will throw an exception if you try to go over 2048MB. And as the javadoc says, to be on the safe side, you probably shouldn't go too near 2048 - perhaps 2000MB is a good practical limit. I browsed http://issues.apache.org/jira/browse/LUCENE-1995 and http://search.lucidimagination.com/search/document/f29fc52348ab9b63/arrayind exoutofboundsexception_during_indexing - it is not proof of concept. It is workaround. Problem still exists, and scenario is unclear. -Fuad http://www.linkedin.com/in/liferay
RE: Too many open files
Make it 10: mergeFactor10/mergeFactor -Fuad -Original Message- From: Ranganathan, Sharmila [mailto:sranganat...@library.rochester.edu] Sent: October-23-09 1:08 PM To: solr-user@lucene.apache.org Subject: Too many open files Hi, I am getting too many open files error. Usually I test on a server that has 4GB RAM and assigned 1GB for tomcat(set JAVA_OPTS=-Xms256m -Xmx1024m), ulimit -n is 256 for this server and has following setting for SolrConfig.xml useCompoundFiletrue/useCompoundFile ramBufferSizeMB1024/ramBufferSizeMB mergeFactor100/mergeFactor maxMergeDocs2147483647/maxMergeDocs maxFieldLength1/maxFieldLength In my case 200,000 documents is of 1024MB size and in this testing, I am indexing total of million documents. We have high setting because we are expected to index about 10+ million records in production. It works fine in this server. When I deploy same solr configuration on a server with 32GB RAM, I get too many open files error. The ulimit -n is 1024 for this server. Any idea? Is this because 2nd server has 32GB RAM? Is 1024 open files limit too low? Also I don't find any documentation for ramBufferSizeMB. I checked Solr 'Solr 1.4 Enterprise Search Server' book, wiki, etc. I am using Solr 1.3. Is it good idea to use ramBufferSizeMB? Vs maxBufferedDocs? What does ramBufferSizeMB mean? My understanding is that when documents added to index which are initially stored in memory reaches size 1024MB(ramBufferSizeMB), it flushes data to disk. Or is it when total memory used(by tomcat, etc) reaches 1024, it flushed data to disk? Thanks, Sharmila
Re: Too many open files
I wouldn't use a RAM buffer of a gig - 32-100 is generally a good number. Fuad Efendi wrote: I was partially wrong; this is what Mike McCandless (Lucene-in-Action, 2nd edition) explained at Manning forum: mergeFactor of 1000 means you will have up to 1000 segments at each level. A level 0 segment means it was flushed directly by IndexWriter. After you have 1000 such segments, they are merged into a single level 1 segment. Once you have 1000 level 1 segments, they are merged into a single level 2 segment, etc. So, depending on how many docs you add to your index, you'll could have 1000s of segments w/ mergeFactor=1000. http://www.manning-sandbox.com/thread.jspa?threadID=33784tstart=0 So, in case of mergeFactor=100 you may have (theoretically) 1000 segments, 10-20 files each (depending on schema)... mergeFactor=10 is default setting... ramBufferSizeMB=1024 means that you need at least double Java heap, but you have -Xmx1024m... -Fuad I am getting too many open files error. Usually I test on a server that has 4GB RAM and assigned 1GB for tomcat(set JAVA_OPTS=-Xms256m -Xmx1024m), ulimit -n is 256 for this server and has following setting for SolrConfig.xml useCompoundFiletrue/useCompoundFile ramBufferSizeMB1024/ramBufferSizeMB mergeFactor100/mergeFactor maxMergeDocs2147483647/maxMergeDocs maxFieldLength1/maxFieldLength -- - Mark http://www.lucidimagination.com
Re: Too many open files and background merge exceptions
try ulimit -n5 or something On Mon, Apr 6, 2009 at 6:28 PM, Jarek Zgoda jarek.zg...@redefine.pl wrote: I'm indexing a set of 50 small documents. I'm adding documents in batches of 1000. At the beginning I had a setup that optimized the index each 1 documents, but quickly I had to optimize after adding each batch of documents. Unfortunately, I'm still getting the Too many open files IO error on optimize. I went from mergeFactor of 25 down to 10, but I'm still unable to optimize the index. I have configuration: useCompoundFilefalse/useCompoundFile ramBufferSizeMB256/ramBufferSizeMB mergeFactor2/mergeFactor maxMergeDocs2147483647/maxMergeDocs maxFieldLength1/maxFieldLength The machine (2 core AMD64, 4GB RAM) is running Debian Linux, Java is 1.6.0_11 64-Bit, Solr is nightly build (2009-04-02). And no, I can not change the limit of file descriptors (currently: 1024). What more can I do? -- We read Knuth so you don't have to. - Tim Peters Jarek Zgoda, RD, Redefine jarek.zg...@redefine.pl -- +1 510 277-0891 (o) +91 33 7458 (m) web: http://pajamadesign.com Skype: pajamadesign Yahoo: jacobsingh AIM: jacobsingh gTalk: jacobsi...@gmail.com
Re: Too many open files and background merge exceptions
you may try to put true in that useCompoundFile entry; this way indexing should use far less file descriptors, but it will slow down indexing, see http://issues.apache.org/jira/browse/LUCENE-888. Try to see if the reason of lack of descriptors is related only on solr. How are you using indexing, by using solrj, by posting xmls? Are the files being opened/parsed on the same machine of solr? On Mon, Apr 6, 2009 at 2:58 PM, Jarek Zgoda jarek.zg...@redefine.pl wrote: I'm indexing a set of 50 small documents. I'm adding documents in batches of 1000. At the beginning I had a setup that optimized the index each 1 documents, but quickly I had to optimize after adding each batch of documents. Unfortunately, I'm still getting the Too many open files IO error on optimize. I went from mergeFactor of 25 down to 10, but I'm still unable to optimize the index. I have configuration: useCompoundFilefalse/useCompoundFile ramBufferSizeMB256/ramBufferSizeMB mergeFactor2/mergeFactor maxMergeDocs2147483647/maxMergeDocs maxFieldLength1/maxFieldLength The machine (2 core AMD64, 4GB RAM) is running Debian Linux, Java is 1.6.0_11 64-Bit, Solr is nightly build (2009-04-02). And no, I can not change the limit of file descriptors (currently: 1024). What more can I do? -- We read Knuth so you don't have to. - Tim Peters Jarek Zgoda, RD, Redefine jarek.zg...@redefine.pl
Re: too many open files
Am Montag, den 14.07.2008, 09:50 -0400 schrieb Yonik Seeley: Solr uses reference counting on IndexReaders to close them ASAP (since relying on gc can lead to running out of file descriptors). How do you force them to close ASAP? I use File and FileOutputStream objects, I close the output streams and then call delete on the files. I sill have problems with to many open files. After a while I get exceptions that I cannot open any new files. After this the threads stop working and a day later, the files are still open and marked for deletion. I have to kill the server to get it running again or call System.gc() periodically. How do force the VM to realese the files? This happens under RedHat with a 2.4er kernel and under Debian Etch with 2.6er kernel. Thanks, Brian -Yonik On Mon, Jul 14, 2008 at 9:15 AM, Brian Carmalt [EMAIL PROTECTED] wrote: Hello, I have a similar problem, not with Solr, but in Java. From what I have found, it is a usage and os problem: comes from using to many files, and the time it takes the os to reclaim the fds. I found the recomendation that System.gc() should be called periodically. It works for me. May not be the most elegant, but it works. Brian. Am Montag, den 14.07.2008, 11:14 +0200 schrieb Alexey Shakov: now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. Fuad Efendi schrieb: Have you tried [ulimit -n 65536]? I don't think it relates to files marked for deletion... == http://www.linkedin.com/in/liferay Earlier or later, the system crashes with message Too many open files
Re: too many open files
now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. Fuad Efendi schrieb: Have you tried [ulimit -n 65536]? I don't think it relates to files marked for deletion... == http://www.linkedin.com/in/liferay Earlier or later, the system crashes with message Too many open files
Re: too many open files
On Mon, Jul 14, 2008 at 5:14 AM, Alexey Shakov [EMAIL PROTECTED] wrote: now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. How can you tell? Are you seeing descriptor use continually growing? -Yonik
Re: too many open files
Hello, I have a similar problem, not with Solr, but in Java. From what I have found, it is a usage and os problem: comes from using to many files, and the time it takes the os to reclaim the fds. I found the recomendation that System.gc() should be called periodically. It works for me. May not be the most elegant, but it works. Brian. Am Montag, den 14.07.2008, 11:14 +0200 schrieb Alexey Shakov: now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. Fuad Efendi schrieb: Have you tried [ulimit -n 65536]? I don't think it relates to files marked for deletion... == http://www.linkedin.com/in/liferay Earlier or later, the system crashes with message Too many open files
Re: too many open files
Solr uses reference counting on IndexReaders to close them ASAP (since relying on gc can lead to running out of file descriptors). -Yonik On Mon, Jul 14, 2008 at 9:15 AM, Brian Carmalt [EMAIL PROTECTED] wrote: Hello, I have a similar problem, not with Solr, but in Java. From what I have found, it is a usage and os problem: comes from using to many files, and the time it takes the os to reclaim the fds. I found the recomendation that System.gc() should be called periodically. It works for me. May not be the most elegant, but it works. Brian. Am Montag, den 14.07.2008, 11:14 +0200 schrieb Alexey Shakov: now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. Fuad Efendi schrieb: Have you tried [ulimit -n 65536]? I don't think it relates to files marked for deletion... == http://www.linkedin.com/in/liferay Earlier or later, the system crashes with message Too many open files
Re: too many open files
Even Oracle requires 65536; MySQL+MyISAM depends on number of tables, indexes, and Client Threads. From my experience with Lucene, 8192 is not enough; leave space for OS too. Multithreaded application (in most cases) multiplies number of files to a number of threads (each thread needs own handler), in case with SOLR-Tomcat: 256 threads... Number of files depends on mergeFactor=10 (default for SOLR). Now, if 10 is merge factor and we have *.cfs, *.fdt, etc (6 file types per segment): 256*10*6 = 15360 (theoretically) == http://www.linkedin.com/in/liferay Quoting Brian Carmalt [EMAIL PROTECTED]: Hello, I have a similar problem, not with Solr, but in Java. From what I have found, it is a usage and os problem: comes from using to many files, and the time it takes the os to reclaim the fds. I found the recomendation that System.gc() should be called periodically. It works for me. May not be the most elegant, but it works. Brian. Am Montag, den 14.07.2008, 11:14 +0200 schrieb Alexey Shakov: now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. Fuad Efendi schrieb: Have you tried [ulimit -n 65536]? I don't think it relates to files marked for deletion... == http://www.linkedin.com/in/liferay Earlier or later, the system crashes with message Too many open files
Re: too many open files
On Mon, Jul 14, 2008 at 9:52 AM, Fuad Efendi [EMAIL PROTECTED] wrote: Even Oracle requires 65536; MySQL+MyISAM depends on number of tables, indexes, and Client Threads. From my experience with Lucene, 8192 is not enough; leave space for OS too. Multithreaded application (in most cases) multiplies number of files to a number of threads (each thread needs own handler), in case with SOLR-Tomcat: 256 threads... Number of files depends on mergeFactor=10 (default for SOLR). Now, if 10 is merge factor and we have *.cfs, *.fdt, etc (6 file types per segment): 256*10*6 = 15360 (theoretically) In Solr, the number of threads does not come into play. It would only matter in Lucene if you were doing something like opening an IndexReader per thread or something. The number of files per segment is normally more like 12, but only 9 of them are held open for the entire life of the reader. Also remember that the IndexWriter internally uses another IndexReader to do deletions, and Solr can have 2 (or more) open... one serving queries and one opening+warming. -Yonik
Re: too many open files
Yonik Seeley schrieb: On Mon, Jul 14, 2008 at 5:14 AM, Alexey Shakov [EMAIL PROTECTED] wrote: now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. How can you tell? Are you seeing descriptor use continually growing? -Yonik 'deleted' index files, listed with lsof-command today, was listed (also as deleted) several days ago... But the amount of this 'deleted' files increases. So, I make a conclusion, that this is the question of time, when the limit of 1 will be reached. Fortunately, the check-ins of new documents are seldom. The server (Tomcat) was restarted (due to different software updates) relatively oft in the last weeks... So, we had no yet the possibility to reach this limit. But the default open file limit (1024) was already reached several times (before we increase it)… Thanks for your help ! Alexey
Re: too many open files
On Mon, Jul 14, 2008 at 10:17 AM, Alexey Shakov [EMAIL PROTECTED] wrote: Yonik Seeley schrieb: On Mon, Jul 14, 2008 at 5:14 AM, Alexey Shakov [EMAIL PROTECTED] now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. How can you tell? Are you seeing descriptor use continually growing? -Yonik 'deleted' index files, listed with lsof-command today, was listed (also as deleted) several days ago... But the amount of this 'deleted' files increases. So, I make a conclusion, that this is the question of time, when the limit of 1 will be reached. You are probably just seeing growth in the number of segments in the index... which means that any IndexReader will be holding open a larger number of files at any one time (and become deleted when the IndexWriter removes old segments). This growth in the number of segments isn't unbounded though (because of segment merges). Your 10,000 descriptors should be sufficient. -Yonik Fortunately, the check-ins of new documents are seldom. The server (Tomcat) was restarted (due to different software updates) relatively oft in the last weeks... So, we had no yet the possibility to reach this limit. But the default open file limit (1024) was already reached several times (before we increase it)… Thanks for your help ! Alexey
Re: too many open files
Yonik Seeley schrieb: On Mon, Jul 14, 2008 at 10:17 AM, Alexey Shakov [EMAIL PROTECTED] wrote: Yonik Seeley schrieb: On Mon, Jul 14, 2008 at 5:14 AM, Alexey Shakov [EMAIL PROTECTED] now we have set the limt to ~1 files but this is not the solution - the amount of open files increases permanantly. Earlier or later, this limit will be exhausted. How can you tell? Are you seeing descriptor use continually growing? -Yonik 'deleted' index files, listed with lsof-command today, was listed (also as deleted) several days ago... But the amount of this 'deleted' files increases. So, I make a conclusion, that this is the question of time, when the limit of 1 will be reached. You are probably just seeing growth in the number of segments in the index... which means that any IndexReader will be holding open a larger number of files at any one time (and become deleted when the IndexWriter removes old segments). This growth in the number of segments isn't unbounded though (because of segment merges). Your 10,000 descriptors should be sufficient. -Yonik Ok, thank you for the explanation. I will observ the open files amount over the time - hopefully it remains stable. Best regards, Alexey Fortunately, the check-ins of new documents are seldom. The server (Tomcat) was restarted (due to different software updates) relatively oft in the last weeks... So, we had no yet the possibility to reach this limit. But the default open file limit (1024) was already reached several times (before we increase it)… Thanks for your help ! Alexey -- Alexey Shakov (Senior Software Entwickler/Architekt) menta AG - The Information E-volution http://www.menta.de/ Bodenseestraße 4, D-81241 München Telefon: +49-89/87130-142 Telefax: +49-89/87130-146 Mobil: +49-177/3200615 E-Mail: [EMAIL PROTECTED] Eintrag: Amtsgericht München, HRB 125132 Vorstand: Reinhold Müller Aufsichtsrat: Thomas N. Pieper (Vors.)
Re: too many open files
Have you tried [ulimit -n 65536]? I don't think it relates to files marked for deletion... == http://www.linkedin.com/in/liferay Earlier or later, the system crashes with message Too many open files
Re: Too many open files
I'm not sure what large db you are referring to (indexing a RDBMS to Solr?), but the first thing to do is run ulimit -a (or some flavour of it, depending on the OS) and increase the open file descriptors limit if the one you see there is just very low (e.g. 1024). If that limit is not low, make sure that things are getting closed properly by your app, so there are no f.d. leaks. Also, make sure mergeFactor is not ridiculously high. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Wagner,Harry [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Friday, May 2, 2008 9:04:56 PM Subject: Too many open files I'm getting this with Solr 1.2 trying to load a large db. Is there a workaround?
Re: too many open files , is it a leak of handler there?
Yonik, can i ask where can i get the fixed code? or the patch? i can not find it in jira? i am a new here.thank you ^_^ - Original Message - From: Yonik Seeley [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Saturday, March 01, 2008 10:53 AM Subject: Re: too many open files , is it a leak of handler there? I just committed a fix for this. Thanks for tracking this down! -Yonik 2008/2/29 陈亮亮 [EMAIL PROTECTED]: ok i have compared the DirectSolrConnection .java and SolrDispatchFilter.java, and found that the DirecSolrConnection really do not call the req.colse() as SolrDispatchFilter do, which is said to free the resources. i guess it is the leak of handlers,i will try and see.^_^ - Original Message - From: 陈亮亮 [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Friday, February 29, 2008 4:51 PM Subject: too many open files , is it a leak of handler there? when embeded the solr in my application last night, i encountered the too many open file exception just like that said in http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200702.mbox/[EMAIL PROTECTED]. And i used DirectSolrConnection to integrate solr with my application. I debuged when solr doing search, and i found that every time solr had a query search done the refcount will increase one. I know solr use refcount to keep reasher safe close, but should it be +1 when solr doing search and -1( it is to say call decref()) after search done? or else when commit take place it just decrease the refcount by 1, and the refount still1 and searcher not really close, which leads to the hanging of the handlers and finally the too many open files problem. Is it a bug? or i should not use the DirectSolrConnection? By the way the ulimit -n 1 not work out in my case, it just delay the time. i use the lsof |grep solr| wc -l to monitor the handler, it keeps increasing, i think it is a leak of handler here. Any help would appreciated, thank you !!!
Re: too many open files , is it a leak of handler there?
2008/3/2 陈亮亮 [EMAIL PROTECTED]: Yonik, can i ask where can i get the fixed code? or the patch? i can not find it in jira? i am a new here.thank you ^_^ I committed it to trunk (the most current development version in subversion). The most recent nightly build should have it. -Yonik - Original Message - From: Yonik Seeley [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Saturday, March 01, 2008 10:53 AM Subject: Re: too many open files , is it a leak of handler there? I just committed a fix for this. Thanks for tracking this down! -Yonik 2008/2/29 陈亮亮 [EMAIL PROTECTED]: ok i have compared the DirectSolrConnection .java and SolrDispatchFilter.java, and found that the DirecSolrConnection really do not call the req.colse() as SolrDispatchFilter do, which is said to free the resources. i guess it is the leak of handlers,i will try and see.^_^ - Original Message - From: 陈亮亮 [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Friday, February 29, 2008 4:51 PM Subject: too many open files , is it a leak of handler there? when embeded the solr in my application last night, i encountered the too many open file exception just like that said in http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200702.mbox/[EMAIL PROTECTED]. And i used DirectSolrConnection to integrate solr with my application. I debuged when solr doing search, and i found that every time solr had a query search done the refcount will increase one. I know solr use refcount to keep reasher safe close, but should it be +1 when solr doing search and -1( it is to say call decref()) after search done? or else when commit take place it just decrease the refcount by 1, and the refount still1 and searcher not really close, which leads to the hanging of the handlers and finally the too many open files problem. Is it a bug? or i should not use the DirectSolrConnection? By the way the ulimit -n 1 not work out in my case, it just delay the time. i use the lsof |grep solr| wc -l to monitor the handler, it keeps increasing, i think it is a leak of handler here. Any help would appreciated, thank you !!!
Re: too many open files , is it a leak of handler there?
ok i have compared the DirectSolrConnection .java and SolrDispatchFilter.java, and found that the DirecSolrConnection really do not call the req.colse() as SolrDispatchFilter do, which is said to free the resources. i guess it is the leak of handlers,i will try and see.^_^ - Original Message - From: 陈亮亮 [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Friday, February 29, 2008 4:51 PM Subject: too many open files , is it a leak of handler there? when embeded the solr in my application last night, i encountered the too many open file exception just like that said in http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200702.mbox/[EMAIL PROTECTED]. And i used DirectSolrConnection to integrate solr with my application. I debuged when solr doing search, and i found that every time solr had a query search done the refcount will increase one. I know solr use refcount to keep reasher safe close, but should it be +1 when solr doing search and -1( it is to say call decref()) after search done? or else when commit take place it just decrease the refcount by 1, and the refount still1 and searcher not really close, which leads to the hanging of the handlers and finally the too many open files problem. Is it a bug? or i should not use the DirectSolrConnection? By the way the ulimit -n 1 not work out in my case, it just delay the time. i use the lsof |grep solr| wc -l to monitor the handler, it keeps increasing, i think it is a leak of handler here. Any help would appreciated, thank you !!!
Re: too many open files , is it a leak of handler there?
i think i have just fix the problem, and close method in Directsolrconnection, and now the number of handler keeps stable. hope it would help other solr users ^_^ - Original Message - From: 陈亮亮 [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Saturday, March 01, 2008 9:33 AM Subject: Re: too many open files , is it a leak of handler there? ok i have compared the DirectSolrConnection .java and SolrDispatchFilter.java, and found that the DirecSolrConnection really do not call the req.colse() as SolrDispatchFilter do, which is said to free the resources. i guess it is the leak of handlers,i will try and see.^_^ - Original Message - From: 陈亮亮 [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Friday, February 29, 2008 4:51 PM Subject: too many open files , is it a leak of handler there? when embeded the solr in my application last night, i encountered the too many open file exception just like that said in http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200702.mbox/[EMAIL PROTECTED]. And i used DirectSolrConnection to integrate solr with my application. I debuged when solr doing search, and i found that every time solr had a query search done the refcount will increase one. I know solr use refcount to keep reasher safe close, but should it be +1 when solr doing search and -1( it is to say call decref()) after search done? or else when commit take place it just decrease the refcount by 1, and the refount still1 and searcher not really close, which leads to the hanging of the handlers and finally the too many open files problem. Is it a bug? or i should not use the DirectSolrConnection? By the way the ulimit -n 1 not work out in my case, it just delay the time. i use the lsof |grep solr| wc -l to monitor the handler, it keeps increasing, i think it is a leak of handler here. Any help would appreciated, thank you !!!
Re: too many open files , is it a leak of handler there?
I just committed a fix for this. Thanks for tracking this down! -Yonik 2008/2/29 陈亮亮 [EMAIL PROTECTED]: ok i have compared the DirectSolrConnection .java and SolrDispatchFilter.java, and found that the DirecSolrConnection really do not call the req.colse() as SolrDispatchFilter do, which is said to free the resources. i guess it is the leak of handlers,i will try and see.^_^ - Original Message - From: 陈亮亮 [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Friday, February 29, 2008 4:51 PM Subject: too many open files , is it a leak of handler there? when embeded the solr in my application last night, i encountered the too many open file exception just like that said in http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200702.mbox/[EMAIL PROTECTED]. And i used DirectSolrConnection to integrate solr with my application. I debuged when solr doing search, and i found that every time solr had a query search done the refcount will increase one. I know solr use refcount to keep reasher safe close, but should it be +1 when solr doing search and -1( it is to say call decref()) after search done? or else when commit take place it just decrease the refcount by 1, and the refount still1 and searcher not really close, which leads to the hanging of the handlers and finally the too many open files problem. Is it a bug? or i should not use the DirectSolrConnection? By the way the ulimit -n 1 not work out in my case, it just delay the time. i use the lsof |grep solr| wc -l to monitor the handler, it keeps increasing, i think it is a leak of handler here. Any help would appreciated, thank you !!!
RE: Too many open files
Good link, I added it to the wiki page where optimization is covered, http://wiki.apache.org/solr/SolrPerformanceFactors . Paul Sundling -Original Message- From: Stu Hood [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 9:23 AM To: solr-user@lucene.apache.org Subject: RE: Too many open files If you check out the documentation for mergeFactor, you'll find that adjusting it downward can lower the number of open files. Just remember that it is a speed tradeoff, and only lower it as much as you need to to stop getting the too many files errors. See this section: http://www.onjava.com/pub/a/onjava/2003/03/05/lucene.html#indexing_speed Thanks, Stu -Original Message- From: Ard Schrijvers [EMAIL PROTECTED] Sent: Thu, August 9, 2007 10:52 am To: solr-user@lucene.apache.org Subject: RE: Too many open files Hello, useCompoundFile set to true, should avoid the problem. You could also try to set maximum open files higher, something like (I assume linux) ulimit -n 8192 Ard You're a gentleman and a scholar. I will donate the MMs to myself :). Can you tell me from this snippet of my solrconfig.xml what I might tweak to make this more betterer? -KH default unless overridden. -- false 10 1000 2147483647 1 1000 1
RE: Too many open files
You're a gentleman and a scholar. I will donate the MMs to myself :). Can you tell me from this snippet of my solrconfig.xml what I might tweak to make this more betterer? -KH indexDefaults !-- Values here affect all index writers and act as a default unless overridden. -- useCompoundFilefalse/useCompoundFile mergeFactor10/mergeFactor maxBufferedDocs1000/maxBufferedDocs maxMergeDocs2147483647/maxMergeDocs maxFieldLength1/maxFieldLength writeLockTimeout1000/writeLockTimeout commitLockTimeout1/commitLockTimeout /indexDefaults
RE: Too many open files
You could try committing updates more frequently, or maybe optimising the index beforehand (and even during!). I imagine you could also change the Solr config, if you have access to it, to tweak indexing (or index creation) parameters - http://wiki.apache.org/solr/SolrConfigXml should be of use to you here. In the unlikely event I qualify for the MMs, I hereby donate them back to you for giving to someone else! Jon -Original Message- From: Kevin Holmes [mailto:[EMAIL PROTECTED] Sent: 09 August 2007 15:23 To: solr-user@lucene.apache.org Subject: Too many open files result status=1java.io.FileNotFoundException: /usr/local/bin/apache-solr/enr/solr/data/index/_16ik.tii (Too many open files) When I'm importing, this is the error I get. I know it's vague and obscure. Can someone suggest where to start? I'll buy a bag of MMs (not peanut) for anyone who can help me solve this* *limit one bag per successful solution for a total maximum of 1 bag to be given
RE: Too many open files
If you check out the documentation for mergeFactor, you'll find that adjusting it downward can lower the number of open files. Just remember that it is a speed tradeoff, and only lower it as much as you need to to stop getting the too many files errors. See this section: http://www.onjava.com/pub/a/onjava/2003/03/05/lucene.html#indexing_speed Thanks, Stu -Original Message- From: Ard Schrijvers [EMAIL PROTECTED] Sent: Thu, August 9, 2007 10:52 am To: solr-user@lucene.apache.org Subject: RE: Too many open files Hello, useCompoundFile set to true, should avoid the problem. You could also try to set maximum open files higher, something like (I assume linux) ulimit -n 8192 Ard You're a gentleman and a scholar. I will donate the MMs to myself :). Can you tell me from this snippet of my solrconfig.xml what I might tweak to make this more betterer? -KH default unless overridden. -- false 10 1000 2147483647 1 1000 1
Re: Too many open files
On 9-Aug-07, at 7:52 AM, Ard Schrijvers wrote: ulimit -n 8192 Unless you have an old, creaky box, I highly recommend simply upping your filedesc cap. -Mike
