On Thu, Mar 5, 2020 at 9:06 AM Luca Bertoncello lucabert@lucabert.de wrote:
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:
- 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.
das rename kannst du dir sparen, wenn du einfach eine view value_current anlegst, die dann auf die richtig value_current tabelle zeigt. unter oracle heißt das synonym. oder mysql/mariadb gibt es das leider nicht. aber einen ähnlichen workflow haben wir auch mit 27mio zeilen. das arbeiten mit der view ohne rename beschleunigt den gesamt prozess drastisch bei uns. das funktioniet allerdings dann nur für lesende prozesse. wenn ihr schreibende habt, müsstest du die zugrunde liegende tabelle dann dynamisch ermitteln und verwenden.
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...
das mit dem gesperrten zugriff erschließt sich mir nicht. ich habe da auch leider keine andere idee und habe nach wie vor den remote storage in verdacht.
Ideen?
Danke Luca Bertoncello (lucabert@lucabert.de)