Hohe CPU-Systemzeitauslastung auf dem MySQL-Server

Eine kleine Hintergrundgeschichte: Vor einiger Zeit haben wir begonnen, in einer unserer MySQL-Datenbanken eine hohe CPU-Systemzeit zu erleben. Diese Datenbank litt auch unter einer hohen Festplattenauslastung, sodass wir herausfanden, dass diese Dinge miteinander verbunden sind. Und da wir bereits Pläne hatten, es auf SSD zu migrieren, dachten wir, dass es beide Probleme lösen wird.

Es hat geholfen ... aber nicht lange.

Für ein paar Wochen nach der Migration war das CPU-Diagramm wie folgt:

Aber jetzt sind wir wieder da:

Dies geschah aus dem Nichts ohne offensichtliche Änderungen der Last oder der Anwendungslogik.

DB-Statistiken:

• MySQL-Version - 5.7.20
• OS - Debian
• DB-Größe - 1,2 TB
• RAM - 700 GB
• CPU-Kerne - 56
• Peek Load - ca. 5kq / s lesen, 600q / s schreiben (obwohl ausgewählte Abfragen oft recht komplex sind)
• Threads - 50 laufen, 300 verbunden
• Es hat ungefähr 300 Tische, alle InnoDB

MySQL-Konfiguration:

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /opt/mysql-data
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
explicit_defaults_for_timestamp

sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

log-error = /opt/mysql-log/error.log

# Replication

server-id = 76

gtid-mode = ON
enforce-gtid-consistency = true

relay-log = /opt/mysql-log/mysql-relay-bin
relay-log-index = /opt/mysql-log/mysql-relay-bin.index
replicate-wild-do-table = dbname.%

log-bin = /opt/mysql-log/mysql-bin.log
expire_logs_days = 7
max_binlog_size = 1024M
binlog-format = ROW
log-bin-trust-function-creators = 1
log_slave_updates = 1

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

# Here goes

skip_name_resolve = 1
general_log = 0
slow_query_log = 1
slow_query_log_file = /opt/mysql-log/slow.log
long_query_time = 3

max_allowed_packet = 16M
max_connections = 700
max_execution_time = 200000

open_files_limit = 32000
table_open_cache = 8000
thread_cache_size = 128
innodb_buffer_pool_size = 550G
innodb_buffer_pool_instances = 28
innodb_log_file_size = 15G
innodb_log_files_in_group = 2
innodb_flush_method = O_DIRECT

max_heap_table_size = 16M
tmp_table_size = 128M
join_buffer_size = 1M
sort_buffer_size = 2M

innodb_lru_scan_depth = 256

query_cache_type = 0
query_cache_size = 0

innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:30G 

Andere Beobachtungen

Leistung des MySQL-Prozesses während der Spitzenlast:

68,31%    68,31%  mysqld  [kernel.kallsyms]    [k] _raw_spin_lock                                                                                                                                                                                                        
   - _raw_spin_lock                                                                                                                                                                                                                                                          
      + 51,63% 0x7fd118e9dbd9                                                                                                                                                                                                                                                
      + 48,37% 0x7fd118e9dbab                                                                                                                                                                                                                                                
