înregistrare Logare
Puncte:2
Mahmoud Moussa avatar Server

MariaDB nebun la 500% timp CPU

drapel br
Mahmoud Moussa

STARE GLOBALĂ

MariaDB [(niciunul)]> SHOW GLOBAL STATUS;
+--------------------------------------------- -------------+------------------------------------ --------------+
| Nume_variabilă | Valoare |
+--------------------------------------------- -------------+------------------------------------ --------------+
| Clienti_avortati | 10 |
| Conectări_avortate | 17 |
| Erori_acces_interzis | 2808 |
| Acl_column_grants | 0 |
| Acl_database_grants | 255 |
| Acl_function_grants | 0 |
| Acl_procedure_grants | 0 |
| Acl_proxy_users | 1 |
| Acl_role_grants | 0 |
| Acl_roles | 0 |
| Acl_table_grants | 2 |
| Acl_users | 253 |
| Aria_pagecache_blocks_not_flushed | 0 |
| Aria_pagecache_blocks_unused | 15706 |
| Aria_pagecache_blocks_used | 40 |
| Aria_pagecache_read_requests | 287044 |
| Aria_pagecache_reads | 20253 |
| Aria_pagecache_write_requests | 36614 |
| Aria_pagecache_writes | 36593 |
| Aria_transaction_log_syncs | 1 |
| Binlog_commits | 0 |
| Binlog_group_commits | 0 |
| Binlog_group_commit_trigger_count | 0 |
| Binlog_group_commit_trigger_lock_wait | 0 |
| Binlog_group_commit_trigger_timeout | 0 |
| Binlog_snapshot_file | |
| Binlog_snapshot_position | 0 |
| Binlog_bytes_scriși | 0 |
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 0 |
| Binlog_stmt_cache_disk_use | 0 |
| Binlog_stmt_cache_use | 0 |
| Timp_ocupat | 0,000000 |
| Bytes_received | 243371501 |
| Bytes_trimis | 2355355672 |
| Com_admin_commands | 2293 |
| Com_alter_db | 0 |
| Com_alter_db_upgrade | 0 |
| Com_alter_event | 0 |
| Com_alter_function | 0 |
| Com_alter_procedure | 0 |
| Com_alter_server | 0 |
| Com_alter_table | 0 |
| Com_alter_tablespace | 0 |
| Com_alter_user | 0 |
| Com_analiza | 0 |
| Com_assign_to_keycache | 0 |
| Com_begin | 0 |
| Com_binlog | 0 |
| Com_call_procedure | 0 |
| Com_change_db | 92 |
| Com_change_master | 0 |
| Com_check | 0 |
| Com_checksum | 0 |
| Com_commit | 0 |
| Com_compound_sql | 0 |
| Com_create_db | 0 |
| Com_create_event | 0 |
| Com_create_function | 0 |
| Com_create_index | 0 |
| Com_create_procedure | 0 |
| Com_create_role | 0 |
| Com_create_server | 0 |
| Com_create_table | 0 |
| Com_create_temporary_table | 0 |
| Com_create_trigger | 0 |
| Com_create_udf | 0 |
| Com_create_user | 0 |
| Com_create_view | 0 |
| Com_dealloc_sql | 0 |
| Com_delete | 8354 |
| Com_delete_multi | 0 |
| Com_do | 0 |
| Com_drop_db | 0 |
| Com_drop_event | 0 |
| Com_drop_function | 0 |
| Com_drop_index | 0 |
| Com_drop_procedure | 0 |
| Com_drop_role | 0 |
| Com_drop_server | 0 |
| Com_drop_table | 0 |
| Com_drop_temporary_table | 0 |
| Com_drop_trigger | 0 |
| Com_drop_user | 0 |
| Com_drop_view | 0 |
| Com_empty_query | 0 |
| Com_execute_immediate | 0 |
| Com_execute_sql | 0 |
| Com_flush | 0 |
| Com_get_diagnostics | 0 |
| Com_grant | 0 |

488 de rânduri în set (0,00 sec)

MariaDB [(niciunul)]>

my.cnf

