Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
I set up a fresh 1GB VPS server instance dedicated solely to MySQL. Everything seems to be working great. However, I noticed that mysqld memory usage quickly grows and sort of peaks out at about 700MB (as expected), but then it slowly “creeps” up over the course of 1-2 days. Then when it reaches about 770MB, the process gets killed by OOM Killer and restarts within a few seconds. It’s not a massive downtime, but I would like it to be stable.
I am using MySQL version 5.7.21. Here are the variables that I changed from default in the my.cnf file, everything else is set to the defaults. The biggest change is an increase memory to the innodb_buffer_pool_size to 512M:
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
sql_mode = "NO_ENGINE_SUBSTITUTION"
innodb_buffer_pool_size = 384M
innodb_log_buffer_size = 2097152
innodb_log_file_size = 20971520
innodb_strict_mode = OFF
join_buffer_size = 1048576
key_buffer_size = 88080384
max_connect_errors = 10000
max_connections = 151
myisam_recover_options = "BACKUP,FORCE"
performance_schema = 0
read_buffer_size = 1048576
slow_query_log = ON
sort_buffer_size = 1048576
sync_binlog = 0
thread_stack = 262144
wait_timeout = 14400
I’m kind of noobish with MySQL administration, so I’m hoping someone with more experience can provide some advice to keeping my MySQL instance a bit more stable on my 1GB instance, OOM Killer strategies and making the database faster/efficient at the same time.
EDIT: I added some extra files for additional information:
SHOW GLOBAL STATUS: https://pastebin.com/SSVEJrQc
SHOW GLOBAL VARIABLES: https://pastebin.com/gV5yGdFR
SHOW ENGINE INNODB STATUS: https://pastebin.com/suHwbpiP
/var/log/mysql/error.log : https://pastebin.com/cRFGrNTp (combined past couple days)
The my.cnf file is shown at the top. I made some changes to it to reduce some of the memory usage, such as dropping the innodb_buffer_pool_size down to 384M instead of 512M. According to "top -c", the memory usage quickly rose to around 550MB and slowly creeped up to about 740M, no crash yet.
Also, the server instance has 1GB of RAM, so I'm not sure why MySQL has to crash at around 770M. It's just a fresh install of Ubuntu 16.04 and MySQL, nothing else at all, no apache or php.
EDIT: I've included more data, I'm running instance on a Dreamhost DreamCompute cloud server:
"top" Results: https://pastebin.com/RNBYMf0b
"df -h" results:
Filesystem Size Used Avail Use% Mounted on
udev 488M 0 488M 0% /dev
tmpfs 100M 11M 89M 11% /run
/dev/vda1 78G 22G 56G 29% /
tmpfs 497M 0 497M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 497M 0 497M 0% /sys/fs/cgroup
tmpfs 100M 0 100M 0% /run/user/1000
"iostat -x": https://pastebin.com/xUNu7fEi
"mysqltuner": https://pastebin.com/pVC3kN1C
I'm seeing a lot of "tmpfs" directories (using RAM)? Is there anything that should or shouldn't be on this list? Also, I've just now updated the my.cnf with the values Wilson Hauck provided and will restart mysqld.
Edit: Regarding "ulimit", after reading more about it, I edited /etc/security/limits.conf and added the following: "* - nofile 40000" . Now when I use "sudo sh -c "ulimit -n", it shows 40000 instead of 1024.
The "iostat -x" and "mysqltuner" reports were created right after I restarted MySQL because they wouldn't install due to "not enough memory". Thanks Wilson for the mysqltuner suggestion, that looks like a great program.
UPDATE: 2/25/2018:
With all of the recommended settings set, I had mysql again crash about 10 hours ago. Here are the details from syslog:
Feb 25 09:41:52 database kernel: [739566.195215] snapd invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=-900
Feb 25 09:41:52 database kernel: [739566.195276] snapd cpuset=/ mems_allowed=0
Feb 25 09:41:52 database kernel: [739566.195310] CPU: 0 PID: 1228 Comm: snapd Not tainted 4.4.0-112-generic #135-Ubuntu
Feb 25 09:41:52 database kernel: [739566.195311] Hardware name: OpenStack Foundation OpenStack Nova, BIOS Bochs 01/01/2011
Feb 25 09:41:52 database kernel: [739566.195313] 0000000000000286 245c0a16fc0af5b0 ffff8800000839d8 ffffffff813fc233
Feb 25 09:41:52 database kernel: [739566.195317] ffff880000083b90 ffff88003ae39c00 ffff880000083a48 ffffffff8120dafe
Feb 25 09:41:52 database kernel: [739566.195319] ffffffff81cd8367 0000000000000000 ffffffff81e6b1a0 0000000000000206
Feb 25 09:41:52 database kernel: [739566.195321] Call Trace:
Feb 25 09:41:52 database kernel: [739566.195361] [<ffffffff813fc233>] dump_stack+0x63/0x90
Feb 25 09:41:52 database kernel: [739566.195375] [<ffffffff8120dafe>] dump_header+0x5a/0x1c5
Feb 25 09:41:52 database kernel: [739566.195383] [<ffffffff811946a2>] oom_kill_process+0x202/0x3c0
Feb 25 09:41:52 database kernel: [739566.195385] [<ffffffff81194ac9>] out_of_memory+0x219/0x460
Feb 25 09:41:52 database kernel: [739566.195394] [<ffffffff8119aad5>] __alloc_pages_slowpath.constprop.88+0x965/0xb00
Feb 25 09:41:52 database kernel: [739566.195396] [<ffffffff8119aef6>] __alloc_pages_nodemask+0x286/0x2a0
Feb 25 09:41:52 database kernel: [739566.195404] [<ffffffff811e483c>] alloc_pages_current+0x8c/0x110
Feb 25 09:41:52 database kernel: [739566.195406] [<ffffffff81190c6b>] __page_cache_alloc+0xab/0xc0
Feb 25 09:41:52 database kernel: [739566.195407] [<ffffffff8119317a>] filemap_fault+0x14a/0x3f0
Feb 25 09:41:52 database kernel: [739566.195418] [<ffffffff812a5d56>] ext4_filemap_fault+0x36/0x50
Feb 25 09:41:52 database kernel: [739566.195419] [<ffffffff811bfe70>] __do_fault+0x50/0xe0
Feb 25 09:41:52 database kernel: [739566.195421] [<ffffffff811c39c2>] handle_mm_fault+0xfa2/0x1820
Feb 25 09:41:52 database kernel: [739566.195433] [<ffffffff810bbc6c>] ? set_next_entity+0x9c/0xb0
Feb 25 09:41:52 database kernel: [739566.195443] [<ffffffff8106b687>] __do_page_fault+0x197/0x400
Feb 25 09:41:52 database kernel: [739566.195445] [<ffffffff8106b957>] trace_do_page_fault+0x37/0xe0
Feb 25 09:41:52 database kernel: [739566.195450] [<ffffffff81063f29>] do_async_page_fault+0x19/0x70
Feb 25 09:41:52 database kernel: [739566.195464] [<ffffffff81849af8>] async_page_fault+0x28/0x30
Feb 25 09:41:52 database kernel: [739566.195465] Mem-Info:
Feb 25 09:41:52 database kernel: [739566.195470] active_anon:220242 inactive_anon:1399 isolated_anon:0
Feb 25 09:41:52 database kernel: [739566.195470] active_file:799 inactive_file:1712 isolated_file:0
Feb 25 09:41:52 database kernel: [739566.195470] unevictable:913 dirty:1 writeback:0 unstable:0
Feb 25 09:41:52 database kernel: [739566.195470] slab_reclaimable:5664 slab_unreclaimable:3906
Feb 25 09:41:52 database kernel: [739566.195470] mapped:1931 shmem:2691 pagetables:1544 bounce:0
Feb 25 09:41:52 database kernel: [739566.195470] free:12712 free_pcp:113 free_cma:0
Feb 25 09:41:52 database kernel: [739566.195473] Node 0 DMA free:4548kB min:716kB low:892kB high:1072kB active_anon:5548kB inactive_anon:12kB active_file:1068kB inactive_file:1968kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:4kB writeback:0kB mapped:808kB shmem:364kB slab_reclaimable:220kB slab_unreclaimable:500kB kernel_stack:368kB pagetables:936kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:19320 all_unreclaimable? yes
Feb 25 09:41:52 database kernel: [739566.195491] lowmem_reserve[]: 0 958 958 958 958
Feb 25 09:41:52 database kernel: [739566.195495] Node 0 DMA32 free:46300kB min:44336kB low:55420kB high:66504kB active_anon:875420kB inactive_anon:5584kB active_file:2128kB inactive_file:4880kB unevictable:3652kB isolated(anon):0kB isolated(file):0kB present:1032184kB managed:1000192kB mlocked:3652kB dirty:0kB writeback:0kB mapped:6916kB shmem:10400kB slab_reclaimable:22436kB slab_unreclaimable:15124kB kernel_stack:3376kB pagetables:5240kB unstable:0kB bounce:0kB free_pcp:452kB local_pcp:452kB free_cma:0kB writeback_tmp:0kB pages_scanned:42084 all_unreclaimable? yes
Feb 25 09:41:52 database kernel: [739566.195502] lowmem_reserve[]: 0 0 0 0 0
Feb 25 09:41:52 database kernel: [739566.195504] Node 0 DMA: 1*4kB (U) 6*8kB (UME) 81*16kB (UME) 32*32kB (UM) 8*64kB (ME) 7*128kB (ME) 3*256kB (UM) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4548kB
Feb 25 09:41:52 database kernel: [739566.195514] Node 0 DMA32: 107*4kB (MEH) 240*8kB (ME) 249*16kB (UMEH) 141*32kB (UMEH) 108*64kB (UMEH) 59*128kB (UMEH) 20*256kB (UMEH) 13*512kB (UME) 9*1024kB (UMH) 0*2048kB 0*4096kB = 46300kB
Feb 25 09:41:52 database kernel: [739566.195526] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
Feb 25 09:41:52 database kernel: [739566.195560] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Feb 25 09:41:52 database kernel: [739566.195561] 5817 total pagecache pages
Feb 25 09:41:52 database kernel: [739566.195576] 0 pages in swap cache
Feb 25 09:41:52 database kernel: [739566.195581] Swap cache stats: add 0, delete 0, find 0/0
Feb 25 09:41:52 database kernel: [739566.195582] Free swap = 0kB
Feb 25 09:41:52 database kernel: [739566.195583] Total swap = 0kB
Feb 25 09:41:52 database kernel: [739566.195584] 262044 pages RAM
Feb 25 09:41:52 database kernel: [739566.195585] 0 pages HighMem/MovableOnly
Feb 25 09:41:52 database kernel: [739566.195585] 8019 pages reserved
Feb 25 09:41:52 database kernel: [739566.195586] 0 pages cma reserved
Feb 25 09:41:52 database kernel: [739566.195587] 0 pages hwpoisoned
Feb 25 09:41:52 database kernel: [739566.195588] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
Feb 25 09:41:52 database kernel: [739566.195593] [ 348] 0 348 9237 1199 21 3 0 0 systemd-journal
Feb 25 09:41:52 database kernel: [739566.195595] [ 451] 0 451 25742 46 17 3 0 0 lvmetad
Feb 25 09:41:52 database kernel: [739566.195597] [ 452] 0 452 10744 376 24 3 0 -1000 systemd-udevd
Feb 25 09:41:52 database kernel: [739566.195599] [ 550] 100 550 25081 61 19 3 0 0 systemd-timesyn
Feb 25 09:41:52 database kernel: [739566.195601] [ 940] 0 940 4030 222 11 3 0 0 dhclient
Feb 25 09:41:52 database kernel: [739566.195603] [ 1054] 0 1054 1305 29 8 3 0 0 iscsid
Feb 25 09:41:52 database kernel: [739566.195604] [ 1055] 0 1055 1430 877 8 3 0 -17 iscsid
Feb 25 09:41:52 database kernel: [739566.195606] [ 1063] 0 1063 68647 1056 37 3 0 0 accounts-daemon
Feb 25 09:41:52 database kernel: [739566.195608] [ 1072] 0 1072 6932 491 19 3 0 0 cron
Feb 25 09:41:52 database kernel: [739566.195609] [ 1078] 0 1078 6511 337 18 3 0 0 atd
Feb 25 09:41:52 database kernel: [739566.195611] [ 1091] 0 1091 1099 300 8 3 0 0 acpid
Feb 25 09:41:52 database kernel: [739566.195613] [ 1094] 0 1094 7136 99 19 3 0 0 systemd-logind
Feb 25 09:41:52 database kernel: [739566.195614] [ 1099] 0 1099 16377 273 35 3 0 -1000 sshd
Feb 25 09:41:52 database kernel: [739566.195616] [ 1101] 104 1101 64098 348 27 3 0 0 rsyslogd
Feb 25 09:41:52 database kernel: [739566.195618] [ 1105] 107 1105 10722 380 27 3 0 -900 dbus-daemon
Feb 25 09:41:52 database kernel: [739566.195619] [ 1113] 0 1113 70365 2590 31 6 0 -900 snapd
Feb 25 09:41:52 database kernel: [739566.195621] [ 1114] 0 1114 158952 1017 31 4 0 0 lxcfs
Feb 25 09:41:52 database kernel: [739566.195623] [ 1150] 0 1150 3343 36 11 3 0 0 mdadm
Feb 25 09:41:52 database kernel: [739566.195624] [ 1159] 0 1159 69294 181 38 3 0 0 polkitd
Feb 25 09:41:52 database kernel: [739566.195626] [ 1203] 0 1203 3618 374 12 3 0 0 agetty
Feb 25 09:41:52 database kernel: [739566.195627] [13137] 0 13137 3664 356 11 3 0 0 agetty
Feb 25 09:41:52 database kernel: [739566.195629] [13141] 0 13141 3664 329 12 3 0 0 agetty
Feb 25 09:41:52 database kernel: [739566.195631] [ 4475] 112 4475 345228 190282 441 4 0 0 mysqld
Feb 25 09:41:52 database kernel: [739566.195635] [28991] 0 28991 1126 141 8 3 0 0 apt.systemd.dai
Feb 25 09:41:52 database kernel: [739566.195638] [28998] 0 28998 1126 383 8 3 0 0 apt.systemd.dai
Feb 25 09:41:52 database kernel: [739566.195640] [29036] 0 29036 11324 1282 27 3 0 0 apt-get
Feb 25 09:41:52 database kernel: [739566.195641] [29217] 0 29217 11324 867 23 3 0 0 apt-get
Feb 25 09:41:52 database kernel: [739566.195643] [29220] 0 29220 1126 157 8 3 0 0 sh
Feb 25 09:41:52 database kernel: [739566.195645] [29221] 0 29221 1126 367 9 3 0 0 update-motd-upd
Feb 25 09:41:52 database kernel: [739566.195646] [29235] 0 29235 40967 16609 84 3 0 0 apt-check
Feb 25 09:41:52 database kernel: [739566.195648] [29570] 0 29570 12235 358 28 3 0 0 cron
Feb 25 09:41:52 database kernel: [739566.195649] [29571] 0 29571 1126 144 8 3 0 0 sh
Feb 25 09:41:52 database kernel: [739566.195651] [29572] 0 29572 2809 278 10 3 0 0 bash
Feb 25 09:41:52 database kernel: [739566.195653] [29579] 0 29579 12235 290 28 3 0 0 cron
Feb 25 09:41:52 database kernel: [739566.195654] [29580] 0 29580 1126 163 7 3 0 0 sh
Feb 25 09:41:52 database kernel: [739566.195656] [29581] 0 29581 2809 91 9 3 0 0 bash
Feb 25 09:41:52 database kernel: [739566.195658] [29582] 0 29582 14775 135 30 3 0 0 sshd
Feb 25 09:41:52 database kernel: [739566.195659] [29584] 0 29584 12235 358 28 3 0 0 cron
Feb 25 09:41:52 database kernel: [739566.195661] [29589] 0 29589 14775 134 32 3 0 0 sshd
Feb 25 09:41:52 database kernel: [739566.195662] [29592] 0 29592 12855 431 30 3 0 0 sudo
Feb 25 09:41:52 database kernel: [739566.195664] [29597] 0 29597 1126 70 8 3 0 0 sh
Feb 25 09:41:52 database kernel: [739566.195665] [29598] 0 29598 2809 124 9 3 0 0 bash
Feb 25 09:41:52 database kernel: [739566.195667] [29602] 0 29602 12235 357 28 3 0 0 cron
Feb 25 09:41:52 database kernel: [739566.195668] [29603] 0 29603 1126 92 8 3 0 0 sh
Feb 25 09:41:52 database kernel: [739566.195670] [29604] 0 29604 2809 321 10 3 0 0 bash
Feb 25 09:41:52 database kernel: [739566.195672] [29615] 0 29615 5787 36 13 3 0 0 systemctl
Feb 25 09:41:52 database kernel: [739566.195673] [29620] 0 29620 12235 276 28 3 0 0 cron
Feb 25 09:41:52 database kernel: [739566.195675] [29621] 0 29621 11236 413 26 3 0 0 sudo
Feb 25 09:41:52 database kernel: [739566.195677] [29623] 0 29623 1126 139 8 3 0 0 sh
Feb 25 09:41:52 database kernel: [739566.195678] [29624] 0 29624 2807 234 10 3 0 0 bash
Feb 25 09:41:52 database kernel: [739566.195680] [29628] 0 29628 14775 75 30 3 0 0 sshd
Feb 25 09:41:52 database kernel: [739566.195681] [29629] 0 29629 12235 476 28 3 0 0 cron
Feb 25 09:41:52 database kernel: [739566.195683] [29641] 0 29641 6945 111 18 3 0 0 sudo
Feb 25 09:41:52 database kernel: [739566.195684] [29642] 0 29642 6945 87 18 3 0 0 sudo
Feb 25 09:41:52 database kernel: [739566.195686] [29643] 0 29643 1126 152 8 3 0 0 sh
Feb 25 09:41:52 database kernel: [739566.195687] [29644] 0 29644 345 1 5 3 0 0 bash
Feb 25 09:41:52 database kernel: [739566.195689] Out of memory: Kill process 4475 (mysqld) score 750 or sacrifice child
Feb 25 09:41:52 database kernel: [739566.197374] Killed process 4475 (mysqld) total-vm:1380912kB, anon-rss:761128kB, file-rss:0kB
Feb 25 09:41:53 database kernel: [739566.658202] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20807 DF PROTO=TCP SPT=54168 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739566.658214] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20808 DF PROTO=TCP SPT=49412 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739566.658291] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20809 DF PROTO=TCP SPT=54293 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739566.666146] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20810 DF PROTO=TCP SPT=53588 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739566.666160] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20811 DF PROTO=TCP SPT=53612 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database systemd[1]: Started MySQL Community Server.
Feb 25 09:41:53 database CRON[29570]: (CRON) info (No MTA installed, discarding output)
Feb 25 09:41:53 database systemd[1]: mysql.service: Main process exited, code=killed, status=9/KILL
Feb 25 09:41:53 database systemd[1]: mysql.service: Unit entered failed state.
Feb 25 09:41:53 database systemd[1]: mysql.service: Failed with result 'signal'.
Feb 25 09:41:53 database systemd[1]: mysql.service: Service hold-off time over, scheduling restart.
Feb 25 09:41:53 database systemd[1]: Stopped MySQL Community Server.
Feb 25 09:41:53 database systemd[1]: Starting MySQL Community Server...
Feb 25 09:41:53 database kernel: [739567.046536] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=42 ID=21475 DF PROTO=TCP SPT=37118 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739567.066187] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20869 DF PROTO=TCP SPT=54293 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739567.066313] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20870 DF PROTO=TCP SPT=49412 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739567.066324] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.*** DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20871 DF PROTO=TCP SPT=54168 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:53 database kernel: [739567.082221] [UFW BLOCK] IN=ens3 OUT= MAC=fa:16:3e:bc:28:e3:44:f4:77:a7:c0:20:08:00 SRC=***.***.***.***DST=***.***.***.*** LEN=40 TOS=0x00 PREC=0x00 TTL=61 ID=20873 DF PROTO=TCP SPT=53612 DPT=3306 WINDOW=0 RES=0x00 RST URGP=0
Feb 25 09:41:54 database kernel: [739567.524532] audit: type=1400 audit(1519551714.232:296): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/29710/status" pid=29710 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=112 ouid=112
Feb 25 09:41:54 database kernel: [739567.524603] audit: type=1400 audit(1519551714.232:297): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=29710 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=112 ouid=0
Feb 25 09:41:54 database kernel: [739567.524670] audit: type=1400 audit(1519551714.232:298): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/29710/status" pid=29710 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=112 ouid=112
Feb 25 09:41:56 database systemd[1]: Started MySQL Community Server.
According to MySQLtuner, it says: "Maximum possible memory usage: 664.8M (66.99% of installed RAM)", so it must be exceeding this somehow.
Suggestions to consider for your my.cnf/ini [mysqld] section,
ulimit -n 40000 # at your Linux command prompt to raise n open files limit
table_open_cache=10000 # from 2000 to support 1M+ opened in 2 days
table_definition_cache=2500 # from default to support 2000+ opened in 2 days
open_files_limit=30000 # from 5000 to support 900,000 + opened in 2 days
max_connections=50 # from 151 to support 17 max_used_connections
read_rnd_buffer_size=128K # from 256k default to reduce RD RPS
innodb_change_buffer_max_size=15 # from 25% of innodb_buffer_pool_size 1% used
innodb_log_buffer_size=12M # from 2M to cover 30 minutes of log
innodb_log_file_size=120M # from ~ 20M to cover a few days
#max_allowed_packet=16M # lead with # for default of 1M m_a_p
if you need more than 1M, in your SESSION
SET #max_allowed_packet=nnnnnnnn; up to 1G and 1G is the LIMIT.
query_cache_size=0 # from 16M - it is already OFF, do not waste RAM on it
query_cache_limit=1K # from 1M to conserve more RAM
query_cache_min_res_unit=512 # from 4096 to store more small results, if ever used
innodb_buffer_pool_instances=8 # from 1 to minimize mutex contention
will be fine with you UNDER 1G per instance of innodb_buffer_pool_size
innodb_lru_scan_depth=128 # from 1024 which is causing page_cleaner warnings
innodb_page_cleaners=64 # from 1 to auto follow = innodb_buffer_pool_instances
thread_cache_size=50 # from 8 default to support 17 max_used with room for growth.
from my perspective, backup your current my.cnf/ini and implement all. There are more opportunities for another day.
Could we use Stack Overflow's chat next week ?
Your query_cache_size is 52428800 = 50M
innodb_buffer_pool_size = 512M
key_buffer_size = 88080384 = 84M
That's already ~650M, which leaves MySQL about 50M for 'other stuff'.
If you tweak down some of these settings, chances are that you can stay below 700M. Unless your version of MySQL really has a memory leak.
Try reducing some of these numbers by another 50M in total.
Bonus:
Just found this calculator: http://www.mysqlcalculator.com/. Might help you figure this out more accurately. Can't speak to how accurate this tool is though
To answer part of your question:
Also, the server instance has 1GB of RAM, so I'm not sure why MySQL has to crash at around 770M. It's just a fresh install of Ubuntu 16.04 and MySQL, nothing else at all, no apache or php.
A server doesn't have "nothing else at all" even if you don't install anything else yourself, there's always background stuff going on as well, and whatever your VPS image includes. You can use top (or if available my preferred tool, htop) to see what's running and what's using memory.
In the OOM kill log, for instance, apt-check has an rss size of 16848, meaning it's taking another 70GB of RAM by itself (see this answer on OOM kiler logs - the numbers indicate 4kB blocks). Additionally, many of the system "directories" such as /tmp are actually stored in RAM rather than on disk. You can see if that's the caes on your machine by running df -h - anything listed with tmpfs as its filesystem is stored in RAM, and if it has space being used, is using RAM as well.
Put various things together, and it's plausible that various system processes can take a decent chunk of that RAM overhead, even without any other processes you specifically installed.
Related
missing resource group when clone node, i see noti below.
Failed Resource Actions:
DrbdData_monitor_60000 on node3.cacticluster 'master' (8): call=74, status=complete, exitreason='',
last-rc-change='Wed Feb 1 22:31:53 2023', queued=0ms, exec=0ms
DRBD Status in connecting.... state
I tried several ways but no success, these 2 node clusters are cloned by me, any solution, thanks a lot!
Log Drbd messages
Feb 7 19:11:47 node4 kernel: drbd cacti: conn( WFConnection -> WFReportParams )
Feb 7 19:11:47 node4 kernel: drbd cacti: Starting ack_recv thread (from drbd_r_cacti [29736])
Feb 7 19:11:47 node4 kernel: block drbd0: drbd_sync_handshake:
Feb 7 19:11:47 node4 kernel: block drbd0: self FD6598A8213A2C93:600465D29E804184:077527C5351B305A:077427C5351B305A bits:339 flags:0
Feb 7 19:11:47 node4 kernel: block drbd0: peer 1C4C9191DB7E2555:600465D29E804185:077527C5351B305A:077427C5351B305A bits:164 flags:0
Feb 7 19:11:47 node4 kernel: block drbd0: uuid_compare()=100 by rule 90
Feb 7 19:11:47 node4 kernel: block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0
Feb 7 19:11:48 node4 kernel: block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0 exit code 0 (0x0)
Feb 7 19:11:48 node4 kernel: block drbd0: Split-Brain detected but unresolved, dropping connection!
Feb 7 19:11:48 node4 kernel: block drbd0: helper command: /sbin/drbdadm split-brain minor-0
Feb 7 19:11:48 node4 kernel: block drbd0: helper command: /sbin/drbdadm split-brain minor-0 exit code 0 (0x0)
Feb 7 19:11:48 node4 kernel: drbd cacti: conn( WFReportParams -> Disconnecting )
Feb 7 19:11:48 node4 kernel: drbd cacti: error receiving ReportState, e: -5 l: 0!
Feb 7 19:11:48 node4 kernel: drbd cacti: ack_receiver terminated
Feb 7 19:11:48 node4 kernel: drbd cacti: Terminating drbd_a_cacti
Feb 7 19:11:48 node4 kernel: drbd cacti: Connection closed
Feb 7 19:11:48 node4 kernel: drbd cacti: conn( Disconnecting -> StandAlone )
Feb 7 19:11:48 node4 kernel: drbd cacti: receiver terminated
Feb 7 19:11:48 node4 kernel: drbd cacti: Terminating drbd_r_cacti
Feb 7 19:11:48 node4 crmd[1459]: notice: Initiating stop operation DrbdFS_stop_0 locally on node4.cacticluster
Feb 7 19:11:48 node4 crmd[1459]: notice: Initiating stop operation DrbdFS_stop_0 on node3.cacticluster
Feb 7 19:11:48 node4 Filesystem(DrbdFS)[45317]: INFO: Running stop for /dev/drbd0 on /mnt/DATA
Feb 7 19:11:48 node4 Filesystem(DrbdFS)[45317]: INFO: Trying to unmount /mnt/DATA
Feb 7 19:11:48 node4 Filesystem(DrbdFS)[45317]: INFO: unmounted /mnt/DATA successfully
Feb 7 19:11:48 node4 crmd[1459]: notice: Result of stop operation for DrbdFS on node4.cacticluster: 0 (ok)
Feb 7 19:11:49 node4 crmd[1459]: notice: Initiating start operation DrbdFS_start_0 on node3.cacticluster
Feb 7 19:11:49 node4 crmd[1459]: notice: Initiating demote operation DrbdData_demote_0 locally on node4.cacticluster
Feb 7 19:11:50 node4 kernel: block drbd0: role( Primary -> Secondary )
Feb 7 19:11:50 node4 kernel: block drbd0: 1356 KB (339 bits) marked out-of-sync by on disk bit-map.
OK, Basically I am echo'ing a line to a CSV comma delimited.
This is what is happening:
This is the output:
Computer1 Fri 08/04/2017 13:20 110 917 340 907
Computer2 Fri 08/04/2017 13:21 110 917 435 852
Computer3 Fri 08/04/2017 12:39 180 92 916
Computer4 Fri 08/04/2017 12:35 232 353 720
I want:
Computer1 Fri 08/04/2017 13:20 110 917 340 907
Computer2 Fri 08/04/2017 13:21 110 917 435 852
Computer3 Fri 08/04/2017 12:39 180 92 916
Computer4 Fri 08/04/2017 12:35 232 353 720
I want to lead with a comma for every 3rd right-justified character, so the values line up correctly.
I am getting size of folders to calculate current folder size, then again weekly to determine growth.
The part I am struggling with is this:
for /f "tokens=1-2 delims= " %%a in ('C:\du64.EXE -v -q -nobanner C:\Temp^|find "Size:"') do SET DISKSIZE=%%b
ECHO. "%DISKSIZE%" **
(This will give a value containing commas. ex 12,345,678,910)
ECHO. %COMPUTERNAME%,%DATE%,%TIME:~0,5%,%DISKSIZE%,%PROCESSOR_ARCHITECTURE%>> "C:\DUOutput.CSV"
...set "DISKSIZE= %%b"
echo %disksize:~-15%
No idea why you're getting 92 in your data, nor what lead with a comma for every 3rd right-justified character means.
see set /?|more from the prompt for documentation. I've no idea how many spaces I put before %%b - so long as there is at least a string of 15, it should be OK.
I tried to log mysql statements , executed by jdbc , hoping to see strings containing declare some cursor or fetch some cursor. But there was not.
Are there any ways to see them?
PS i set variables in mysql as following:
SET GLOBAL log_output="FILE"
SET GLOBAL general_log_file="Path/File"
SET GLOBAL general_log='ON'
Try this.
Add 'logger' and 'profileSQL' to the jdbc url:
&logger=com.mysql.jdbc.log.Slf4JLogger&profileSQL=true
Then you will get the SQL statement below:
2016-01-14 10:09:43 INFO MySQL - FETCH created: Thu Jan 14 10:09:43 CST 2016 duration: 1 connection: 19130945 statement: 999 resultset: 0
2016-01-14 10:09:43 INFO MySQL - QUERY created: Thu Jan 14 10:09:43 CST 2016 duration: 1 connection: 19130945 statement: 999 resultset: 0 message: SET sql_mode='NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES'
2016-01-14 10:09:43 INFO MySQL - FETCH created: Thu Jan 14 10:09:43 CST 2016 duration: 1 connection: 19130945 statement: 999 resultset: 0
2016-01-14 10:09:43 INFO MySQL - QUERY created: Thu Jan 14 10:09:43 CST 2016 duration: 2 connection: 19130945 statement: 13 resultset: 17 message: select 1
2016-01-14 10:09:43 INFO MySQL - FETCH created: Thu Jan 14 10:09:43 CST 2016 duration: 0 connection: 19130945 statement: 13 resultset: 17
2016-01-14 10:09:43 INFO MySQL - QUERY created: Thu Jan 14 10:09:43 CST 2016 duration: 1 connection: 19130945 statement: 15 resultset: 18 message: select ##session.tx_read_only
2016-01-14 10:09:43 INFO MySQL - FETCH created: Thu Jan 14 10:09:43 CST 2016 duration: 0 connection: 19130945 statement: 15 resultset: 18
2016-01-14 10:09:43 INFO MySQL - QUERY created: Thu Jan 14 10:09:43 CST 2016 duration: 2 connection: 19130945 statement: 14 resultset: 0 message: update sequence set seq=seq+incr where name='demo' and seq=4602
2016-01-14 10:09:43 INFO MySQL - FETCH created: Thu Jan 14 10:09:43 CST 2016 duration: 0 connection: 19130945 statement: 14 resultset: 0
The default logger is:
com.mysql.jdbc.log.StandardLogger
Mysql jdbc property list: https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html
While merging index with delta on Sphinx, I got this error:
~: /usr/local/bin/indexer --merge myindex myindexDelta --rotate;
Sphinx 2.0.6-release (r3473)
Copyright (c) 2001-2012, Andrew Aksyonoff
Copyright (c) 2008-2012, Sphinx Technologies Inc ( http://sphinxsearch.com )
using config file '/usr/local/etc/sphinx.conf'...
merging index 'myindexDelta' into index 'myindex'...
read 414.6 of 414.6 MB, 100.0% done
FATAL: failed to merge index 'myindexDelta' into index 'myindex': failed to open /server/sphinx/data/myindex.sps: No such file or directory
My configuration on sphinx.conf is as following
source myindex
{
type = mysql
sql_host = localhost
sql_user = db
sql_pass =
sql_db = db
sql_query_pre = SET SESSION query_cache_type=OFF
sql_query_pre = REPLACE INTO sph_counter SELECT 1, MAX(id) FROM mytable
sql_query_pre = SET NAMES utf8
sql_query = \
SELECT id,title FROM mytable \
WHERE id<=( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
sql_ranged_throttle = 0
}
source myindexDelta : myindex
{
sql_query_pre = SET SESSION query_cache_type=OFF
sql_query_pre = SET NAMES utf8
sql_query = \
SELECT id,title FROM mytable \
WHERE id > ( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
}
index myindex
{
source = myindex
path = /server/sphinx/data/myindex
min_word_len = 3
min_infix_len = 0
}
index myindexDelta : myindex
{
source = myindexDelta
path = /server/sphinx/data/myindexDelta
min_word_len = 3
min_infix_len = 0
}
indexes files listings with permissions:
~: ls -lh /server/sphinx/data/
-rw-r--r-- 1 root root 0 Nov 11 21:40 myindexDelta.spa
-rw-r--r-- 1 root root 290K Nov 11 21:40 myindexDelta.spd
-rw-r--r-- 1 root root 328 Nov 11 21:40 myindexDelta.sph
-rw-r--r-- 1 root root 106K Nov 11 21:40 myindexDelta.spi
-rw-r--r-- 1 root root 0 Nov 11 21:40 myindexDelta.spk
-rw------- 1 root root 0 Nov 11 21:40 myindexDelta.spl
-rw-r--r-- 1 root root 0 Nov 11 21:40 myindexDelta.spm
-rw-r--r-- 1 root root 223K Nov 11 21:40 myindexDelta.spp
-rw-r--r-- 1 root root 1 Nov 11 21:40 myindexDelta.sps
-rw-r--r-- 1 root root 0 Jul 3 21:17 myindex.spa
-rw-r--r-- 1 root root 7.0G Jul 3 23:54 myindex.spd
-rw-r--r-- 1 root root 290 Jul 3 23:54 myindex.sph
-rw-r--r-- 1 root root 397M Jul 3 23:54 myindex.spi
-rw-r--r-- 1 root root 0 Jul 3 23:54 myindex.spk
-rw------- 1 root root 0 Nov 11 21:08 myindex.spl
-rw-r--r-- 1 root root 0 Jul 3 21:17 myindex.spm
-rw-r--r-- 1 root root 9.2G Jul 3 23:54 myindex.spp
I am sure the code explains everything, adding description is not necessary.
I'm guessing that the original 'myindex' was made by a different version of sphinx. (ie dont think 2.0.6-release would of been available in July)
And somewhere in that version update, the requirement for a .sps file has changed - the new version requires it, whereas the old doesnt. You have no string attributes hence why the file contains no data in the delta.
I would suggest either rebuilding myindex with your current version of indexer - so they versions are identical.
Or maybe you could try copying myindexDelta.sps to myindex.sps. It contains no data (1 dummy byte!) so it shouldn't corrupt anything. Would only need to do this once.
I am running a EC2 small instance as my production server. It has 1.7G memory. I noticed it uses almost all memory. However when I check top output, it looks like that only 30% is actually used. Did I misread the top output?
Here is the top output (sorted by %MEM)
top - 21:33:15 up 141 days, 9:39, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 81 total, 2 running, 79 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1747660k total, 1733580k used, 14080k free, 224144k buffers
Swap: 917496k total, 132k used, 917364k free, 1144808k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11664 mysql 15 0 794m 83m 5020 S 0.0 4.9 0:17.34 mysqld
12845 nobody 25 0 52416 38m 3200 S 0.0 2.3 0:02.10 ruby1.8
12847 nobody 16 0 52704 38m 2068 S 0.0 2.2 0:02.08 ruby1.8
12023 www-data 15 0 37692 10m 4164 S 0.0 0.6 0:01.28 apache2
11979 www-data 15 0 37660 10m 4172 S 0.0 0.6 0:01.24 apache2
12020 www-data 15 0 37708 10m 4120 S 0.0 0.6 0:01.17 apache2
12263 www-data 15 0 37708 10m 4176 S 0.0 0.6 0:00.83 apache2
11989 www-data 15 0 37720 10m 4024 S 0.0 0.6 0:01.28 apache2
12014 www-data 15 0 37468 10m 4172 S 0.0 0.6 0:01.17 apache2
12021 www-data 15 0 37652 10m 3992 S 0.0 0.6 0:01.25 apache2
12054 www-data 15 0 37480 10m 4176 S 0.0 0.6 0:01.33 apache2
11990 www-data 15 0 37448 10m 4188 S 0.0 0.6 0:01.16 apache2
12024 www-data 16 0 37416 10m 4172 S 0.0 0.6 0:01.00 apache2
11991 www-data 15 0 37432 10m 4148 S 0.0 0.6 0:01.24 apache2
11984 www-data 15 0 37444 9.8m 3972 S 0.0 0.6 0:01.33 apache2
11985 www-data 15 0 37444 9.8m 3948 S 0.0 0.6 0:01.18 apache2
11982 www-data 15 0 37408 9.8m 3968 S 0.0 0.6 0:01.12 apache2
12013 www-data 17 0 37432 9.8m 4152 S 0.0 0.6 0:01.19 apache2
12052 www-data 15 0 37176 9.8m 4180 S 0.0 0.6 0:01.29 apache2
11981 www-data 15 0 37172 9.8m 4168 S 0.0 0.6 0:01.40 apache2
12395 www-data 15 0 37420 9988 3972 S 0.0 0.6 0:00.72 apache2
12015 www-data 15 0 37412 9972 3900 S 0.0 0.6 0:01.31 apache2
11987 www-data 15 0 37160 9956 4136 S 0.0 0.6 0:01.22 apache2
12022 www-data 15 0 37140 9900 4140 S 0.0 0.6 0:01.20 apache2
12051 www-data 15 0 37216 9848 3976 S 0.0 0.6 0:01.31 apache2
11978 www-data 18 0 36948 9784 4180 S 0.0 0.6 0:01.08 apache2
11975 www-data 15 0 37140 9772 3972 S 0.0 0.6 0:01.49 apache2
12019 www-data 15 0 37148 9752 3944 S 0.0 0.6 0:01.08 apache2
11970 www-data 15 0 36920 9736 4160 S 0.0 0.6 0:01.25 apache2
11974 www-data 15 0 36848 9656 4148 S 0.0 0.6 0:01.53 apache2
11973 www-data 15 0 36924 9552 3972 S 0.0 0.5 0:01.19 apache2
28622 root 18 0 35232 9232 5592 S 0.0 0.5 0:00.30 apache2
11969 www-data 15 0 36340 9132 4136 S 0.0 0.5 0:01.51 apache2
12018 www-data 19 0 36332 9124 4136 S 0.0 0.5 0:01.32 apache2
11972 www-data 15 0 36320 8968 3988 S 0.0 0.5 0:01.33 apache2
12012 www-data 15 0 35796 8600 4144 S 0.0 0.5 0:01.11 apache2
11965 root 15 0 17356 7552 1644 S 0.0 0.4 0:00.13 ruby1.8
12848 root 15 0 8384 2744 2164 R 0.0 0.2 0:00.12 sshd
12762 root 15 0 8384 2724 2164 S 0.0 0.2 0:00.01 sshd
11302 postfix 18 0 6184 2576 1880 S 0.0 0.1 0:00.02 tlsmgr
11964 root 16 0 8188 2248 1492 S 0.0 0.1 0:00.06 ApplicationPool
23997 postfix 22 0 5856 1852 1488 S 0.0 0.1 0:00.22 qmgr
12850 root 15 0 4408 1848 1436 S 0.0 0.1 0:00.00 bash
12764 root 25 0 4396 1800 1400 S 0.0 0.1 0:00.00 bash
23996 root 15 0 5804 1780 1428 S 0.0 0.1 0:01.01 master
13036 postfix 17 0 5812 1684 1356 S 0.0 0.1 0:00.00 pickup
1051 klog 18 0 2884 1676 436 S 0.0 0.1 0:00.04 klogd
13035 root 15 0 2468 1164 916 R 0.0 0.1 0:00.01 top
5841 nobody 15 0 2652 1120 684 S 0.0 0.1 0:00.50 memcached
11509 root 15 0 5456 1068 676 S 0.0 0.1 0:00.00 sshd
1163 root 18 0 3560 1060 872 S 0.0 0.1 0:01.46 cron
1 root 18 0 2032 840 580 S 0.0 0.0 0:04.20 init
4070 syslog 18 0 2056 732 568 S 0.0 0.0 7:25.48 syslogd
908 root 16 -2 2292 656 528 S 0.0 0.0 0:00.06 dhclient3
The 'used' count includes filesystem cache and kernel buffers. The cached memory can be free'd when an application requires more heap. You are right to say that only about 30% is actually used, since 65% of that is cache, and 12% is buffers.
The kernel will release the cached memory when an application attempts to allocate more memory, this is normal behavior and I see no problem with your memory usage.
When you use significant amounts of swap, and your 'cached' count is very low - then you have a problem.
Some additional helpful information here (applicable to any Linux distro) -
http://forums.gentoo.org/viewtopic.php?t=175419
Mem: 1747660k total, 1733580k used, 14080k free, 224144k buffers
compare the total and used :-)
It is used for file buffering. It is nothing wrong since good memory managment should always use all availble memory in system. I don't remember but I think that 1144808k cached is the memory you can't find.
You can try writing simple application that reserves about 1 GB of memory and release it and quit. Then probably you should have this 1 GB counted as free memory since file buffers was removed.