Batch Schreibzugriffe auf die SQL Datenbank: mdl_block_exacompdescrexamp_mm Table

[GGeorggg]

Hallo

könntet ihr euch das das bitte anschauen: ich hab mir einen Export der mdl_block_exacompdescrexamp_mm Tabelle geholt hier ein Auszug:

"id"	"descrid"	"exampid"	"sorting"	"id_foreign"	"table_foreign"
...	...	...	...	...
24653008	5544	1450698	0
24653009	5754	1450698	0
24653010	5755	1450698	0
24653011	5756	1450698	0
...	...	...	...	...

kurz später sehe ich dann SQL Queries vom moodle cron:

DELETE FROM mdl_block_exacompdescrexamp_mm WHERE exampid = '1450698'
INSERT INTO mdl_block_exacompdescrexamp_mm (exampid,descrid) VALUES('1450698','5544')
INSERT INTO mdl_block_exacompdescrexamp_mm (exampid,descrid) VALUES('1450698','5754')
INSERT INTO mdl_block_exacompdescrexamp_mm (exampid,descrid) VALUES('1450698','5755')
INSERT INTO mdl_block_exacompdescrexamp_mm (exampid,descrid) VALUES('1450698','5756')

Könntet ihr das als

UPDATE mdl_block_exacompdescrexamp_mm set descrid = @descrid where mdl_block_exacompdescrexamp_mm.exampid = @exampid and mdl_block_exacompdescrexamp_mm.descrid != @descrid;

umbauen.

Passiert im Moment ca alle zwei Sekunden per Cron Job - nicht dramatisch aber erzeugt mehr Writes als notwendig und die reichen wir weiter an alle Slave Datenbanken

denke das passiert hier:

https://github.com/gtn/exacomp/blob/b849004ab35fc2ba649599f2dcac7a594a14658e/classes/data.php#L2869-L2882 die

[richardwolfmayr]

Vielen Dank für die Hinweise. Das Problem ist folgendes Szenario: Ein Example ist zu den Descriptoren 1 und 2 zugeteilt. Es gibt also 2 Einträge für die gleiche exampleid. Der Raster wird in Komet verändert und das Example ist nun zu den Descriptoren 3 und 4 zugeteilt. Der Raster wird neu in Moodle importiert. Mit Update können wir die nicht mehr vorhandenen Verbindungen zu Descriptor 1 und 2 nicht löschen. Außerdem würde der vorgeschlagene Update Befehl ja immer alle Einträge für eine exampleid betreffen, und damit alle Einträge auf genau eine Descriptorid ändern, wenn ich das richtig verstehe.

Wir haben nun eine andere Optimierung, damit nicht andauernd gelöscht und neu inserted wird, was ja im Normalfall bei den Imports passieren wird.

Was meinen Sie mit "Passiert im Moment ca alle zwei Sekunden per Cron Job"?

[GGeorggg]

Hallo @richardwolfmayr

Das Problem ist folgendes Szenario: Ein Example ist zu den Descriptoren 1 und 2 zugeteilt. Es gibt also 2 Einträge für die gleiche exampleid. Der Raster wird in Komet verändert und das Example ist nun zu den Descriptoren 3 und 4 zugeteilt. Der Raster wird neu in Moodle importiert. Mit Update können wir die nicht mehr vorhandenen Verbindungen zu Descriptor 1 und 2 nicht löschen. Außerdem würde der vorgeschlagene Update Befehl ja immer alle Einträge für eine exampleid betreffen, und damit alle Einträge auf genau eine Descriptorid ändern, wenn ich das richtig verstehe.

ich kenne leider die Userstory dahinter zu wenig, um hier eine qualitativen Beitrag zu leisten (ich komme von der Ops/DBA Seite) und bin kein Moodle Anwender.

Wir haben nun eine andere Optimierung, damit nicht andauernd gelöscht und neu inserted wird, was ja im Normalfall bei den Imports passieren wird. Perfekt, wenn wir writes so gut wie möglich vermeiden können ist das eine gute Optimierung. Die Writes skalieren einfach nicht und die vielen DELETE/INSERTS werden auch auf allen replizierten Datenbanken durchgeführt, das führt zu höheren Verzögerungen und großen Logs. Das versuchen wir weitgehend zu reduzieren um die Performance/Kosten akzeptable zu halten, daher der CR.

Hast du eine CommitID/Release, damit ich prüfen kann wann wir das Update ausrollen und ggf Datenbank Performance nochmals reviewen können ?

Was meinen Sie mit "Passiert im Moment ca alle zwei Sekunden per Cron Job"? der Cron Job (ich vermute das ist \block_exacomp\task\autotest) ist je nach Last ca 30-35 Minuten aktiv und wird jede volle Stunde gestartet - der Job läuft also zu 50% der Zeit und erzeugt alle zwei Sekunden ein DELTE und paar INSERTs. Das macht ziemlich viel Log in einem Tag, das würde wir gerne vermeiden.

danke Georg

[richardwolfmayr]

Hast du eine CommitID/Release

Die Optimierung ist noch in Arbeit, ich werde hier informieren wenn es fertig und in 4.6.6 ist.

der Cron Job (ich vermute das ist \block_exacomp\task\autotest) ist je nach Last ca 30-35 Minuten aktiv

Danke. Zur Autotest-Funktionalität gibt es bereits weitreichende Veränderungen. Seit Version 2022021000 existiert der Task "autotest" nicht mehr, da das nun eleganter/performanter mit Events gelöst ist.