Puncte:0

MySQL „Nu se poate aloca memorie pentru pool-ul de buffer” la 73% de utilizare a memoriei?

drapel in

Găzduiesc un site web WordPress pe o picătură DigitalOcean (1 GB RAM). Baza de date MySQL a site-ului web se blochează ocazional, ceea ce face ca site-ul web să afișeze „Eroare la stabilirea conexiunii la baza de date”. Utilizarea memoriei a scăzut în jurul orei 2:40, ceea ce indică faptul că atunci baza de date s-a prăbușit. Am verificat fișierul jurnal MySQL pentru ziua respectivă, iar cea mai veche intrare a fost la 10:47. Iată începutul fișierului jurnal:

2021-12-06T10:47:14.800977Z 0 [Avertisment] TIMESTAMP cu valoare implicită DEFAULT este depreciat. Vă rugăm să utilizați --explicit_defaults_for_timest$
2021-12-06T10:47:14.806192Z 0 [Notă] /usr/sbin/mysqld (mysqld 5.7.36-0ubuntu0.18.04.1) începând cu procesul 2810...
2021-12-06T10:47:14.819674Z 0 [Notă] InnoDB: suport PUNCH HOLE disponibil
2021-12-06T10:47:14.819711Z 0 [Notă] InnoDB: Mutexurile și rw_lock-urile folosesc elementele integrate atomice GCC
2021-12-06T10:47:14.819716Z 0 [Notă] InnoDB: folosește mutexuri pentru evenimente
2021-12-06T10:47:14.819720Z 0 [Notă] InnoDB: __atomic_thread_fence() încorporat GCC este utilizat pentru bariera de memorie
2021-12-06T10:47:14.819723Z 0 [Notă] InnoDB: Tabelele comprimate folosesc zlib 1.2.11
2021-12-06T10:47:14.819727Z 0 [Notă] InnoDB: Utilizarea AIO nativă Linux
2021-12-06T10:47:14.820551Z 0 [Notă] InnoDB: Număr de pool-uri: 1
2021-12-06T10:47:14.823342Z 0 [Notă] InnoDB: Utilizarea instrucțiunilor CPU crc32
2021-12-06T10:47:14.825847Z 0 [Notă] InnoDB: Inițializarea pool-ului de buffer, dimensiunea totală = 128 M, instanțe = 1, dimensiunea bucată = 128 M
2021-12-06T10:47:14.826246Z 0 [EROARE] InnoDB: mmap(137428992 bytes) a eșuat; eroare 12
2021-12-06T10:47:14.826258Z 0 [EROARE] InnoDB: Nu se poate aloca memorie pentru pool-ul de buffer
2021-12-06T10:47:14.826262Z 0 [EROARE] InnoDB: Inițializarea pluginului a fost anulată cu eroare Eroare generică
2021-12-06T10:47:14.826270Z 0 [EROARE] Funcția de pornire a pluginului „InnoDB” a returnat o eroare.
2021-12-06T10:47:14.826274Z 0 [EROARE] Înregistrarea pluginului „InnoDB” ca MOTOR DE STOCARE a eșuat.
2021-12-06T10:47:14.826278Z 0 [EROARE] Nu s-a putut inițializa pluginurile încorporate.
2021-12-06T10:47:14.826282Z 0 [EROARE] Se anulează

2021-12-06T10:47:14.832237Z 0 [Notă] Sfârșit binlog
2021-12-06T10:47:14.832297Z 0 [Notă] Închiderea pluginului „CSV”
2021-12-06T10:47:14.832572Z 0 [Notă] /usr/sbin/mysqld: Închidere finalizată

Pe baza fișierului jurnal, se pare că MySQL rămâne fără memorie. Cu toate acestea, utilizarea memoriei pentru picătură a fost constantă în jurul valorii de 73%, până când baza de date a căzut în jurul orei 2:40, când a scăzut la 32%. Se pare că are o mulțime de memorie disponibilă, așa că de ce se prăbușește?

EDITARE După cum am cerut, iată conținutul fișierelor mele de configurare MySQL:

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

[mysql]

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

[mysqldump]
rapid
citate-nume
max_allowed_packet = 16M

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

