On 11/1/2016 1:07 AM, Kent Mu wrote: > Hi friends! We come across an issue when we use the solrj(4.9.1) to > connect to solr server, our deployment is one master with 10 replicas. > we index data to the master, and search data from the replicas via > load balancing. the error stack is as below: *Timeout occured while > waiting response from server at: > http://review.solrsearch3.cnsuning.com/solr/commodityReview > <http://review.solrsearch3.cnsuning.com/solr/commodityReview>* > org.apache.solr.client.solrj.SolrServerException: Timeout occured > while waiting response from server at:
This shows that you are connecting to port 80. It is relatively rare to run Solr on port 80, though it is possible. Do you have an intermediate layer, like a proxy or a load balancer? If so, you'll need to ensure that there's not a problem there. If it works normally when replication isn't happening, that's probably not a worry. > It takes place not often. after analysis, we find that only when the > replicas Synchronous Data from master solr server. it seem that when > the replicas block search requests when synchronizing data from > master, is that true? Solr should be able to continue serving requests while replication happens. I have never heard of this happening before, and I never ran into it when I was using replication a long time ago on version 1.4.x. I think it is more likely that you've got a memory issue than a bug. If it IS a bug, it will *not* be fixed in a 4.x version, you would need to upgrade to 6.x and see whether it's still a problem. Version 6.2.1 is the latest at the moment, and release plans are underway for 6.3 right now. > I wonder if it is because that our solr server hardware configuration > is too low? the physical memory is 8G with 4 cores. and the JVM we set > is Xms512m, Xmx7168m. The following assumes that there is no other software on the server, like a database, or an application server, web server, etc. If there is, any issues are likely to be a result of extreme memory starvation, and possibly swapping. Additional physical memory is definitely needed if there is other software on the server beyond basic OS tools. If the total index data that is on your server is larger than about 1.5 to 2GB, chances are excellent that you do not have enough free memory to cache that data effectively, which can lead to major performance issues. You've only left about 1GB of memory in the system for that purpose, and that memory must also run the entire operating system, which can take a significant percentage of 1GB. With a large index, I would strongly recommend adding memory to this server. https://wiki.apache.org/solr/SolrPerformanceProblems As mentioned in that wiki page, for good performance Solr absolutely requires that the operating system have spare memory available to cache the index. In general, allocating almost all your memory to the Java heap is a bad idea with Solr. If your index *is* smaller than 1.5 to 2GB, allocating a 7GB heap is probably not necessary, unless you are doing *incredibly* memory-hungry queries, such as grouping, faceting, or sorting on many fields. If you can reduce the heap size, there would be more memory available for caching. Indexing can sometimes cause very large merges to happen, and a full index optimize would rewrite the entire index. Replication copies the changed index files, and if the size of the changes is significant, additional memory can be required for good performance. See the special note on the wiki page above about optimizes. Thanks, Shawn
