Thanks Rick,
Turns out it was the kernel killing it, dmesg showed:
Out of memory: Kill process 2647 (java) score 118 or sacrifice child
Killed process 2647, UID 1006, (java) total-vm:2857484kB,
anon-rss:227440kB, file-rss:12kB
Now I just need to tell the kernel not to do that.
The other things on the box are nginx and my Perl web-app.
Those 2 are both restarted upon a deploy, which is what knocks Solr down.
I'll experiment with different heap values, with a 1MB index (on disk) I
should be able to get it fairly low.
I have the same occasional problem on my dev box, which only has 1GB RAM
- quite surprising it runs at all on there if it has half the ram of the
live box(es).
On 26/05/17 07:35, Rick Leir wrote:
Robert,
What is at the end of solr.log when it has died?
Is there anything in syslog or messages?
What is the other app?
Run the top command, memory screen, on Ubuntu:
$ top -o RES
I have never used strace(1) on Solr, but that is an option. Run Solr
in strace with the appropriate options to reduce the voluminous output.
You could upgrade your hardware cheaply at a surplus store (almost
every machine in my office is surplus .. think .. actually, every one).
cheers -- Rick
On 2017-05-25 06:55 PM, Robert Brown wrote:
Hi,
I'm currently running 6.5.1 with a tiny index, less than 1MB.
When I restart another app on the same server as Solr, Solr
occasionally dies, but no solr_oom_killer.log file.
Heap size is 256MB (~30MB used), Physical RAM 2GB, typically using
1.5GB.
How else can I debug what's causing it?
Also, for such a small index, what would be an appropriate heap
size? 10MB seems to just kill it (OOM log file produced) as it starts.
Thanks,
Rob
