Apologies all I just realised I replied to the wrong thread. This is in response to "Solr cloud on Docker?" not "SolrCloud" location for solr.xml". Apologies for the confusion.
Thanks Dwane ________________________________ From: Dwane Hall <dwaneh...@hotmail.com> Sent: Monday, 2 March 2020 7:31 PM To: Jan Høydahl <jan....@cominvent.com>; solr-user@lucene.apache.org <solr-user@lucene.apache.org> Subject: Re: SolrCloud location for solr.xml Hey Jan, Thanks for the info re swap there’s some interesting observations you’ve mentioned below particularly the container swap by default. There was this note on the Docker forum describing a similar situation you mention did you attempt these settings with the same result? (https://success.docker.com/article/node-using-swap-memory-instead-of-host-memory) It mentions Docker EE specifically but it might be worth a try. In our environment we also run a vm.swappiness setting of 1 (our OS default) which is inherited by our containers as we don’t enforce any memory or resource limits directly on them. I did not attempt to turn off container swap during my testing so I don't have any benchmarks to relay back but if I get some clear air I’ll try to spin up some tests and see if I can replicate your observations. There’s a great resource/tutorial from the Alibaba guys on testing and tweaking container resource limits and their observations are far more comprehensive than my experience (ref below). If you haven't seen it may prove a useful reference for testing as I’ve noticed some of the Docker settings are not quite what you expect them to be. For example the Docker documentation defines the –cpus value as follows: “Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set --cpus="1.5", the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting --cpu-period="100000" and --cpu-quota="150000". Available in Docker 1.13 and higher. “ From the reference below CPU’s = Threads per core X cores per socket X sockets CPUs are not physical CPU’s We found this out the hard way when attempting to CPU resource limit a Fusion instance and wondered why it was struggling to start all its services on a single thread instead of a physical CPU 🙂 It's a three part series https://www.alibabacloud.com/blog/594573?spm=a2c5t.11065265.1996646101.searchclickresult.612d62b1TGCY58 https://www.alibabacloud.com/blog/docker-container-resource-management-cpu-ram-and-io-part-2_594575 https://www.alibabacloud.com/blog/594579?spm=a2c5t.11065265.1996646101.searchclickresult.612d62b1TGCY58 I'll keep a keen eye on any developments and relay back if I get some tests together. Cheers, Dwane PS: I’m assuming you're testing Solr 8.4.1 on Linux hosts? ________________________________ From: Jan Høydahl <jan....@cominvent.com> Sent: Monday, 2 March 2020 12:01 AM To: solr-user@lucene.apache.org <solr-user@lucene.apache.org> Subject: Re: SolrCloud location for solr.xml As long as solr.xml is a mix of setting that need to be separate per node and cluster wide settings, it makes no sense to enforce it in zk. Perhaps we instead should stop requiring solr.xml and allow nodes to start without it. Solr can then use a hard coded version as fallback. Most users just copies the example solr.xml into SOLR_HOME so if we can simplify the 80% case I don’t mind if more advanced users put it in zk or in local file system. Jan Høydahl > 1. mar. 2020 kl. 01:26 skrev Erick Erickson <erickerick...@gmail.com>: > > Actually, I do this all the time. However, it’s because I’m always blowing > everything away and installing a different version of Solr or some such, > mostly laziness. > > We should move away from allowing solr.xml to be in SOLR_HOME when running in > cloud mode IMO, but that’ll need to be done in phases. > > Best, > Erick > >> On Feb 28, 2020, at 5:17 PM, Mike Drob <md...@apache.org> wrote: >> >> Hi Searchers! >> >> I was recently looking at some of the start-up logic for Solr and was >> interested in cleaning it up a little bit. However, I'm not sure how common >> certain deployment scenarios are. Specifically is anybody doing the >> following combination: >> >> * Using SolrCloud (i.e. state stored in zookeeper) >> * Loading solr.xml from a local solr home rather than zookeeper >> >> Much appreciated! Thanks, >> Mike
