Am o problemă cu utilizarea CPU pe site-ul web care utilizează WordPress, Apache și MySQL. În timpul zilei, din când în când, utilizarea procesorului de către MySQL și Apache crește până la 2400% (am 24 de nuclee în total), serverul îngheață, încărcarea medie urcă până la 24.
Recent, a fost puțin mai mult trafic decât de obicei, dar chestia asta nu ar trebui să fie permanentă, nu? Am actualizat nucleul, baza de date, bibliotecile, am repornit de multe ori. Și totuși, îngheață. M-am uitat la lista de procese a DB, dar nu este nimic extraordinar. În baza de date, există cantități destul de mari de date. Cu doar câteva săptămâni în urmă a funcționat bine, iar acum nu mai funcționează. Deci, nu ar trebui să fie interogări neoptimizate.
Care pot fi cauzele unui astfel de comportament?
Actualizați:
rezultatul A) AFIȘAȚI STARE GLOBALĂ CA „com_%r%_table”;
+-----------------------+-------+
| Nume_variabilă | Valoare |
+-----------------------+-------+
| Com_alter_table | 5 |
| Com_create_table | 34 |
| Com_drop_table | 0 |
| Com_rename_table | 0 |
| Com_show_create_table | 0 |
+-----------------------+-------+
5 rânduri în set (3,04 sec)
B) AFIȚI STAREA GLOBALĂ CA „uptime%”;
+---------------------------+--------+
| Nume_variabilă | Valoare |
+---------------------------+--------+
| Uptime | 455524 |
| Uptime_since_flush_status | 455524 |
+---------------------------+--------+
2 rânduri în set (0,01 sec)
C) AFIȚI STAREA GLOBALĂ CA „%dirty%”;
+--------------------------------+-------+
| Nume_variabilă | Valoare |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
+--------------------------------+-------+
2 rânduri în set (0,00 sec)
p.s. Mai am probleme cu serverul.
Trebuia să schimb setul de caractere dintr-una dintre bazele de date și a durat puțin mai mult de o zi pentru a termina, cu doar 400 000 de rânduri. Înainte, era nevoie de ceva timp, dar nu atât de mult. Mă întrebam, s-ar putea, că după atacul DDOS pot exista unele modificări la baza de date, astfel încât să funcționeze mai rău?
Actualizare 2:
rezultate mysqltuner:
[--] S-a omis verificarea versiunii pentru scriptul MySQLTuner
[OK] Conectat folosind acreditările din contul de întreținere Debian.
[OK] În prezent rulează versiunea MySQL acceptată 8.0.26-0ubuntu0.20.04.2
[OK] Funcționează pe arhitectură pe 64 de biți
-------- Fișier jurnal Recomandări --------------------------------------- ---------------------------
[OK] Fișierul jurnal /var/log/mysql/error.log există
[--] Fișier jurnal: /var/log/mysql/error.log(0B)
[--] Fișierul jurnal /var/log/mysql/error.log este gol. Presupunând rotire a jurnalului. Utilizați --server-log={fișier} pentru fișierul explicit
-------- Statistici motor de stocare ---------------------------------------- --------------------------
[--] Stare: +ARHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Date în tabelele InnoDB: 262.4G (Tabelele: 179)
[OK] Total tabele fragmentate: 0
-------- Măsuri de performanță a analizei --------------------------------------- -----------------------
[--] innodb_stats_on_metadata: OFF
[OK] Nu există actualizări ale statisticilor în timpul interogării INFORMATION_SCHEMA.
-------- Recomandări de securitate ---------------------------------------- --------------------------
[--] Omis din cauza caracteristicii neacceptate pentru MySQL 8
-------- Recomandări de securitate CVE --------------------------------------- -----------------------
[OK] NICIUN CVE DE SECURITATE GĂSIT PENTRU VERSIUNEA DVS
-------- Măsuri de performanță ---------------------------------------- --------------------------------
[--] Până la: 5d 11h 4m 6s (15M q [31,945 qps], 191K conexiune, TX: 80G, RX: 2G)
[--] Citiri / Scrieri: 99% / 1%
[--] Înregistrarea binară este activată (MOD GTID: OFF)
[--] Memorie fizică: 31.4G
[--] Memoria MySQL maximă: 9.8G
[--] Altă memorie de proces: 0B
[--] Buffer-uri totale: 176,0 M globale + 65,1 M per thread (max. 151 fire)
[--] P_S Utilizare maximă a memoriei: 72B
[--] Galera GCache Utilizare maximă a memoriei: 0B
[OK] Utilizarea maximă a memoriei atinse: 9,8G (31,14% din RAM instalată)
[OK] Utilizare maximă posibilă a memoriei: 9,8G (31,14% din RAM instalată)
[OK] Utilizarea generală posibilă a memoriei cu alte procese este compatibilă cu memoria disponibilă
[OK] Interogări lente: 0% (0/15M)
[!!] Cea mai mare utilizare a conexiunii: 100% (151/151)
[OK] Conexiuni întrerupte: 0,09% (174/191712)
[!!] rezoluția numelui este activă: se face o rezoluție inversă a numelui pentru fiecare conexiune nouă și poate reduce performanța
[--] Cache-ul de interogări a fost eliminat în MySQL 8
[OK] Sortări care necesită tabele temporare: 0% (0 sortări temporale / 5M sortări)
[OK] Nicio unire fără indexuri
[OK] Tabelele temporare create pe disc: 0% (0 pe disc / 2M în total)
[OK] Rata de accesare a memoriei cache a firelor: 92% (15K create / 191K conexiuni)
[OK] Rata de accesări în memoria cache a tabelului: 99% (21 milioane de accesări / 21 milioane de solicitări)
[OK] table_definition_cache(2000) este mai mare decât numărul de tabele(506)
[OK] Limită de fișiere deschise utilizată: 0% (6/10K)
[OK] Blocări de masă achiziționate imediat: 100% (9 blocări imediate / 9 blocări)
[OK] Acces la memoria cache Binlog: 99,57% (25538 memorie / 25647 total)
-------- Schema de performanță ---------------------------------------- ---------------------------------
[--] Memorie folosită de P_S: 72B
[--] Schema de sistem este instalată.
-------- Măsuri ThreadPool ---------------------------------------- ---------------------------------
[--] Statul ThreadPool este dezactivat.
-------- Măsuri MyISAM ---------------------------------------- -------------------------------------
[--] Metricurile MyISAM sunt dezactivate pe ultimele versiuni MySQL.
-------- InnoDB Metrics ---------------------------------------- -------------------------------------
[--] InnoDB este activat.
[--] Concurența firelor InnoDB: 0
[OK] Fișierul InnoDB per tabel este activat
[!!] Pool de buffer InnoDB / dimensiunea datelor: 128.0M/262.4G
[!!] Raport dimensiunea fișierului jurnal InnoDB / dimensiunea pool-ului buffer InnoDB (75%): 48.0M * 2/128.0M ar trebui să fie egal cu 25%
[OK] Instanțele pool-ului de buffer InnoDB: 1
[--] Număr de bucăți de grup de tampon InnoDB: 1 pentru 1 instanță(e) de grup de tampon
[OK] Innodb_buffer_pool_size aliniat cu Innodb_buffer_pool_chunk_size și Innodb_buffer_pool_instances
[OK] Eficiența tamponului de citire InnoDB: 98,29% (925392031 accesări/ 941450541 în total)
[!!] Eficiența jurnalului de scriere InnoDB: 309,39% (25100125 accesări/ 8112662 în total)
[!!] Așteptări în jurnalul InnoDB: 0,00% (65 așteptări / 33212787 scrieri)
-------- Aria Metrics ---------------------------------------- --------------------------------------
[--] Aria Storage Engine nu este disponibil.
-------- Măsuri TokuDB ---------------------------------------- -------------------------------------
[--] TokuDB este dezactivat.
-------- XtraDB Metrics ---------------------------------------- -------------------------------------
[--] XtraDB este dezactivat.
-------- Galera Metrics ---------------------------------------- -------------------------------------
[--] Galera este dezactivată.
-------- Măsuri de replicare ---------------------------------------- --------------------------------
[--] Galera Replicare sincronă: NU
[--] Niciun sclav(i) de replicare pentru acest server.
[--] Format binlog: ROW
[--] Suport XA activat: ACTIVAT
[--] Replicare semi-sincronă Master: Neactivat
[--] Replicare semi-sincronă Slave: Neactivat
[--] Acesta este un server independent
-------- Recomandări ----------------------------------------- -----------------------------------
Recomandări generale:
Reduceți sau eliminați conexiunile persistente pentru a reduce utilizarea conexiunii
Configurați-vă conturile numai cu ip sau subrețele, apoi actualizați configurația cu skip-name-resolve=1
Înainte de a schimba innodb_log_file_size și/sau innodb_log_files_in_group, citiți asta: *link*
Variabile de ajustat:
max_connections (> 151)
wait_timeout (< 28800)
interactive_timeout (< 28800)
innodb_buffer_pool_size (>= 262.4G) dacă este posibil.
innodb_log_file_size ar trebui să fie (=16M) dacă este posibil, astfel încât dimensiunea totală a fișierelor jurnal InnoDB este egală cu 25% din dimensiunea pool-ului de buffer.
innodb_log_buffer_size (>= 16M)
Actualizare 3:
Astăzi serverul meu a înghețat din nou. Procesul care a supraîncărcat CPU a fost apache2. Am reușit să opresc serviciul. Și deodată totul a început să funcționeze fără probleme. Am încercat să fac backup pentru baza de date, cea cu multe rânduri, și a funcționat foarte bine. Dar, după ceva timp, totul a înghețat din nou: utilizarea CPU de către unele procese a fost la 2400%, media de încărcare a depășit 24. Deci, sugestia mea, că nu apache-ul este cel care încarcă procesorul, nici MySQL. Unele dintre procese, cum ar fi htop sau gzip, pe care le folosesc pentru backup, au, de asemenea, o utilizare mare a procesorului, din când în când. Ce ar putea fi atunci? Ar putea fi acesta rezultatul unui atac DDOS și, dacă da, cum îl pot remedia?
