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