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
select * from MyTable where pk = 123durchschnittlich?global status, ob etwas mit der zunehmenden CPU-Auslastung zusammenhängt. Ich glaube nicht, dass mit den derzeit verfügbaren Daten etwas erreicht werden kann. Ich werde eine andere Frage stellen, wenn ich etwas Neues finde.Antworten:
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:
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 bietenSELECT,EXPLAIN SELECT ...undSHOW 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 von3,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 VARIABLESundSHOW GLOBAL STATUS? Mehr Diskussion hier .Analyse von VARIABLEN & STATUS
(Entschuldigung, nichts springt heraus, wenn Sie Ihre Frage beantworten.)
Beobachtungen:
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? 70Threads_runningzeigt an, dassSHOWdas 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 SchemaUngewöhnlich groß: (Die meisten davon sind auf ein sehr ausgelastetes System zurückzuführen.)
(Fortsetzung)
quelle
innodb_flush_log_at_trx_commit = 2scheint keine Auswirkung zu haben und Thread-Konflikte scheinen auch nicht das Problem zu sein, da selbst bei mäßigen Lasten (Threads runnig <50) CPU-System / CPU-Benutzer so etwas wie 3 bis 1.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 esjemallocstattdessenglibcund das Problem verschwand. Wir arbeiten seitjemallocmehr 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 sollteMySQL. Aber es scheint, als ob unser spezieller Fallglibceinfach nicht richtig funktioniert hat.quelle
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.
quelle
Vorschläge für den Abschnitt my.cnf / ini [mysqld] für Ihren SEHR BESETZTEN
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.
quelle
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
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.
quelle
Ihr SHOW GLOBAL STATUS zeigt an, dass innodb_buffer_pool_pages_dirty 4.291.574 waren.
Um die aktuelle Anzahl zu überwachen,
Um diese Anzahl zu reduzieren,
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.
quelle