[root@host ~]# cat /etc/my.cnf
#
# Acest grup este citit atât de client, cât și de server
# folosește-l pentru opțiuni care afectează totul
#
[client server]

#
# include toate fișierele din directorul de configurare
#
!includedir /etc/my.cnf.d

[mysqld]
log-error=/var/lib/mysql/s102.halabtech.net.err
schema-performanță=0
innodb_file_per_table=1
default-storage-engine=MyISAM
max_allowed_packet=268435456
open_files_limit=40000
skip-name-resolve

sql_mode=''

local-infile=0
connect_timeout=25
wait_timeout=30
interactive_timeout=30
slow-query-log=1
long_query_time=5
slow_query_log_file="/var/log/mysql-slow.log"

key_buffer_size = 128M
thread_stack = 128K
thread_cache_size = 8
max_heap_table_size = 256M
query_cache_limit = 4M
query_cache_size = 512M
innodb_buffer_pool_size = 2G

Specificații server:

CPU Intel(R) Core(TM) i7-8700 la 3,20 GHz

Memorie: 4107488k/68927488k disponibile (7792k cod kernel, 1900528k absent, 1353716k rezervate, 5950k date, 1984k init)

Filesystem Size Used Avail Use% Montat pe
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 28M 32G 1% /run
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/md2 437G 273G 142G 66% /
/dev/md1 488M 401M 62M 87% /boot
tmpfs 6.3G 0 6.3G 0% /run/user/0
tmpfs 6.3G 0 6.3G 0% /run/user/987
tmpfs 6.3G 0 6.3G 0% /run/user/1034

ACTUALIZAȚI

MYSQL SLOW QUERY DUMP: (Numele reale ale bazei de date au fost schimbate)

Citirea jurnalului de interogări lente mysql din /var/log/mysql-slow.log
Count: 2 Time=20.58s (41s) Lock=0.00s (0s) Rows_sent=4089261.5 (8178523), Rows_examined=4089261.5 (8178523), Rows_affected=0.0 (0), root[root]@localhost
  SELECT /*!40001 SQL_NO_CACHE */ * FROM `hb_udownloads`

Număr: 3 Timp=15,38s (46s) Blocare=0,00s (0s) Rows_sent=81,0 (243), Rows_examined=10026558,0 (30079674), Rows_affected=0,0 (0), server***_fusion[server***_fusion] @gazdă locală
  SELECT *,(selectați count(id) din tbl_swkey
  unde group_id=tbl_keygroup.id și folosit=0) așa cum s-a vândut, (selectați count(id) din tbl_swkey
  unde group_id=tbl_keygroup.id și used=1) așa cum este folosit FROM tbl_keygroup
  ordonați după `displayorder` asc

Număr: 1 Timp=8.68s (8s) Blocare=0.00s (0s) Rows_sent=0.0 (0), Rows_examined=4090482.0 (4090482), Rows_affected=0.0 (0), support***_res[support***_res] @gazdă locală
  UPDATE hb_udownloads SET `upackage_id` = 0 WHERE upackage_id = 403775

Count: 1 Time=5,64s (5s) Lock=0,00s (0s) Rows_sent=0,0 (0), Rows_examined=4088258.0 (4088258), Rows_affected=0,0 (0), support***_res[support***_res] @gazdă locală
  SELECT udownload_id AS retval FROM hb_udownloads WHERE user_id = 415064 AND file_id = 78499 LIMIT 1

Count: 1 Time=5,58s (5s) Lock=0,00s (0s) Rows_sent=0,0 (0), Rows_examined=4088256.0 (4088256), Rows_affected=0,0 (0), support***_res[support***_res] @gazdă locală
  SELECT udownload_id AS retval FROM hb_udownloads WHERE user_id = 208286 AND file_id = 202629 LIMIT 1

Count: 1 Time=5,35s (5s) Lock=0,00s (0s) Rows_sent=0,0 (0), Rows_examined=4088255.0 (4088255), Rows_affected=0,0 (0), support***_res[support***_res] @gazdă locală
  SELECT udownload_id AS retval FROM hb_udownloads WHERE user_id = 235082 AND file_id = 473624 LIMIT 1

