[Koha] Out of memory

[King, Fred]

I had a similar experience. I was running a test installation on a Digital Ocean server with 512MB RAM where I was the *only* user. The production site has much more and is a lot happier.

Fred King
Medical Librarian, MedStar Washington Hospital Center
fred.king at medstar.net
202-877-6670
ORCID 0000-0001-5266-0279
MedStar Authors Catalog: http://medstarauthors.org

Sometimes I wake up from a dream and then go back to it in disguise so I can find out what they’re saying about me behind my back.
--Bill in Portland


-----Original Message-----
From: Koha [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Chris Brown
Sent: Monday, March 19, 2018 3:28 AM
To: Rubeno Fernández
Cc: koha
Subject: Re: [Koha] Out of memory

Hi Rubeno,

We have less biblio records than you (about 5000) and initially we hosted Koha on a VPS with just 1Gb of memory, also from Digital Ocean, as it happens. With six staff users logged in (during training sessions) were getting a variety of software errors, though I don't think mysqld ever crashed. Memory usage was pretty high, and upgrading to a droplet with 2Gb of memory gave a big improvement. It's certainly worth a try.  Running "top" may give you a more fine-grained picture of memory usage, particularly if you sort on the %MEM column.

Hope this helps,

Best Regards,

Chris Brown


On Mon, Mar 19, 2018 at 6:12 AM, Rubeno Fernández <enseikou at gmail.com>
wrote:

> Hi all,
>
> How much memory do you need to run Koha?
> I run a database with about 22000 records on a virtual server on 
> Digital Ocean with 1GB memory and very low usage, but the server is 
> crashing very often.
>
> With dmesg I find this kind of messages several times a day:
>
> [Sun Mar 18 16:10:10 2018] https://urldefense.proofpoint.com/v2/url?u=http-3A__addbiblio.pl&d=DwIGaQ&c=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVxj8-bJ04M&r=vKh6XwOmjyC51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI&m=_CAkvYy8a_k5aiwJyQiQqtxn5XZudWCc-7c9qWutA44&s=Pr97cNpNijeEtvP2zz_V-3RB5qcZ1D5NoouUxkbV6CA&e= invoked oom-killer:
> gfp_mask=0x24201ca, order=0, oom_score_adj=0 [Sun Mar 18 16:10:10 
> 2018] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__addbiblio.pl&d=DwIGaQ&c=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVxj8-bJ04M&r=vKh6XwOmjyC51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI&m=_CAkvYy8a_k5aiwJyQiQqtxn5XZudWCc-7c9qWutA44&s=Pr97cNpNijeEtvP2zz_V-3RB5qcZ1D5NoouUxkbV6CA&e= cpuset=/ mems_allowed=0 And then MySQL crashes and restarts:
> Sun Mar 18 16:10:10 2018] Out of memory: Kill process 6539 (mysqld) 
> score
> 222
> or sacrifice child
> [Sun Mar 18 16:10:10 2018] Killed process 6539 (mysqld) 
> total-vm:1538124kB, anon-rss:224948kB, file-rss:0kB
>
> From /var/log/syslog:
> Mar 18 16:10:11 biblioteko systemd[1]: mysql.service: Main process 
> exited, code=killed, status=9/KILL Mar 18 16:10:11 biblioteko 
> systemd[1]: mysql.service: Unit entered failed state.
> Mar 18 16:10:11 biblioteko systemd[1]: mysql.service: Failed with 
> result 'signal'.
> Mar 18 16:10:11 biblioteko systemd[1]: mysql.service: Service hold-off 
> time over, scheduling restart.
> Mar 18 16:10:11 biblioteko systemd[1]: Stopped MySQL Community Server.
> Mar 18 16:10:11 biblioteko systemd[1]: Starting MySQL Community Server...
>
> Just yesterday the killed process was rebuild_zebra.p, which didn't 
> restart, and Koha was retrieving no results for searches.
>
> The strange thing is that Digital Ocean's own monitoring tool never 
> reports such memory spikes: usage is usually high but never more than 
> 80%. Maybe the spikes are too short? What would you recommend for a 
> more fine-grained monitoring of memory?
>
> Right now my memory is this:
> root at biblioteko:~# free
>               total        used        free      shared  buff/cache
> available
> Mem:        1016056      555304      266328       14936      194424
> 292164
> Swap:             0           0           0
>
> On file /etc/mysql/mysql.conf.d/mysqld.cnf the value of 
> "innodb_buffer_pool_size" is 385M, if that's of any help.
>
> Do I really need more physical memory on my server?
> _______________________________________________
> Koha mailing list  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__koha-2Dcommunity.o
> rg&d=DwIGaQ&c=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVxj8-bJ04M&r=vKh6XwOmjy
> C51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI&m=_CAkvYy8a_k5aiwJyQiQqtxn5XZudWCc-7
> c9qWutA44&s=tnQspFRCDDxEBJblf-_FcsZhDDeWhlcF6WhHYxtZDgo&e=
> Koha at lists.katipo.co.nz
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.katipo.co.n
> z_mailman_listinfo_koha&d=DwIGaQ&c=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVx
> j8-bJ04M&r=vKh6XwOmjyC51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI&m=_CAkvYy8a_k5a
> iwJyQiQqtxn5XZudWCc-7c9qWutA44&s=x97u-EzVBbonN7yFavnLDjNXL8LhF7E3kf82U
> Nc9pUg&e=
>
_______________________________________________
Koha mailing list  https://urldefense.proofpoint.com/v2/url?u=http-3A__koha-2Dcommunity.org&d=DwIGaQ&c=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVxj8-bJ04M&r=vKh6XwOmjyC51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI&m=_CAkvYy8a_k5aiwJyQiQqtxn5XZudWCc-7c9qWutA44&s=tnQspFRCDDxEBJblf-_FcsZhDDeWhlcF6WhHYxtZDgo&e=
Koha at lists.katipo.co.nz
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.katipo.co.nz_mailman_listinfo_koha&d=DwIGaQ&c=RvBXVp2Kc-itN3g6r3sN0QK_zL4whPpndVxj8-bJ04M&r=vKh6XwOmjyC51IkP1OfsdjQZoWT2vpi6VZl8El8EPRI&m=_CAkvYy8a_k5aiwJyQiQqtxn5XZudWCc-7c9qWutA44&s=x97u-EzVBbonN7yFavnLDjNXL8LhF7E3kf82UNc9pUg&e=