1

I use VestaCP on Debian 9.

Yesterday I received 3 email alerts related to cron. All three contain the same error message: /bin/sh: execle: Cannot allocate memory.

So, I started with the free --mega command:

              total        used        free      shared  buff/cache   available
Mem:           5969        5078         366         210         525         452
Swap:             0           0           0

There is clearly a RAM problem since I only have 366 Mb free.

To find out more, I used the following command ps -A --sort -rss -o comm,pmem,rss | head -n 20 to list my processes that use RAM:

fail2ban-server 35.2 2101952
systemd-journal 22.9 1370060
clamd           16.9 1014312
mysqld           2.8 169508
spamd child      1.5 95288
spamd            1.3 83448
spamd child      1.3 83048
apache2          0.6 41752
apache2          0.6 41444
apache2          0.6 40308
apache2          0.6 40276
apache2          0.6 40156
apache2          0.6 39860
apache2          0.6 39624
apache2          0.6 38696
apache2          0.6 37840
apache2          0.5 32160
apache2          0.3 17912
named            0.2 16016

So I understand right, it seems that the first 3 processes use 75% of the RAM!

I would like to have your opinion on how to optimize this:

1) Are these results normal?

2) Is there a way to fix this? Maybe by clearing the cache?

3) I have heard of the ulimit command, but is it really effective? If I configure ulimit 256 for fail2ban and clamav, won't it make these processes useless?

I did a lot of research but either it did not concern my problem, or the topics dated from 2010-2012 and therefore might not be correct in 2020.

Edit 1 : I don't know what to check for fail2ban and clamav but for journal, I imagine that the configuration file is in /etc/systemd/journald.conf. Here is mine:

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg

Should something be changed in this to limit the use of RAM?

Edit 2 : here is the result of cat /proc/sys/vm/swappiness : 60

cyclone200
  • 125
  • 4
  • Could you add the result of "cat /proc/sys/vm/swappiness" ? – Dom May 31 '20 at 09:27
  • Sure. It is 60. – cyclone200 May 31 '20 at 10:35
  • 1
    Fail2ban is a memory hog. The more jails you have enabled the more memory it uses. The only thing you can do is disable jails you have no need for, or tighten security so they aren't needed. Not much can be done for clamd as it loads a huge db of virus info into memory. You can run clamav as opposed to clamd, it's slower but more memory friendly as it loads db as needed and then unloads. Obvious solution is add more memory :) In my experience your experience is normal. – Admiral Noisy Bottom May 31 '20 at 10:54

2 Answers2

2

I had issue with ClamAV and memory, adding a 4GB swap drive solved the problem.

dd if=/dev/zero of=/media/swap.img bs=1024 count=4M 

mkswap /media/swap.img

etc/fstab

/media/swap.img  none  swap  sw 0  0

And then reboot.

Kline
  • 227
  • 4
  • 13
2

To me, the kernel can not allocate memory as there is no swap. Your swapiness is 60, so the kernel may use swap when 60% of RAM is used. As there is no swap, it failed to allocate. You should set your swappiness to 0 with echo 0 > /proc/sys/vm/swappiness, or/and add some swap space.

Look also to change fail2ban to another port blocker, lighter. I have seen Pyruse in my docs but never test it

Dom
  • 6,628
  • 1
  • 19
  • 24
  • Thank you for your answer. I've just added and activated (swapon) a 1Gb swap. If I keep a swappiness of 60, should I do something to activate it? Since my RAM won't fall under 75%... Maybe reboot the VPS? – cyclone200 Jun 01 '20 at 12:34
  • 1
    As you wasn't enable the swap, it was not used. So the swappiness parameter should be enabled immediately. You can reboot if you want. You will need to render permanent the parameter in /etc/rc.local by example. – Dom Jun 02 '20 at 07:56