Während der Arbeit an einem lokalen Container, in den ich Daten aus einem SMF2-Forum mit über 20 Jahren Aktivität importiert habe, bin ich auf einen Showstopper-Bug bei Topic.reset_all_highest gestoßen.
Nach dem Datenimport zeigt meine Datenbank etwa 60.000 reguläre Themen und etwa 400.000 private Nachrichten-Themen an, und die Abfragen in Topic.reset_all_highest verursachen eine Art geometrisches Wachstum der Zeilen, mit dem Ergebnis, dass mein Speicherplatz zur Neige geht (obwohl ich anfangs 120 GB frei hatte).
Ich versuche derzeit, die Abfragen in überschaubare Blöcke aufzuteilen und sie direkt in Postgres auszuführen, aber das ist natürlich suboptimal (und ich bin mir nicht sicher, ob es überhaupt funktioniert und die richtigen Ergebnisse liefert).
Ich habe versucht herauszufinden, ob andere dieses Problem hatten, aber nichts gefunden, daher frage ich mich, ob dies irgendwie mit meinem eigenen Setup zusammenhängen könnte – ich verwende übrigens die neueste Docker-Version.
Ich habe kürzlich einen Import von bescheidener Größe durchgeführt, der anscheinend unbegrenzt bei Topic.reset_all_highest hängt und ich musste die Abfrage in Postgres beenden, um fortzufahren. Ich hatte dieses Problem bisher nicht und dachte, dass es vielleicht daran lag, dass mein Postgres-Server überlastet war (er hat eine Reihe von verbundenen Websites).
Mein nächster Schritt war, zu einem anderen Postgres-Server zu wechseln, aber dazu bin ich noch nicht gekommen.
Nachdem die ersten beiden Teile meines “Split Query”-Experiments reibungslos verliefen (X und Y für öffentliche Themen), habe ich es mit dem Z-Teil versucht, und es fror ein – das heißt, die Abfrage war laut PostgreSQL-Aktivität aktiv und top zeigte den Prozess mit 100% Auslastung an.
Also habe ich mir die SQL noch einmal angesehen und das Problem gefunden: beide Abfragen enden so
WHERE
topics.archetype <> 'private_message' AND
X.topic_id = topics.id AND
Y.topic_id = topics.id AND
(
topics.highest_staff_post_number <> X.highest_post_number OR
topics.highest_post_number <> Y.highest_post_number OR
topics.last_posted_at <> Y.last_posted_at OR
topics.posts_count <> Y.posts_count OR
topics.word_count <> Z.word_count
)
(die andere hat natürlich ‘private_message’ als Archetyp)
Was bedeutet, dass der Abfrage fehlt
Z.topic_id = topics.id – was die gesamte geometrische Zunahme verursacht.
Ändern der WHERE-Klausel der Abfragen zu
WHERE
topics.archetype <> 'private_message' AND
X.topic_id = topics.id AND
Y.topic_id = topics.id AND
Z.topic_id = topics.id AND
(
topics.highest_staff_post_number <> X.highest_post_number OR
topics.highest_post_number <> Y.highest_post_number OR
topics.last_posted_at <> Y.last_posted_at OR
topics.posts_count <> Y.posts_count OR
topics.word_count <> Z.word_count
)
hat das Problem für mich behoben.
Soll ich einen PR öffnen?
Ich würde sagen ja. Wenn Sie einen Commit finden könnten, der das kaputt gemacht hat, wäre das noch überzeugender.
Ich habe einen PR dafür geöffnet, mit einigen unglücklichen Einschränkungen (d. h. ich kann mir nicht vorstellen, wie ich diese Änderung testen kann).
Diese Änderung sieht korrekt aus, ich werde sie zusammenführen.
(Testtechnisch sollte es eine Abdeckung geben und ein einfacher Test wäre ausreichend, um dies zu validieren. Wir müssen nur bestätigen, dass keine Regression auftritt.)