+   37,36%     0,02%  mysqld  libc-2.19.so         [.] 0x00000000000f4bd9                                                                                                                                                                                                    
+   33,83%     0,01%  mysqld  libc-2.19.so         [.] 0x00000000000f4bab                                                                                                                                                                                                    
+   26,92%     0,00%  mysqld  libpthread-2.19.so   [.] start_thread                                                                                                                                                                                                          
+   26,82%     0,00%  mysqld  mysqld               [.] pfs_spawn_thread                                                                                                                                                                                                      
+   26,82%     0,00%  mysqld  mysqld               [.] handle_connection                                                                                                                                                                                                     
+   26,81%     0,01%  mysqld  mysqld               [.] do_command(THD*)                                                                                                                                                                                                      
+   26,65%     0,02%  mysqld  mysqld               [.] dispatch_command(THD*, COM_DATA const*, enum_server_command)                                                                                                                                                          
+   26,29%     0,01%  mysqld  mysqld               [.] mysql_parse(THD*, Parser_state*)                                                                                                                                                                                      
+   24,85%     0,01%  mysqld  mysqld               [.] mysql_execute_command(THD*, bool)                                                                                                                                                                                     
+   23,61%     0,00%  mysqld  mysqld               [.] handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long)                                                                                                                                       
+   23,54%     0,00%  mysqld  mysqld               [.] 0x0000000000374103                                                                                                                                                                                                    
+   19,78%     0,00%  mysqld  mysqld               [.] JOIN::exec()                                                                                                                                                                                                          
+   19,13%     0,15%  mysqld  mysqld               [.] sub_select(JOIN*, QEP_TAB*, bool)                                                                                                                                                                                     
+   13,86%     1,48%  mysqld  mysqld               [.] row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long)                                                                                                                       
+    8,48%     0,25%  mysqld  mysqld               [.] ha_innobase::general_fetch(unsigned char*, unsigned int, unsigned int)                                                                                                                                                
+    7,93%     0,00%  mysqld  [unknown]            [.] 0x00007f40c4d7a6f8                                                                                                                                                                                                    
+    7,57%     0,00%  mysqld  mysqld               [.] 0x0000000000828f74                                                                                                                                                                                                    
+    7,25%     0,11%  mysqld  mysqld               [.] handler::ha_index_next_same(unsigned char*, unsigned char const*, unsigned int)                                                                                                                                       

Es zeigt, dass MySQL viel Zeit mit spin_locks verbringt . Ich hatte gehofft, einen Hinweis darauf zu bekommen, woher diese Schlösser kommen, leider kein Glück.

Das Abfrageprofil bei hoher Last zeigt eine extreme Anzahl von Kontextwechseln. Ich habe select * aus MyTable verwendet, wobei pk = 123 ist. MyTable hat ungefähr 90 Millionen Zeilen. Profilausgabe:

Status               Duration CPU_user CPU_system Context_voluntary Context_involuntary Block_ops_in Block_ops_out Messages_sent Messages_received Page_faults_major Page_faults_minor Swaps Source_function       Source_file          Source_line
starting             0,000756 0,028000 0,012000   81                1                   0            0             0             0                 0                 0                 0                             
checking permissions 0,000057 0,004000 0,000000   4                 0                   0            0             0             0                 0                 0                 0     check_access          sql_authorization.cc 810
Opening tables       0,000285 0,008000 0,004000   31                0                   0            40            0             0                 0                 0                 0     open_tables           sql_base.cc          5650
init                 0,000304 0,012000 0,004000   31                1                   0            0             0             0                 0                 0                 0     handle_query          sql_select.cc        121
System lock          0,000303 0,012000 0,004000   33                0                   0            0             0             0                 0                 0                 0     mysql_lock_tables     lock.cc              323
optimizing           0,000196 0,008000 0,004000   20                0                   0            0             0             0                 0                 0                 0     optimize              sql_optimizer.cc     151
statistics           0,000885 0,036000 0,012000   99                6                   0            0             0             0                 0                 0                 0     optimize              sql_optimizer.cc     367
preparing            0,000794 0,000000 0,096000   76                2                   32           8             0             0                 0                 0                 0     optimize              sql_optimizer.cc     475
executing            0,000067 0,000000 0,000000   10                1                   0            0             0             0                 0                 0                 0     exec                  sql_executor.cc      119
Sending data         0,000469 0,000000 0,000000   54                1                   32           0             0             0                 0                 0                 0     exec                  sql_executor.cc      195
end                  0,000609 0,000000 0,016000   64                4                   0            0             0             0                 0                 0                 0     handle_query          sql_select.cc        199
query end            0,000063 0,000000 0,000000   3                 1                   0            0             0             0                 0                 0                 0     mysql_execute_command sql_parse.cc         4968
closing tables       0,000156 0,000000 0,000000   20                4                   0            0             0             0                 0                 0                 0     mysql_execute_command sql_parse.cc         5020
freeing items        0,000071 0,000000 0,004000   7                 1                   0            0             0             0                 0                 0                 0     mysql_parse           sql_parse.cc         5596
cleaning up          0,000533 0,024000 0,008000   62                0                   0            0             0             0                 0                 0                 0     dispatch_command      sql_parse.cc         1902

