With the success on preliminary benchmark on my use case for Elasticsearch . I thought I would see how it ran on a ARM based ODroid U3.

The U3 is a credit card sized mini PC from HardKernel, that runs Android or Linux.

The Odroid U3 Specs include a 1.7GHz Exynos4412 Prime Cortex-A9 Quad-core processor, and 2GB RAM. While it support MMC storage, I'll be using a 16GB Sandisk Ultra UHS I Class 10 SD Card, in part to makes things interesting, and in part so I easily swap out my Android XBMC MMC between projects.

I have gone with Ubuntu 14.4 from the ODroid forum site.

Oracle Java 8 via apt-get was straight forward, however elasticsearch via packages.elasticsearch.org did not explicitly support armhf.

I added the following to /etc/apt/sources.list as outline by the docs

However apt-get update gave me the following error.

As Elasticsearch runs in Java, I figured running the x86 version would be fine. Just needed to figure out how to do it.

After hitting a dead end after editing /etc/dpkg/dpkg.cfg.d/architectures, I tried adding architecture tags to /etc/apt/sources.list as outlined in the Multarch/HOWTO.

Worked a treat, package sources updated, and elastic search installed as a deb package.

Like any software raised on linux, even where it runs under a JVM like Elasticsearch, running it on windows bring to light a few quirks.

One of the most common Elastic Search Environment Variables is ES_HEAP_SIZE, shown in the System variable panel below.

With the default set to 1GB, setting this is often done early on, though note the following 2 gotcha's in windows.

  1. After you set the ES_HEAP_SIZE, you need to re-install the service. Restarting ES won't do it.
  2. If you are restarting the service from the command line, remember to open a new CMD window after setting the Environment Variables, A stale window will hold the old value, (or have none if none was set) and restarting the service in that cmd.exe session won't update the heap size.

Here is how you can ensure that your Environment Variable took under the JVM section via /_nodes/stats?pretty=true

Also, remember to not cross 31Gb!