Count: 1 Time=5,21s (5s) Lock=0,00s (0s) Rows_sent=0,0 (0), Rows_examined=4088254.0 (4088254), Rows_affected=0,0 (0), support***_res[supporth***_res] @gazdă locală
  SELECT udownload_id AS retval FROM hb_udownloads WHERE user_id = 61350 AND file_id = 493488 LIMIT 1

Count: 1 Time=5,17s (5s) Lock=0,00s (0s) Rows_sent=0,0 (0), Rows_examined=4088259.0 (4088259), Rows_affected=0,0 (0), support***_res[support***_res] @gazdă locală
  SELECT udownload_id AS retval FROM hb_udownloads WHERE user_id = 338554 AND file_id = 439150 LIMIT 1

Vă rugăm să spuneți de ce am uneori vârfuri foarte mari până la 500% și ce ar trebui făcut pentru a rezolva problema, deoarece primesc o mulțime de erori de 50x. Te rog să-mi ierți și engleza mea proastă. Multumesc anticipat.

190
3 + 8
uhm
digijay avatar
drapel mx
digijay
Aruncă o privire la jurnalul de interogări lente: `/var/log/mysql-slow.log`.Puteți folosi `mysqldumpslow` ([vezi aici](https://mariadb.com/kb/en/mysqldumpslow/)) pentru a obține un rezumat. Primești indicii? Vă rugăm [adăugați-le la întrebarea dvs.](https://serverfault.com/posts/1074131/edit)
0
Răspunde
drapel ua
Rick James
Slowlog: http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog CPU mare implică, de obicei, lipsa indecșilor adecvați și/sau formularea slabă a interogărilor.
2
Răspunde
drapel ua
Rick James
Chiar aveți aproximativ 60 GB de programe care rulează? MariaDB pare să folosească sub 6 GB?
0
Răspunde
Mahmoud Moussa avatar
drapel br
Mahmoud Moussa
@digijay Am adăugat ieșirea mysqldumpslow la postări, vă rugăm să o verificați. Mulțumesc mult.
1
Răspunde
Mahmoud Moussa avatar
drapel br
Mahmoud Moussa
@RickJames Bună Rick! Vă mulțumesc mult pentru răspuns, am adăugat descărcarea lentă a interogării, puteți vă rog să-l verificați și să-mi spuneți care este problema exactă?
0
Răspunde
Mahmoud Moussa avatar
drapel br
Mahmoud Moussa
@RickJames Da, am 64 GB de RAM instalat pe server. Ai vreo sugestie? Mulțumesc mult.
0
Răspunde
drapel ws
symcbean
Chiar trebuie să adăugați niște indecși.
0
Răspunde
Wilson Hauck avatar
drapel jp
Wilson Hauck
Solicitare de informații suplimentare - după ce ați adăugat indexurile sugerate. Există dispozitive SSD sau NVME pe serverul MySQL Host? Postați pe pastebin.com și distribuiți linkurile. Din rădăcina dvs. de conectare SSH, rezultă text de: B) AFIȚI STARE GLOBALĂ; după minim 24 de ore UPTIME C) AFIȘAȚI VARIABILELE GLOBALE; D) AFIȚI LISTA COMPLETĂ DE PROCES; ȘI informații opționale foarte utile, dacă sunt disponibile includ - htop SAU top pentru majoritatea aplicațiilor active, ulimit -a pentru o listă de limite Linux/Unix, iostat -xm 5 3 pentru IOPS în funcție de dispozitiv și număr de nuclee/procesoare, pentru analiza de reglare a sarcinii de lucru a serverului pentru a oferi sugestii.
0
Răspunde
Puncte:3
Phill W. avatar Server
drapel cn
Phill W.

Utilizarea ridicată a procesorului înseamnă, de obicei, multă scanare a tabelelor în memorie.

Privind una dintre interogările tale lente:

Timp=5,64s (5s) Rows_sent=0,0 (0) Rows_examined=4088258,0 (4088258)
SELECTează udownload_id AS retval 
DE LA hb_udownloads 
WHERE user_id = 415064  
AND file_id = 78499  
LIMITA 1