Peter Zaitsev hat kürzlich einen Beitrag über Kontextwechsel verfasst, in dem er sagt:

In der realen Welt würde ich mir jedoch keine Sorgen machen, dass Konflikte ein großes Problem darstellen, wenn Sie weniger als zehn Kontextwechsel pro Abfrage haben.

Aber es zeigt mehr als 600 Schalter!

Was kann diese Symptome verursachen und was kann dagegen getan werden? Ich freue mich über Hinweise oder Informationen zu diesem Thema. Alles, was mir bisher begegnet, ist ziemlich alt und / oder nicht schlüssig.

PS Gerne gebe ich bei Bedarf gerne weitere Informationen weiter.

Ausgabe von SHOW GLOBAL STATUS und SHOW VARIABLES

Ich kann es hier nicht posten, da der Inhalt die Postgrößenbeschränkung überschreitet.

GLOBAL STATUS
ANZEIGEN VARIABLEN ANZEIGEN

iostat

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7,35    0,00    5,44    0,20    0,00   87,01

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0,00     0,00    0,00    0,00     0,00     0,00     8,00     0,00   32,00   32,00    0,00  32,00   0,00
sda               0,04     2,27    0,13    0,96     0,86    46,52    87,05     0,00    2,52    0,41    2,80   0,28   0,03
sdb               0,21   232,57   30,86  482,91   503,42  7769,88    32,21     0,34    0,67    0,83    0,66   0,34  17,50

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9,98    0,00   77,52    0,46    0,00   12,04

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sda               0,00     1,60    0,00    0,60     0,00     8,80    29,33     0,00    0,00    0,00    0,00   0,00   0,00
sdb               0,00   566,40   55,60  981,60   889,60 16173,60    32,90     0,84    0,81    0,76    0,81   0,51  53,28

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11,83    0,00   72,72    0,35    0,00   15,10

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sda               0,00     2,60    0,00    0,40     0,00    12,00    60,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb               0,00   565,20   51,60  962,80   825,60 15569,60    32,32     0,85    0,84    0,98    0,83   0,54  54,56

Update 2018-03-15

> show global status like 'uptime%'
Uptime;720899
Uptime_since_flush_status;720899

> show global status like '%rollback'
Com_rollback;351422
Com_xa_rollback;0
Handler_rollback;371088
Handler_savepoint_rollback;0

600q / s Schreiben mit einem Flush pro Commit erreichen wahrscheinlich das Limit Ihrer aktuellen rotierenden Festplatten. Ein Wechsel zu SSDs würde den Druck entlasten.

Die schnelle Lösung (bevor Sie SSDs erhalten) besteht wahrscheinlich darin, diese Einstellung zu ändern:

innodb_flush_log_at_trx_commit = 2

Lesen Sie jedoch die Vorbehalte zu dieser Änderung.

Mit dieser Einstellung und SSDs können Sie weiter wachsen.

Eine andere mögliche Lösung besteht darin, einige Schreibvorgänge zu einem einzigen zu kombinieren COMMIT(wobei die Logik nicht verletzt wird).

Fast immer ist eine hohe CPU und / oder E / A auf schlechte Indizes und / oder eine schlechte Formulierung von Abfragen zurückzuführen. Schalten Sie das Slowlog mit ein long_query_time=1, warten Sie eine Weile und sehen Sie dann, was auftaucht. Mit Abfragen in der Hand bieten SELECT, EXPLAIN SELECT ...und SHOW CREATE TABLE. Das Gleiche gilt für die Schreibanfragen. Von diesen können wir wahrscheinlich die CPU und / oder E / A zähmen. Auch mit Ihrer aktuellen Einstellung von 3, pt-query-digestkönnten einige interessante Dinge finden.