#
# Fișierul de configurare a serverului bazei de date MySQL.
#
# Puteți copia acest lucru într-una dintre:
# - „/etc/mysql/my.cnf” pentru a seta opțiuni globale,
# - „~/.my.cnf” pentru a seta opțiuni specifice utilizatorului.
#
# Se pot folosi toate opțiunile lungi pe care le acceptă programul.
# Rulați programul cu --help pentru a obține o listă de opțiuni disponibile și cu
# --print-defaults pentru a vedea pe care le-ar înțelege și utiliza de fapt.
#
# Pentru explicații vezi
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# Acesta va fi transmis tuturor clienților mysql
# S-a raportat că parolele ar trebui să fie incluse cu bifă/ghilimele
# mai ales dacă conțin caractere „#”...
# Nu uitați să editați /etc/mysql/debian.cnf când schimbați locația socket-ului.

# Iată intrări pentru unele programe specifice
# Următoarele valori presupun că aveți cel puțin 32M ram

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
frumos = 0

[mysqld]
#
# * Setări de bază
#
utilizator = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-blocare-exterior
#
# În loc să omiteți rețeaua, implicit este acum să ascultați numai pornit
# localhost care este mai compatibil și nu este mai puțin sigur.
bind-address = 127.0.0.1
#
# * Reglaj fin
#
key_buffer_size = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
# Acesta înlocuiește scriptul de pornire și verifică tabelele MyISAM dacă este necesar
# prima dată când sunt atinși
myisam-recover-options = BACKUP
#max_connections = 100
#table_open_cache = 64
#thread_concurrency = 10
#
# * Configurare cache de interogări
#
query_cache_limit = 1M
query_cache_size = 16M
#
# * Înregistrare și replicare
#
# Ambele locații sunt rotite de cronjob.
# Fiți conștienți de faptul că acest tip de jurnal este un ucigaș de performanță.
# Începând cu 5.1, puteți activa jurnalul în timpul execuției!
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1
#
# Jurnal de erori - ar trebui să fie foarte puține intrări.
#
log_error = /var/log/mysql/error.log
#
# Aici puteți vedea interogări cu o durată deosebit de lungă
#slow_query_log = 1
#slow_query_log_file = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# Următoarele pot fi folosite ca jurnalele de rezervă ușor de reluat sau pentru replicare.
# notă: dacă configurați un slave de replicare, consultați README.Debian despre
# alte setări pe care poate fi necesar să le modificați.
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * InnoDB
#
# InnoDB este activat implicit cu un fișier de date de 10 MB în /var/lib/mysql/.
# Citiți manualul pentru mai multe opțiuni legate de InnoDB. Sunt multi!
#
# * Caracteristici de securitate
#
# Citiți și manualul, dacă doriți chroot!
# chroot = /var/lib/mysql/
#
# Pentru generarea certificatelor SSL recomand GUI OpenSSL "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

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

