Hi Shawn,
Thanks for the information.
On 2/19/16 3:32 PM, Shawn Heisey wrote:
You will use fewer resources if you only run one Solr instance on each
machine. You can still have different considerations for different
hardware with one instance -- on the servers with more resources,
configure a larger Java heap and run more indexes.
Yes, I do realize the performance across this box would run better with
a single instance. However, jump down to the bottom comment for more detail.
If the plan is to run SolrCloud, having only one Solr instance per
physical machine will ensure that SolrCloud never places more than one
replica for a shard on the same physical host, and it will do this
without special configuration.
I will confirm the use of SolrCloud in this environment. This hasn't
been mentioned so far, but I don't always get all information from the
software architects immediately when I'm still in build mode.
The documentation is driven by what users ask for. A lot of users ask
how to run multiple instances on one machine. Your idea above would be
my preference on how to handle the documentation. Or perhaps leave the
instructions in there, but include a strong warning indicating that one
instance will usually work better.
Each time I see somebody ask how to run multiple instances, I give them
the same advice I gave you. It is often ignored.
Here's the fundamental issue when talking about use of software like
Solr in a corporate environment. As a systems engineer at Marketo, my
best practices recommendations and justifications are based on the
documentation provided by the project owners. If the project's docs
state that something is feasible without any warnings, not only will the
software engineer latch onto that documentation and want to use it in
that way, my hands will be tied as a systems engineer when I'm expected
to roll that architecture to production, as I have nothing to argue
against that use case.
So, here's the word of caution to project owners. Many companies work
just like Marketo. The software team will design and build a platform
based on what the documentation states is possible. My job (in addition
to building a functional system) is to not only read through the install
docs to ensure Marketo is following best practices, but also to be the
voice of clarity when concepts are cloudy. If a doc explicitly says
"don't do this" or "warning: not supported", I have immediate
justification to recommend not following that path when going into
production. However, when docs are written that state that something is
possible without a hint of "but this is bad and here's why", my hands
are tied when talking to management. They need hard facts and with
reasons not to go into production with a specific design. The management
here are fact driven and need to see reasons from the project owners /
developers (not from me) why any given setup is not recommended.
I am personally not at all fond of doubling up services of any type when
going into production simply for the reason that either of the two
processes could bring down the whole box and take down both instances.
But, that argument alone isn't strong enough to justify not doing it.
This issue isn't limited to Solr / Java. This type of failure can happen
with any application of any type. However, for management to take a
design change seriously, I need technical ammo (in the form of docs that
state major performance degradation) that I can take to them and say,
"Hey, look at this. It says not to do this because .... " and then we
come up with an alternative design.
I should also like to note that we have a current environment, although
much smaller, which has been running two instances per box seemingly
without issues for several years. For me to attempt to argue that it's
not possible or is a bad idea goes against the experience we've already
accrued when running two Solr JVMs side-by-side. So, if there is some
legitimate benchmarks that, for example, show side-by-side instances
degrade each other worse than running two Xen VMs on the same systems or
when running alone, then I have a strong reason to suggest using an
alternative design. Unfortunately, our past use of Solr already
justifies the use of two instances in this new replacement system.
Thanks.
Thanks,
Shawn
--
Signature
*Brian Wright*
*Sr. Systems Engineer *
901 Mariners Island Blvd Suite 200
San Mateo, CA 94404 USA
*Email *bri...@marketo.com <mailto:bri...@marketo.com>
*Phone *+1.650.539.3530**
*****www.marketo.com <http://www.marketo.com/>*
Marketo Logo