Beachten Sie, dass bei 50 "laufenden" Threads viele Konflikte auftreten. Dies kann die von Ihnen notierte Umschaltung usw. verursachen. Wir müssen Anfragen bekommen, um schneller fertig zu werden. Mit 5,7, das System kann mehr als 100 mit Kiellaufgewinde. Bei einem Anstieg über 64 hinaus verschwören sich die Kontextwechsel, Mutexe, Sperren usw., um jeden Thread zu verlangsamen, was zu keiner Verbesserung des Durchsatzes führt, während die Latenz über das Dach geht.

Für einen anderen Ansatz zur Analyse des Problems geben Sie bitte SHOW VARIABLESund SHOW GLOBAL STATUS? Mehr Diskussion hier .

Analyse von VARIABLEN & STATUS

(Entschuldigung, nichts springt heraus, wenn Sie Ihre Frage beantworten.)

Beobachtungen:

• Version: 5.7.20-log
• 700 GB RAM
• Betriebszeit = 36d 13:21:34
• Sie laufen nicht unter Windows.
• Laufende 64-Bit-Version
• Sie scheinen InnoDB vollständig (oder größtenteils) auszuführen.

Die wichtigeren Themen:

Viele temporäre Tabellen, insbesondere festplattenbasierte, werden für komplexe Abfragen erstellt. Hoffen wir, dass das langsame Protokoll einige Abfragen identifiziert, die verbessert werden können (über Indizierung / Neuformulierung / usw.). Andere Indikatoren sind Verknüpfungen ohne Indizes und sort_merge_passes. Keines davon ist jedoch schlüssig. Wir müssen die Abfragen sehen.

Max_used_connections = 701ist> = Max_connections = 700, also wurden wahrscheinlich einige Verbindungen abgelehnt. Wenn dies darauf hinweist, dass mehr als beispielsweise 64 Threads ausgeführt werden , leidet die Systemleistung zu diesem Zeitpunkt wahrscheinlich. Erwägen Sie, die Anzahl der Verbindungen zu drosseln, indem Sie die Clients drosseln. Verwenden Sie Apache, Tomcat oder etwas anderes? 70 Threads_runningzeigt an, dass SHOWdas System zum Zeitpunkt der Ausführung in Schwierigkeiten war.

Das Erhöhen der Anzahl der Anweisungen in jeder Anweisung COMMIT(wenn dies angemessen ist) kann zur Leistungssteigerung beitragen.

innodb_log_file_sizeist mit 15 GB größer als nötig, aber ich sehe keine Notwendigkeit, es zu ändern.

Tausende von Tischen sind normalerweise kein gutes Design.

eq_range_index_dive_limit = 200betrifft mich, aber ich weiß nicht, wie ich beraten soll. War es eine bewusste Entscheidung?

Warum so viele CREATE + DROP PROCEDURE?

Warum so viele SHOW-Befehle?

Details und andere Beobachtungen:

( Innodb_buffer_pool_pages_flushed ) = 523,716,598 / 3158494 = 165 /sec - Schreibt (Flushes) - überprüft innodb_buffer_pool_size

( table_open_cache ) = 10,000 - Anzahl der zu zwischenspeichernden Tabellendeskriptoren - Mehrere hundert sind normalerweise gut.

( (Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed) ) = ((61,040,718 + 523,716,598) ) / 3158494 = 185 /sec - InnoDB I / O.

( Innodb_dblwr_pages_written/Innodb_pages_written ) = 459,782,684/523,717,889 = 87.8% - Scheint, als sollten diese Werte gleich sein?

( Innodb_os_log_written ) = 1,071,443,919,360 / 3158494 = 339226 /sec- Dies ist ein Indikator dafür, wie beschäftigt InnoDB ist. - Sehr beschäftigt InnoDB.

( Innodb_log_writes ) = 110,905,716 / 3158494 = 35 /sec

( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 1,071,443,919,360 / (3158494 / 3600) / 2 / 15360M = 0.0379 - Verhältnis - (siehe Protokoll)

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 3,158,494 / 60 * 15360M / 1071443919360 = 791- Minuten zwischen InnoDB-Protokollrotationen Ab 5.6.8 kann dies dynamisch geändert werden. Stellen Sie sicher, dass Sie auch my.cnf ändern. - (Die Empfehlung von 60 Minuten zwischen den Umdrehungen ist etwas willkürlich.) Passen Sie innodb_log_file_size an. (Kann in AWS nicht geändert werden.)

( Com_rollback ) = 770,457 / 3158494 = 0.24 /sec- ROLLBACKs in InnoDB. - Eine übermäßige Häufigkeit von Rollbacks kann auf eine ineffiziente App-Logik hinweisen.

( Innodb_row_lock_waits ) = 632,292 / 3158494 = 0.2 /sec- Wie oft gibt es eine Verzögerung beim Abrufen einer Zeilensperre. - Kann durch komplexe Abfragen verursacht werden, die optimiert werden könnten.

( Innodb_dblwr_writes ) = 97,725,876 / 3158494 = 31 /sec- "Doublewrite Buffer" schreibt auf die Festplatte. "Doublewrites" sind ein Zuverlässigkeitsmerkmal. Einige neuere Versionen / Konfigurationen benötigen sie nicht. - (Symptom anderer Probleme)

( Innodb_row_lock_current_waits ) = 13- Die Anzahl der Zeilensperren, auf die derzeit von Operationen an InnoDB-Tabellen gewartet wird. Null ist ziemlich normal. - Ist etwas Großes los?

( innodb_print_all_deadlocks ) = OFF- Ob alle Deadlocks protokolliert werden sollen. - Wenn Sie von Deadlocks geplagt sind, schalten Sie diese ein. Achtung: Wenn Sie viele Deadlocks haben, kann dies viel auf die Festplatte schreiben.

( local_infile ) = ON - local_infile = ON ist ein potenzielles Sicherheitsproblem

( bulk_insert_buffer_size / _ram ) = 8M / 716800M = 0.00%- Puffer für mehrzeilige INSERTs und LOAD DATA - Zu groß kann die RAM-Größe gefährden. Zu klein könnte solche Operationen behindern.

( Questions ) = 9,658,430,713 / 3158494 = 3057 /sec- Abfragen (außerhalb von SP) - "qps" -> 2000 belasten möglicherweise den Server

( Queries ) = 9,678,805,194 / 3158494 = 3064 /sec- Abfragen (einschließlich innerhalb von SP) -> 3000 können den Server belasten

( Created_tmp_tables ) = 1,107,271,497 / 3158494 = 350 /sec - Häufigkeit der Erstellung von "temporären" Tabellen als Teil komplexer SELECTs.

( Created_tmp_disk_tables ) = 297,023,373 / 3158494 = 94 /sec- Häufigkeit der Erstellung von "temporären" Datenträgertabellen als Teil komplexer SELECTs - Erhöhen Sie tmp_table_size und max_heap_table_size. Überprüfen Sie die Regeln für temporäre Tabellen, wenn MEMORY anstelle von MyISAM verwendet wird. Möglicherweise können geringfügige Schema- oder Abfrageänderungen MyISAM vermeiden. Bessere Indizes und eine Neuformulierung von Abfragen helfen eher.

( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (693300264 + 214511608 + 37537668 + 0) / 1672382928 = 0.565- Anweisungen pro Commit (unter der Annahme aller InnoDB) - Niedrig: Kann helfen, Abfragen in Transaktionen zu gruppieren. Hoch: Lange Transaktionen belasten verschiedene Dinge.

( Select_full_join ) = 338,957,314 / 3158494 = 107 /sec - Verknüpfungen ohne Index - Fügen Sie den in JOINs verwendeten Tabellen geeignete Indizes hinzu.

( Select_full_join / Com_select ) = 338,957,314 / 6763083714 = 5.0% -% der Auswahlen, die indexlos verknüpft sind - Fügen Sie den in JOINs verwendeten Tabellen geeignete Indizes hinzu.

( Select_scan ) = 124,606,973 / 3158494 = 39 /sec - vollständige Tabellenscans - Hinzufügen von Indizes / Optimieren von Abfragen (es sei denn, es handelt sich um winzige Tabellen)

( Sort_merge_passes ) = 1,136,548 / 3158494 = 0.36 /sec - Schwere Sortierungen - Erhöhen Sie sort_buffer_size und / oder optimieren Sie komplexe Abfragen.

( Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi ) = (693300264 + 37537668 + 198418338 + 0 + 214511608 + 79274476) / 3158494 = 387 /sec - Schreibvorgänge / Sek. - 50 Schreibvorgänge / Sek. + Protokollspülungen maximieren wahrscheinlich die E / A-Schreibkapazität normaler Laufwerke

( ( Com_stmt_prepare - Com_stmt_close ) / ( Com_stmt_prepare + Com_stmt_close ) ) = ( 39 - 38 ) / ( 39 + 38 ) = 1.3%- Schließen Sie Ihre vorbereiteten Aussagen? - Closes hinzufügen.

( Com_stmt_close / Com_stmt_prepare ) = 38 / 39 = 97.4%- Vorbereitete Anweisungen sollten geschlossen werden. - Überprüfen Sie, ob alle vorbereiteten Anweisungen "geschlossen" sind.

( innodb_autoinc_lock_mode ) = 1- Galera: Wünsche 2 - 2 = "verschachtelt"; 1 = "aufeinanderfolgend" ist typisch; 0 = "traditionell".

( Max_used_connections / max_connections ) = 701 / 700 = 100.1% - Peak% der Verbindungen - Erhöhen Sie max_connections und / oder verringern Sie wait_timeout

( Threads_running - 1 ) = 71 - 1 = 70 - Aktive Threads (Parallelität bei der Datenerfassung) - Optimieren von Abfragen und / oder Schema

Ungewöhnlich groß: (Die meisten davon sind auf ein sehr ausgelastetes System zurückzuführen.)

Com_commit = 529 /sec
Com_create_procedure = 0.01 /HR
Com_drop_procedure = 0.01 /HR
Com_delete = 12 /sec
Com_delete_multi = 63 /sec
Com_insert = 219 /sec
Com_kill = 0.69 /HR
Com_reset = 0.0011 /HR
Com_revoke = 0.0023 /HR
Com_select = 2141 /sec
Com_show_binlogs = 12 /HR
Com_show_create_func = 0.011 /HR
Com_show_privileges = 0.0034 /HR
Com_show_profile = 0.027 /HR
Com_show_profiles = 0.028 /HR
Com_show_slave_status = 0.037 /sec
Com_show_storage_engines = 12 /HR
Com_show_warnings = 0.14 /sec
Com_slave_stop = 0.0011 /HR
Com_update_multi = 25 /sec
Created_tmp_files = 0.3 /sec
Handler_commit = 3251 /sec
Handler_external_lock = 18787 /sec
Handler_prepare = 615 /sec
Handler_read_first = 239 /sec
Handler_read_key = 173669 /sec
Handler_read_next = 1291439 /sec
Handler_read_prev = 28535 /sec
Handler_read_rnd = 32789 /sec

(Fortsetzung)

Innodb_buffer_pool_bytes_dirty = 7.03e+10
Innodb_buffer_pool_pages_data = 3.41e+7
Innodb_buffer_pool_pages_dirty = 4.29e+6
Innodb_buffer_pool_pages_misc = 2.15e+6
Innodb_buffer_pool_pages_total = 3.62e+7
Innodb_data_fsyncs = 132 /sec
Innodb_data_writes = 232 /sec
Innodb_data_written = 5440151 /sec
Innodb_dblwr_pages_written = 145 /sec
Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group = 582.3MB
Innodb_pages_written = 165 /sec
Innodb_row_lock_time = 5.97e+7
Innodb_rows_deleted + Innodb_rows_inserted = 2180 /sec
Innodb_rows_inserted = 2155 /sec
Innodb_rows_read = 1398531 /sec
Max_used_connections = 701
Open_tables = 10,000
Select_full_range_join = 2.57e+7
Select_range = 130 /sec
Sort_range = 30 /sec
Sort_scan = 332 /sec
Table_open_cache_hits = 9354 /sec
Threads_running = 71
eq_range_index_dive_limit = 200
innodb_purge_threads = 4
innodb_thread_sleep_delay = 16,925

Wir haben nie herausgefunden, was genau die Ursache für dieses Problem war, aber um einen Abschluss anzubieten, werde ich sagen, was ich kann.

Unser Team führte einige Auslastungstests durch und kam zu dem Schluss, dass MySQLProbleme bei der Speicherzuweisung aufgetreten sind. Also versuchten sie es jemallocstattdessen glibcund das Problem verschwand. Wir arbeiten seit jemallocmehr als 6 Monaten in der Produktion, ohne dieses Problem jemals wieder zu sehen.

Ich sage nicht, dass jemallocdas besser ist oder dass jeder es mit verwenden sollte MySQL. Aber es scheint, als ob unser spezieller Fall glibceinfach nicht richtig funktioniert hat.

Meine 2 Cent.

Führen Sie "iostat -xk 5" aus, um festzustellen, ob die Festplatte immer noch ein Problem darstellt. Auch das CPU-System hängt mit dem Systemcode (Kernell) zusammen. Überprüfen Sie die neue Festplatte / Treiber / Konfiguration.

Vorschläge für den Abschnitt my.cnf / ini [mysqld] für Ihren SEHR BESETZTEN

max_heap_table_size=128M  # from 16M to match tmp_table_size
innodb_lru_scan_depth=100  # from 256 to reduce depth every second
innodb_change_buffer_max_size=15  # from 25 max used misc is 6%
innodb_flush_neighbors=0  # from 1 with SSD there is no rotational delay
innodb_read_ahead_threshold=8  # from 56 to expedite RD nxt extent
read_rnd_buffer_size=128K  # from 256K to reduce RD RPS

Meine Erwartung ist eine allmähliche Abnahme der Ergebnisse von SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_pages_dirty'; mit diesen Vorschlägen angewendet. Am 13.01.18 hatten Sie über 4 Millionen schmutzige Seiten.

Ich hoffe diese helfen. Diese können dynamisch geändert werden. Es gibt noch viele weitere Möglichkeiten, wenn Sie sie möchten, lassen Sie es mich wissen.

Wenn IOPS bei 30 KB getestet wurde (wir benötigen eine Reihe von IOPS für zufällige Schreibvorgänge), sollten Sie diesen Vorschlag für den Abschnitt my.cnf / ini [mysqld] berücksichtigen

innodb_io_capacity_max=20000  # from 2000 and keep top 10000 free for now
innodb_io_capacity=10000  # from 200 to ensure we stay away from the limits

kann mit SET GLOBAL dynamisch geändert werden und sollte innodb_buffer_pool_pages_dirty schnell reduzieren.

Die Ursache für COM_ROLLBACK mit einem Durchschnitt von 1 alle 4 Sekunden bleibt ein Leistungsproblem, bis es behoben ist.

@chimmi 9. April 2018 Holen Sie sich dieses MySQL-Skript von https://pastebin.com/aZAu2zZ0, um einen schnellen Überblick über die in SLEEP festgelegten oder freigegebenen Ressourcen für den globalen Status zu erhalten, die für nn Sekunden festgelegt wurden. Auf diese Weise können Sie feststellen, ob jemand dazu beigetragen hat, die Häufigkeit von COM_ROLLBACK zu verringern. Möchte von Ihnen per E-Mail hören.

Ihr SHOW GLOBAL STATUS zeigt an, dass innodb_buffer_pool_pages_dirty 4.291.574 waren.

Um die aktuelle Anzahl zu überwachen,

SHOW GLOBAL STATUS LIKE '%pages_dirty';

Um diese Anzahl zu reduzieren,

SET GLOBAL innodb_flushing_avg_loops=5;

Führen Sie in einer Stunde die Monitoranforderung aus, um festzustellen, wo Sie mit schmutzigen Seiten stehen.

Bitte teilen Sie mir Ihre Zählungen zu Beginn und eine Stunde später mit.

Wenden Sie die Änderung auf Ihre my.cnf an, um die Seitenverschmutzungsreduzierung langfristig zu verbessern.