Utilizarea memoriei MySQL se prăbușește pe server

Vreau doar să prefațez acest lucru cu faptul că sunt nou în lucrul de administrator al serverului, dar sunt foarte interesat și dornic să învăț. Găzduiesc un mic site WordPress pe Digital Ocean, site-ul este relativ nou și are puțin sau deloc trafic. Picătura rulează o stivă LAMP tipică și are 1 GB memorie, ceea ce, din experiența mea, a fost suficientă în trecut, deoarece tind să nu folosesc multe plugin-uri și să folosesc teme destul de ușoare. Singurul plugin pe care l-am instalat pe care nu l-am folosit până acum este WordFence. Oricum, în timpul dezvoltării, primesc ocazional o eroare care spune „Eroare de stabilire a conexiunii la DB”, uneori site-ul nu se va încărca deloc și conectarea prin SSH este super lentă. Astăzi m-am confruntat cu problema și, după ce s-a rezolvat de la sine, am intrat în SSH pentru a vedea ce pot găsi. Mai jos este ceea ce am reușit să adun:

top enumerați în mod constant mysql în sus, deoarece utilizarea sa este mare

1724 mysql 20 0 1333488 405436 0 S 0,7 40,5 0:11,53 mysqld

grep -Ei 'oom|memorie lipsită' /var/log/syslog

25 ianuarie 15:18:40 nucleu picături: [599977.961722] oom_kill_process.cold+0xb/0x10
25 ianuarie 15:18:40 kernel droplet: [599977.961936] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
25 ianuarie 15:18:40 kernel picături: [599977.962031] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysk=slice/slice mysqld,pid=31337,uid=112
25 ianuarie 15:18:40 kernel cu picături: [599977.962130] Memorie epuizată: proces ucis 31337 (mysqld) total-vm:1342776kB, anon-rss:439804kB, fișier-rss:0kB, USS:0kB, USS:0kB:0kB:0kB: pgtables:1264kB oom_score_adj:0
25 ianuarie 15:18:40 kernel cu picături: [599978.039990] oom_reaper: proces cules 31337 (mysqld), acum anon-rss:0kB, fișier-rss:0kB, shmem-rss:0kB
25 ianuarie 15:26:50 kernel picături: [600468.028506] systemd invocat oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
25 ianuarie 15:26:50 nucleu picături: [600468.028534] oom_kill_process.cold+0xb/0x10
25 ianuarie 15:26:50 kernel droplet: [600468.028658] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
25 ianuarie 15:26:50 kernel picături: [600468.028754] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysk=slice/s mysqld,pid=67924,uid=112
25 ianuarie 15:26:50 kernel cu picături: [600468.028885] Memorie epuizată: proces ucis 67924 (mysqld) total-vm:1310584kB, anon-rss:385228kB, fișier-rss:0kB, USS:0kB, USS:0kB:0kB:0kB: pgtables:1132kB oom_score_adj:0
25 ianuarie 15:26:50 kernel droplet: [600468.092875] oom_reaper: proces cules 67924 (mysqld), acum anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Fiind nou în acest domeniu, nu sunt sigur dacă acest lucru este un motiv de îngrijorare (posibil un atac de vreun fel) sau dacă este pur și simplu o configurație instalarea WordPress cu un clic de la Digital Ocean sau, eventual, că 1 GB de memorie nu mai este suficient. Orice perspectivă ar fi foarte apreciată!

Nu sunt un expert în MySQL, dar am petrecut puțin timp reducând utilizarea memoriei MySQL 8.0 pe un server personal necritic pe care îl rulez și funcționează bine. Alții pot posta răspunsuri mai bune - mergeți cu ei peste asta.

Rulez un server AWS EC2 t3a.nano cu cinci instanțe Wordpress, MySQL 8.x., PHP 7.x și alte câteva lucruri cu 512MB RAM și 1GB swap, așa că 1GB este suficient pentru un site cu volum redus. Puteți adăuga spațiu de schimb dacă doriți, sistemul de operare va pagina datele de care nu are nevoie, astfel încât procesele în execuție să aibă mai multă RAM disponibilă.

Trebuie să configurați MySQL să ruleze cu memorie limitată, lucruri precum reducerea dimensiunilor RAM, a bufferelor și dezactivarea schemei de performanță.Reducerea utilizării RAM PHP va ajuta, de asemenea, la reducerea șanselor de a intrat în ucigașul lipsei de memorie. MySQL 8.0 încă folosește mult mai mult RAM decât MySQL 5.6, deși un expert ar putea să o reducă mai mult decât am avut mine.

Iată părțile cheie din configurația mea MySQL 8 - menționând aici că nu sunt un expert în MySQL și ar trebui să faceți câteva cercetări pentru a înțelege această configurație înainte de a o aplica. Unele dintre acestea ar putea fi valorile implicite, dar, în general, am setat majoritatea parametrilor aproape de cea mai mică valoare permisă.

Fișierele dvs. de configurare pot fi în locații diferite. Asigurați-vă că faceți o copie de rezervă a întregului server înainte de a începe orice modificare și faceți o copie de rezervă a fișierelor înainte de a le modifica.

/etc/mysql/conf.d/mysql.cnf

# setări globale
performance_schema = OFF

innodb_buffer_pool_size=50M
innodb_flush_method=O_DIRECT
innodb_log_buffer_size=1048576
innodb_log_file_size=4194304
innodb_max_undo_log_size=10485760
innodb_sort_buffer_size=64K
innodb_ft_cache_size=1600000
innodb_max_undo_log_size=10485760
max_connections=20
key_buffer_size=1M

# de setări pe fir
thread_stack=140K
thread_cache_size = 2
read_buffer_size=8200
read_rnd_buffer_size=8200
max_heap_table_size=16K
tmp_table_size=128K
temptable_max_ram=2097152
bulk_insert_buffer_size=0
join_buffer_size=128
net_buffer_length=1K

/etc/mysql/mysql.conf.d/mysqld.cnf

key_buffer_size = 16M
thread_stack = 256K

Iată câteva ajustări pe care le-am făcut la configurația PHP pentru a reduce utilizarea RAM

/etc/php/7.4/fpm/pool.d/www.conf

pm.max_children = 3
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 1
pm.process_idle_timeout = 20s;
pm.max_requests = 50
php_admin_value[memory_limit] = 64M

Statistici server

Iată câteva statistici din comanda „top” a serverelor

Per total

• Mem 448MB, 42MB gratuit, 190MB folosit, 216MB buffer/cache
• Schimbați 1024, 725 MB gratuit, 300 MB folosit

Procesele

• MySQL Virt 1459020 Res 44696 CPU 3% Mem 10%
• PHP FPM 7.x Virt 223124 Res 32464 CPU 0% Mem 7%
• CPU Nginx Virt 63932 Res 7520 0% Mem 2%