[mysqld_safe]
syslog
dominix avatar
drapel gf
ar trebui să aveți unele variabile setate în /etc/my.cnf.d/server.cnf legate de memorie și/sau innodb care nu se potrivesc cu dimensiunea sau memoria bazei de date. ne puteți arăta aceste variabile și dimensiunea bazei de date?
bumbleshoot avatar
drapel in
@dominix Nu există nici un director sau fișier /etc/my.cnf.d/server.cnf. Cel mai apropiat lucru pe care îl pot găsi este /etc/mysql/mysql.conf.d/mysqld.cnf. Serverul rulează Ubuntu 18.04, dacă asta ajută.
drapel us
Puteți adăuga un fragment mai lung din fișierul jurnal la întrebare? Acest fișier jurnal pare că serverul MySQL tocmai pornește, ceea ce nu se potrivește cu descrierea dvs.
bumbleshoot avatar
drapel in
@dominix Dimensiunea bazei de date este de 43,5 MB.
bumbleshoot avatar
drapel in
@TeroKilkanen Conform istoricului utilizării memoriei, se pare că baza de date s-a prăbușit în jurul orei 2:40. Cu toate acestea, fișierul jurnal pentru ziua respectivă nu are intrări înainte de ora 10:47. Acesta este cel mai aproape de momentul prăbușirii bazei de date. Îmi voi extinde întrebarea pentru a include toate intrările de la începutul fișierului jurnal.
drapel us
Ați verificat fișierele jurnal rotite?
bumbleshoot avatar
drapel in
@TeroKilkanen Am actualizat formularea din întrebarea mea, sper că este mai clar acum.
bumbleshoot avatar
drapel in
@TeroKilkanen Te referi la fișierele jurnal comprimate din /var/log/mysql? Da, le-am decomprimat și le-am citit.
drapel us
Are `/var/log/kern.log` ceva în jurul momentului accidentului?
bumbleshoot avatar
drapel in
Să [continuăm această discuție în chat](https://chat.stackexchange.com/rooms/132261/discussion-between-bumbleshoot-and-tero-kilkanen).
Puncte:2
drapel us

După examinarea jurnalului de kernel în chat, motivul blocării MySQL a fost lipsa memoriei.

6 decembrie 02:47:13 kernel: [341799.228400] Memorie epuizată: Uciderea procesului 23566 (mysqld) scor 197 sau sacrificarea copilului
6 decembrie 02:47:13 kernel: [341799.229866] Procesul oprit 23566 (mysqld) total-vm:1168576kB, anon-rss:198536kB, file-rss:0kB, shmem-rs:

În acea perioadă au fost active o mulțime de procese Apache2. Aceasta înseamnă că creșterea traficului determină un consum crescut de memorie. Ca rezultat, nucleul a decis să oprească MySQL pentru a elibera memorie.

Se poate alerga mysqltuner pentru a analiza configurația MySQL. Oferă recomandări, care pot ajuta la reducerea consumului de memorie MySQL.

Cu toate acestea, creșterea traficului poate provoca în continuare aceleași probleme. Prin urmare, o soluție mai durabilă este creșterea memoriei disponibile pentru picătură.

bumbleshoot avatar
drapel in
Mulțumesc din nou pentru ajutor!
bumbleshoot avatar
drapel in
Tocmai am verificat Google Analytics pentru acest site web și a existat o singură vizualizare de pagină pe 6 decembrie (site-ul web a căzut pe 6 decembrie între orele 2:40-2:50). Acest lucru nu pare să se potrivească cu ceea ce ați văzut în jurnalul kernelului. Ai idee de ce?
drapel us
Google Analytics afișează numai traficul din browserele web care execută codul Google Analytics JS. În plus, internetul are o mulțime de trafic de bot. Puteți vedea acel trafic în serverul dvs. web access.log
bumbleshoot avatar
drapel in
Bine, are sens. Trebuie să fi fost mult trafic de bot deodată pentru a copleși un server care folosea în mod constant doar 73% memorie? Crezi că a fost un atac DDoS? Există vreo modalitate de a bloca acest trafic bot în viitor?
Puncte:1
drapel ua

1 GB RAM este foarte mic aceste zile. Server-ul ar putea supraviețuiți dacă vă setați innodb_buffer_pool_size = 50M. Recomandările pentru un anumit procent de RAM nu se aplică pentru o dimensiune RAM atât de mică.

Există riscul ca 50M să fie prea mic. Vă rugăm să furnizați dvs my.cnf astfel încât să putem căuta alte setări pentru a se micșora. Câteva probabil:

max_connections = 10
key_buffer_size = 10M
temp_table_size = 10M
max_heap_table_size = 10M
table_open_cache = 100

query_cache_size = 0
max_allowed_packet = 8M
key_buffer_size = 10M
max_connections = 10

Da, MySQL/MariaDB va rula într-o mașină mică, dar reglarea este necesară.

Dacă Apache rulează pe același server, reduceți MaxRequestWorkers la 10. Și verificați configurația oricărui alt server care rulează pe același server [virtual].

bumbleshoot avatar
drapel in
Multumesc pentru raspuns.`my.cnf` conține doar `!includedir /etc/mysql/conf.d/` și `!includedir /etc/mysql/mysql.conf.d/`. `/etc/mysql/conf.d/` conține `mysql.cnf` și `mysqldump.cnf`. `/etc/mysql/mysql.conf.d/` conține `mysqld.cnf` și `mysqld_safe_syslog.cnf`. Trebuie să vedeți conținutul vreunuia dintre aceste fișiere?
drapel ua
@bumbleshoot - Da, vă rog să le arătați.
bumbleshoot avatar
drapel in
Ok, le-am adăugat la întrebarea mea inițială.
drapel ua
@bumbleshoot - Am mai adăugat câteva setări pentru a le modifica.
bumbleshoot avatar
drapel in
Multumesc mult! Voi încerca aceste setări.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.