Am 05.03.2020 08:51, schrieb Markus Bergholz:
Hallo Markus
oh, das hört sich aber für eine db sehr inperformant an!
Das habe ich auch gedacht... Allerdings ist es nicht immer so...
Heute früh habe ich wieder probiert: 1938981 Zeilen in 21 Sekunden...
Trotzdem konnten weitere SQL-Anfragen (INSERT) nicht sofort durchgeführt
werden.
Zur Klärung:
1) die SQL-Anfragen, die nicht sofort durchgeführt werden können, sind
INSERT in eine Tabelle (value_current), die vom Stored Procedure auch
bearbeitet wird
2) die Stored Procedure _LIEST_ einige Daten aus der Tabelle
value_current und speichert sie in eine andere Tabelle
(value_aggregat1), dann _LIEST_ die restliche Daten aus value_current
und speichert sie in eine temporäre Tabelle (value_current_1), die
später per RENAME in value_current geändert wird (die frühere
value_current wird in value_current_old umbenannt). Schließlich wird die
value_current_old per DROP vernichtet.
wenn das stored procedure 30k zeilen aktualisiert, ist das gesamte
remote i/o geblockt.
Ich könnte es mir vorstellen, dass eine kurze Sperrung während der
RENAME stattfindet, das ist aber nicht der Fall... Die Sperrung findet
tatsächlich während der Lesung aus value_current und Speicherung in
value_aggregat1 bzw. value_current_1.
Das ist für mich unerklärlich...
Und dass auch die Anfragen an _ANDEREN_ Datenbanken deswegen warten
müssen kann ich mir auch nicht erklären...
wie viel ram hat die kiste? innodb_pool_buffer_size? passt die db in
den ram?
Der Server hat 24GB RAM.
Die Einstellungen sind:
innodb_buffer_pool_size = 16G
innodb_buffer_pool_instances = 4
innodb_log_file_size = 1G
innodb_log_buffer_size = 16M
innodb_file_per_table = 1
innodb_io_capacity = 2000
innodb_read_io_threads = 128
innodb_thread_concurrency = 0
innodb_write_io_threads = 128
innodb_use_native_aio = 0
Vorher war innodb_buffer_pool_size war nur 8GB. Nach der Verdoppelung
dauert die Stored Procedure deutlich weniger, aber die Zugriffe werden
weiterhin gesperrt...
Ideen?
Danke
Luca Bertoncello
(lucab...@lucabert.de)
