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 (lucabert@lucabert.de)