OOM killer shut down MySQL although ram usage seems low
Solution 1:
Try increasing vm.min_free_kbytes, this will ensure you have enough free memory when needed. Some(kernel) processes require memory to be immediately available (and cannot wait for the MM to free some) and if its not the kernel can trigger the OOM killer. Don't set to to more than 5% of your total memory, this may also make your system unstable.
If it happens during complete backup, probably the backup takes a lot of memory in buffers/cache. Increasing vm.min_free_kbytes helped me in similar situations where daemon was killed although it didn't use that much.
The way OOM killer works, it kills the process that used most memory lately and sometimes it may be wonky.
Solution 2:
Suggestions for your my.cnf/ini
, [mysqld]
section
key_buffer_size=64M # from 16M to support your ~ 14,000 MyISAM tables
query_cache_size=0 # from 16M to conserve CPU and encourage good coding
innodb_buffer_pool_size=2G # from 128M default to support your 4G DB better
innodb_buffer_pool_instances=8 # from 1 to reduce mutex contention, even w 2G
max_connections=50 # from 151 default until you need more
query_cache_limit=1K # from 4M to conserve RAM and QC will be OFF
query_cache_type=0 # to ensure is OFF
#max_allowed_packet=24M # lead with # for default size of 1M
when you need larger M_A_P, in your SESSION, SET @max_allowed_packet=nnnnnnn;
up to 1 GB and 1GB is the load infile size limit.