Nu există o explicație evidentă în VARIABILE și STARE.
Analiza STATULUI GLOBAL și a VARIABILLOR:
Observatii:
- Versiunea: 8.0.20
- 60 GB RAM
- Timp de funcționare = 04:49:11; este posibil ca unele valori GLOBAL STATUS să nu fie încă semnificative.
- Rulați pe Windows.
- 4,89 Întrebări/sec. : 3,43 Întrebări/sec
Cele mai importante probleme:
Aproape nimic nu se întâmplă. Întâmpin probleme în a-mi imagina că MySQL a blocat accidentul.
Inferior max_connections
la 500. (Nu au existat mai mult de 23 de conexiuni simultane de la pornire.)
tmp_table_size = 500M -- este în prezent periculos de mare pentru cantitatea de RAM pe care o aveți.
innodb_doublewrite = ON
Detalii și alte observații:
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1.024 * 4 = 4.096
-- Cantitatea de muncă pentru curățarea paginilor în fiecare secundă.
-- „InnoDB: page_cleaner: 1000ms intentionat bucla a durat...” poate fi reparat prin scăderea lru_scan_depth: Luați în considerare 1000 / innodb_page_cleaners (acum 4). De asemenea, verificați pentru schimbare.
( innodb_lru_scan_depth ) = 1.024
-- „InnoDB: page_cleaner: bucla intenționată a durat 1000 ms...” poate fi remediată prin scăderea lru_scan_depth
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 2.478.311 * 16384 / 38912M = 99,5%
-- piscina tampon gratuit
-- buffer_pool_size este mai mare decât setul de lucru; ar putea să o scadă
( innodb_io_capacity ) = 200
-- Când spălați, utilizați atât de multe IOP-uri.
-- Citirile pot fi lente sau țepoase.
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 2.478.311 / 2490368 = 99,5%
-- Pct of buffer_pool nu este utilizat în prezent
-- innodb_buffer_pool_size (acum 40802189312) este mai mare decât este necesar?
( innodb_io_capacity_max / innodb_io_capacity ) = 2.000 / 200 = 10
-- Capacitate: max/plan
-- Recomand 2. Max ar trebui să fie aproximativ egal cu IOP-urile pe care le poate gestiona subsistemul dumneavoastră I/O. (Dacă tipul de unitate este necunoscut, 2000/200 poate fi o pereche rezonabilă.)
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 196.214.784 / 38912M = 0,48%
-- Procentul din pool-ul de tampon ocupat de date
-- Un procent mic Mai indică faptul că buffer_pool este inutil de mare.
( innodb_doublewrite ) = innodb_doublewrite = OFF
-- I/O suplimentară, dar siguranță suplimentară în caz de accident.
-- OFF este OK pentru FusionIO, Galera, Replicas, ZFS.
( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 3.944.448 / (17351 / 3600) / 2 / 48M = 0,00813
-- Raport
-- (vezi minutele)
( Timp de funcționare / 60 * innodb_log_file_size / Innodb_os_log_written ) = 17.351 / 60 * 48M / 3944448 = 3.690
-- Minute între rotațiile jurnalului InnoDB Începând cu 5.6.8, aceasta poate fi schimbată dinamic; asigurați-vă că schimbați și my.cnf.
-- (Recomandarea de 60 de minute între rotații este oarecum arbitrară.) Ajustați innodb_log_file_size (acum 50331648). (Nu se poate modifica în AWS.)
( innodb_flush_method ) = innodb_flush_method = fără tampon
-- Cum ar trebui InnoDB să ceară sistemului de operare să scrie blocuri. Sugerați O_DIRECT sau O_ALL_DIRECT (Percona) pentru a evita tamponarea dublă. (Cel puțin pentru Unix.) Vezi chrischandler pentru avertisment despre O_ALL_DIRECT
( innodb_io_capacity ) = 200
- Capacitate operațiuni I/O pe secundă pe disc. 100 pentru drive-uri lente; 200 pentru unități de filare; 1000-2000 pentru SSD-uri; înmulțiți cu factorul RAID.
( innodb_adaptive_hash_index ) = innodb_adaptive_hash_index = ON
-- De obicei, ar trebui să fie ON.
-- Există cazuri în care OFF este mai bine. Vezi și innodb_adaptive_hash_index_parts (acum 8) (după 5.7.9) și innodb_adaptive_hash_index_partitions (MariaDB și Percona). ON a fost implicat în accidente rare (bug 73890). 10.5.0 a decis să dezactiveze implicit.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF
-- Dacă să înregistrezi toate blocajele.
-- Dacă sunteți afectat de Deadlocks, activați acest lucru. Atenție: dacă aveți o mulțime de blocaje, acest lucru poate scrie mult pe disc.
( max_connections ) = 2.000
-- Numărul maxim de conexiuni (file). Afectează diverse alocări.
-- Dacă max_connections (acum 2000) este prea mare și diferite setări de memorie sunt mari, ați putea rămâne fără memorie RAM.
( bulk_insert_buffer_size ) = 8 / 61440M = 0,01%
-- Buffer pentru INSERT-uri cu mai multe rânduri și LOAD DATA
-- Prea mare ar putea amenința dimensiunea RAM. Prea mic ar putea împiedica astfel de operațiuni.
( tmp_table_size ) = 4096M
-- Limita de dimensiune a MEMORIE tabelele temp utilizate pentru a susține un SELECT
-- Reduceți tmp_table_size (acum 4294967296) pentru a evita rămânerea fără memorie RAM. Poate nu mai mult de 64 de milioane.
( Select_full_join / Com_select ) = 15.198 / 31082 = 48,9%
-- % dintre selecții care sunt îmbinări fără index
-- Adăugați indexuri adecvate la tabelele utilizate în JOIN-uri.
( Com_admin_commands / Interogări ) = 25.348 / 84808 = 29,9%
-- Procentul de interogări care sunt comenzi „admin”.
-- Ce se întâmplă?
( long_query_time ) = 10
-- Cutoff (secunde) pentru definirea unei interogări „lente”.
-- Sugerează 2
( log_slow_slave_statements ) = log_slow_slave_statements = OFF
-- (5.6.11, 5.7.1) În mod implicit, instrucțiunile replicate nu vor apărea în slowlog; acest lucru îi face să se arate.
-- Poate fi util în slowlog să vedeți scrierile care ar putea interfera cu citirile Replica.
( back_log ) = 80
-- (Dimensiune automată începând cu 5.6.6; bazat pe max_connections)
-- Creșterea la min(150, max_connections (acum 2000)) poate ajuta atunci când faceți o mulțime de conexiuni.
( Max_used_connections / max_connections ) = 23 / 2000 = 1,1%
-- Vârf % din conexiuni
-- Deoarece mai mulți factori de memorie se pot extinde pe baza max_connections (acum 2000), este bine să nu aveți această setare prea mare.
( Com_change_db / Connections ) = 25.413 / 311 = 81,7
-- Comutări de baze de date per conexiune
-- (minor) Luați în considerare utilizarea sintaxei „db.table”.
( Aborted_connects / Connections ) = 227 / 311 = 73,0%
-- Poate că un hacker încearcă să intre? (Incercari de conectare)
Anormal de mic:
10 * read_buffer_size = 0,6 MB
Com_insert = 4,4 /HR
Handler_read_next = 16 /sec
Innodb_buffer_pool_reads * innodb_page_size / innodb_buffer_pool_size = 0,47%
Innodb_dblwr_pages_written = 0
Innodb_rows_updated = 0,62 /HR
back_log / max_connections = 4,0%
innodb_doublewrite_files = 0
innodb_doublewrite_pages = 0
Anormal de mare:
Com_create_db = 0,21 /HR
Com_create_table = 92 /HR
Com_show_charsets = 1,7 /HR
Com_show_plugins = 0,41 /HR
Com_show_storage_engines = 0,41 /HR
Innodb_buffer_pool_pages_free = 2,48e+6
Innodb_system_rows_deleted = 0,1 /sec
Innodb_system_rows_inserted = 0,1 /sec
Innodb_system_rows_updated = 0,32 /sec
Ssl_accepts = 304
Ssl_default_timeout = 7.200
Ssl_finished_accepts = 304
Ssl_session_cache_hits = 290
Ssl_session_cache_timeouts = 5
Ssl_verify_depth = 4,29e+9
Ssl_verify_mode = 5
gtid_executed_compression_period = 0,058 /sec
innodb_thread_concurrency = 21
max_error_count = 1.024
max_length_for_sort_data = 4.096
optimizer_trace_offset = --1
performance_schema_max_cond_classes = 100
performance_schema_max_mutex_classes = 300
performance_schema_max_rwlock_classes = 60
performance_schema_max_stage_classes = 175
performance_schema_max_statement_classes = 218
performance_schema_max_thread_classes = 100
Corzi anormale:
event_scheduler = ON
ft_boolean_syntax = + -><()~*:\"\"&
have_query_cache = NU
innodb_fast_shutdown = 1
innodb_temp_tablespaces_dir = .\#innodb_temp\
sistem_de_fișiere_minuscule = ON
nume_tabele_minuscule = 1
mysqlx_compression_algorithms = DEFLATE_STREAM, LZ4_MESSAGE,ZSTD_STREAM
Optimizer_trace = activat=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
protocol_compression_algorithms = zlib,zstd,necomprimat
slave_rows_search_algorithms = INDEX_SCAN,HASH_SCAN