On Thu, Mar 5, 2020 at 9:06 AM Luca Bertoncello <[email protected]> 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: > 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. > 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 > ([email protected]) > >