Interogarea citește întregul tabel de 4 milioane de rânduri, dar revine cel mult unu dintre ele (și, în acest caz, deloc).
Ai nevoie indici pe acest tabel pentru a sprijini această interogare. Una compozită pe ID-ul de utilizator și file_id ar fi un început bun.

Un alt ucigaș de performanță aici:

Timp=20,58s (41s) Rows_sent=4089261,5 (8178523) Rows_examined=4089261,5 (8178523)
SELECT /*!40001 SQL_NO_CACHE */ * 
DE LA `hb_udownloads`

Nu folosi niciodată "Selectați *" în Cod de producție.
Mereu specificați în mod explicit coloanele dorite. Aș ghici că acest tabel a „crescut” (a câștigat coloane) în ultima vreme.
OK, fără o clauză where, oricum se va scana tabelul, dar asta ridică întrebarea - ce va face clientul sărac [aplicația] do cu cele 4 milioane de rânduri pe care le „aruncă” această interogare?

0 + 0
Puncte:1
avatar Server
drapel ua
Rick James

** Acest lucru ar trebui să îl facă pe primul mult mai rapid:

SELECTAȚI k.*, s.vandut, s.folosit
    FROM ( SELECT ID_grup,
                  SUM(utilizat = 0) AS vândut,
                  SUM(utilizat = 1) AS folosit
               DE LA tbl_swkey
         ) AS s
    JOIN tbl_keygroup AS k ON s.group_id = k.id
    ORDER BY displayorder

Si are

tbl_swkey: INDEX(grup_id, folosit)
tbl_keygroup: INDEX(displayorder)

Dacă trebuie să discutați în continuare această întrebare, vă rugăm să furnizați AFIȚI CREATE TABLE pentru ambele mese, dimensiunile mesei și EXPLICAȚI SELECTARE....

** Acest

SELECTează udownload_id AS retval
    DE LA hb_udownloads
    WHERE user_id = 415064
      AND file_id = 78499
    LIMITA 1

are nevoie de un index compus pe 3 coloane pentru a fi mult mai rapid:

INDEX(user_id, file_id, udownload_id)

Nu-ți pasă ce rând potrivit primești? Sau ar trebui să adăugați un COMANDA PENTRU? Dacă adăugați un COMANDA PENTRU, ar putea fi necesar să se schimbe sfatul meu de index.

** Acesta a venit de la mysqldump?

SELECT /*!40001 SQL_NO_CACHE */ * FROM `hb_udownloads`

Dacă nu sunteți mulțumit de cât de invazive sunt depozitele, există mai multe discuții pe dba.stackexchange.com despre acest subiect.

0 + 0
Puncte:1
Matthew Ife avatar Server
drapel jo
Matthew Ife

Unele dintre aceste interogări par că ar putea avea nevoie de optimizare.

De exemplu:

Rows_examined=10026558.0 (30079674), Rows_affected=0.0 (0), server***_fusion[server***_fusion]@localhost
  SELECT *,(selectați count(id) din tbl_swkey
  unde group_id=tbl_keygroup.id și folosit=0) așa cum s-a vândut, (selectați count(id) din tbl_swkey
  unde group_id=tbl_keygroup.id și used=1) așa cum este folosit FROM tbl_keygroup
  ordona dupa `displayorder` asc

Această interogare scanează 30000000 de rânduri.

Este posibil să o schimbați pe aceasta, de exemplu, la două interogări:

SELECT * FROM tbl_keygroup ORDER prin `displayorder` asc;
SELECT count(id) FROM tbl_swkey WHERE folosit IN (0,1) GROUP BY folosit;

Deoarece interogarea în sine implică o îmbinare inutilă și două scanări de tabel complet care ar putea fi înjumătățite.

O mare parte din ceea ce ați arătat indică probleme legate de optimizarea interogărilor și m-aș uita la acel jurnal de interogare lent pentru a determina care ar fi cea mai bună modalitate de a prelua acele date cu cel mai mic număr de scanări de tabel.

De asemenea, probabil că veți dori să indexați o mulțime de date în același scop.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

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.