What are you trying to achieve by using virtualisation? If it is just code separation, consider using containers and Docker rather than fully fledged VMs.
CPU is shared, but each container sees its own view of its file system. Upayavira On Thu, Oct 1, 2015, at 07:47 AM, Bernd Fehling wrote: > Hi Shawn, > > unfortunately we have to run VMs, otherwise we would waste hardware. > I thought other solr users are in the same situation but seams that > other users have tons of hardware available and we are the only one > having to use VMs. > Right, bare metal is always better than any VM. > As you mentioned we have the indexer (master) on one physical machine > and two searchers (slaves) on other physical machines, all together with > other little VMs which are not I/O and CPU heavy. > > Regards > Bernd > > Am 30.09.2015 um 18:48 schrieb Shawn Heisey: > > On 9/30/2015 3:12 AM, Bernd Fehling wrote: > >> while setting up some new servers (virtual machines) using XEN I was > >> thinking about an alternative like KVM. My last tests with KVM is > >> a while ago and XEN performed much better in the area of I/O and > >> CPU usage. > >> This lead me to the idea to start a poll about virtualization platform and > >> your experiences. > > > > I once had a virtualized Solr install with Xen where each VM housed one > > Solr instance with one core. The index was distributed, so it required > > several VMs for one copy of the index. > > > > I eliminated the virtualization, used the same hardware as bare metal > > with Linux, still one Solr instance installed on the machine, but with > > multiple Solr cores. Performance is much better now. > > > > General advice: Don't run virtual machines. > > > > If a virtual environment is the only significant hardware you have > > access to and it's used for more than Solr, then you might need to. If > > you do run virtual, then minimize the number of VMs, don't put multiple > > replicas of the same index data on the same physical VM host, give each > > Solr VM lots of memory, and don't oversubscribe the memory/cpu on the > > physical VM host. > > > > Thanks, > > Shawn > >
