Toblerone
Samstag, 19. April 2008
MySQL, anyone?
I need a little bit of help from a MySQL-savvy person, so please forgive me the technical mumbo-jumbo following below.

The database update which is necessary for the Antville 1.2 upgrade takes long. Very long. Too long. I started it yesterday at 1:30 in the night and it is still running.

Well, you might say, haven't you written the update script yourself? Aren't you the guy who should know why it's running so slowly?

But I am really pretty clueless right now. Because all I am doing is issueing quite simple select, update and insert statements.

The problem might be, though, that it's Millions of them. During the first few hours everything goes quite smoothly, but after that each bulk of inserts or updates to a table (especially the one containing all the lovely postings of the Antville.org community) is interrupted with a break of a few minutes at first which in the meantime even exceeds ten minutes.

Thus, the update is taking longer and longer and longer. And of course I don't want Antville.org to be down for such a long time.

I already tried different things I found on various websites and in the depths of the MySQL documentation, even with some success in speeding up things a little bit.

But it's still not working out...

So my urgent request is: if you know how to optimize MySQL performance pretty good or you know someone else who does, please please please get in touch with me as soon as possible.

... Comment

bei Massen
von Inserts bzw. Updates sollten Sie vorher alle Indexe, die nicht unbedingt gebraucht werden, löschen.

Zwar keine Erfahrung mit MySQL, aber sowas ist allgemein. Aber das wußten Sie sicherlich schon, ich wollts aber trotzdem gesagt haben, weil es genau danach klang.

... Link

Ja, darauf bin ich schon gekommen
Ich lege daher bei der problematischsten Tabelle schon gleich eine neue Tabelle ohne Index-Keys an, in der die Daten reinkopiert werden. Das hat die Sache zwar etwas beschleunigt, am Schluss warte ich trotzdem mehr als 10 Minuten zwischen zwei Update-Bulks (10.000 Records).

... Link


... Comment
not that i would like to apply for this job (i'm not more than an ambitious amateur in this area, and certainly there are people out there knowing much more), but i guess that upgrading to innodb would probably be a good move before doing the update. mainly because afaik innodb doesn't lock the whole table during inserts/updates/deletes (as myisam does). in addition iirc antville uses a "text" column in AV_TEXT, which might prevent mysql using a much faster in-memory table (more on this).

... Link

InnoDB
is a good idea, I guess – one I will try out for sure. However, shouldn't it be okay if the tables are locked during the update, ie. as long as there is no other thread trying to access the same table?

I will read into the "text" column thingy, maybe this could bring some improvements, too.

... Link


... Comment
Was genau hast du denn vor? Kann man irgendwo dein derzeitiges Update-Skript/Query einsehen?

... Link

Hier der problematische Teil vom Update-Skript.

Zunächst wird eine neue Tabelle "content" ohne Index-Keys angelegt, in die mittels "insert into ... select" die Records überführt werden.

Zäh wird es dann ab Z. 336: der Platzhalter "#!content" wird mit folgendem Pseudo-Code ersetzt:
  1. Select 10.000 Records vom Table "content"
  2. Konvertiere die Records
  3. Update Table "content" mit konvertierten Records für jede ID

    ... Link

    Ich verstehe zwar nicht ganz, was du da mit #AV_TEXT und #content usw. machst...

    Aber kannst du nicht einfach die benötigten Spalten in die Tabelle einfügen und dann mit Werten füllen (und nicht eine neue Tabelle anlegen und alles kopieren)?

    Mehrere tausend Zeilen kopieren dauert halt seine Zeit... :-)

    ... Link

    Könnte man meinen, aber im Gegenteil: das Kopieren in eine neue Tabelle hat einen ziemlichen Geschwindigkeitsschub gebracht. Ist sozusagen eine frische Tabelle, ohne Altlasten.

    Außerdem kann ich so von der einen Tabelle lesen und in die andere schreiben, was von Vorteil zu sein scheint, da andernfalls immer eine gewisse Latenz zu beobachten ist, bis MySQL die soeben beschriebene Tabelle wieder lesen kann.

    Zudem hab ich nun einige Index-Keys während des Updates deaktiviert, damit die nicht zuviel Zeit in Anspruch nehmen.

    Sehr geholfen hat dann auch das Schrauben an einigen MySQL-Settings.

    Jetzt könnte ein komplettes Update in 2 bis 3 Stunden zu schaffen sein...

    ... Link

    Zu früh gefreut
    Die ersten 700.000 Records der Content-Table gingen wirklich flott, in dem Tempo wäre das Update sogar unter 2 Stunden durchgelaufen.

    Leider wurde dann aber jedes Update zunehmend langsamer; um kurz nach 19 Uhr ging's los, und es ist immer noch am Laufen.

    Derzeit liegen die Pausen zwischen zwei Updates von 5000 Records wieder bei unsäglichen 5 bis 10 Minuten...
    :(

    ... Link

    versuch doch mal das slow query log aufzudrehen (setz halt die minimalzeit auf 1 minute oder so), und lass dann das update laufen. vielleicht gibt das einen hinweis auf fehlende/falsch gesetzte indexes.

    ... Link

    Hab ich mal gemacht
    Mir ist dabei nur aufgefallen, dass die Select-Statements immer langsamer werden, je höher "offset" im statement wird:

    select id, xml, metadata from content order by id limit 5000 offset 230000
    2609 millis

    select id, xml, metadata from content order by id limit 5000 offset 1225000
    428386 millis

    Daher versuch ich gerade, ob ich einen Geschwindigkeitszuwachs erreichen kann, wenn ich den AV_TEXT-Table immer ohne Offset lese, und stattdessen jeden konvertierten Record dort lösche.

    Dadurch benötigen die Updates zwar etwas länger, aber vielleicht macht sich der immer kleiner werdende AV_TEXT-Table bezahlt...

    ... Link

    Spooky
    Beim Konvertieren der Topics zu Tags werden die Selects interessanterweise auch wieder schneller:

    select topic, tag.id, content.id as tagged_id, modifier_id, creator_id, content.site_id from content, tag where topic is not null and topic = tag.name and tag.type = 'Story' limit 5000 offset 1355000
    272085 millis

    select topic, tag.id, content.id as tagged_id, modifier_id, creator_id, content.site_id from content, tag where topic is not null and topic = tag.name and tag.type = 'Story' limit 5000 offset 1360000
    4583 millis

    Faszinierend...

    ... Link

    du könntest noch probieren die records im content table nach id zu sortieren (siehe myisamck (optionen --sort-index und --sort-records, --analyze kann auch nicht schaden), das könnte beim offset/limit problem helfen. oder auch das update-script so umzuschreiben dass du dir immer die letzte behandelte id merkst und mit "where id > lastId order by id limit 5000" arbeitest.

    ... Link

    Gute Ideen
    ...die womöglich zur *endlich* erlangten Geschwindigkeitssteigerung noch beitragen könnten.

    Die letzten Änderungen (Records komplett auslesen, konvertieren, in neue Table schreiben und dann gleich im alten Table löschen) haben die Dauer des ganzen Vorgangs auf unter 4 Stunden reduziert.

    Das Sortieren werd ich einfach noch vor der Konvertierung durchführen, kann ja nix schaden.

    Was Deinen Vorschlag ("where id > lastId") angeht, so bin ich ziemlich sicher, dass es ein Fehler von mir war, auf "limit n offset m" umzusteigen.

    Diese Variante benötigt wohl mehr Zeit; auch wenn das wohl nicht der einzige Grund war.

    ... Link


    ... Comment

    Online for 2714 days
    Last modified: 2008.12.02, 08:49
    Status
    Youre not logged in ... Login
    Menu
    ... Home
    ... Tags

    Search
    Calendar
    Dezember 2008
    MoDiMiDoFrSaSo
    1234567
    891011121314
    15161718192021
    22232425262728
    293031
    Oktober
    Recent updates
    Die Suche ist immer noch Substandard, ja.
    by tobi (2008.12.02, 08:49)
    ist search tatsächlich immer noch so behindert dass es ausschliesslich in den Titles sucht?...
    by progosk (2008.12.01, 23:17)
    Sorry, hab ich vergessen. Ist jetzt hoffentlich beantwortet.
    by tobi (2008.11.12, 11:45)
    Slightly off-topic: Ich hatte eine Frage bzgl. der Anzahl der angezeigten Zeichen in RSS-Feeds....
    by alex63 (2008.11.12, 11:21)
    Kommentare sind strukturell gesehen tatsächlich Stories mit leicht veränderten Eigenschaften. Dass man mit einer...
    by tobi (2008.11.12, 10:59)
    Habe gerade einen lustigen Effekt bemerkt, der dazu führt, dass man Kommentare wie Stories...
    by ichichich (2008.11.12, 10:30)
    war das mit dem Cookie nicht sogar breit diskutiert worden hier? Na ja, vielen...
    by DaveKay (2008.10.21, 17:52)
    Außerdem neu Seit gestern läuft Antville.org mit der allerneuesten Helma, auch bisher ohne Probleme. Das...
    by tobi (2008.10.21, 13:49)
    danke
    by mariong (2008.10.21, 08:46)
    Hui Das hat also doch etwas länger gedauert, die gute Elise mit neuen Versionen von...
    by tobi (2008.10.21, 01:19)
    haben sie auch kürzlich hader gesehen? ;-) o.k. - alles klar.
    by dieguteseite (2008.10.13, 11:19)
    Klar, dürfen Sie so unverschämt sein, und mich bitten; ich darf dafür so unverschämt...
    by tobi (2008.10.13, 10:50)
    herr tobi, dürfte ich so unverschämt sein und sie bitten bei meinen mostread die top-7...
    by dieguteseite (2008.10.10, 20:48)
    Also mir wär's auch recht, wenn entweder die Zahlen einfach stehen blieben, denn die...
    by simons (2008.10.09, 20:34)
    ich würd ja eher sagen, dass die anderen stories zu niedrige zugriffszahlen haben. ;-)...
    by alex63 (2008.10.09, 19:03)
    Wenn das PIs wären würde ich ja sagen: das lassen wir, ich such mal...
    by DonDahlmann (2008.10.09, 18:43)
    statistik ist opium für vollkoffer setzten sie ruhig alle meine auf 0 zurück. oder lassen...
    by kris (2008.10.09, 17:44)
    Nachbesserungen So, der zweite Teil des Updates, den ich letztesmal nicht mehr geschafft habe, ist...
    by tobi (2008.10.03, 02:15)
    funkt, danke!
    by motzes (2008.09.13, 23:24)
    Galleries sind wieder da! Und damit hoffe ich, dass diese erfreuliche Nachricht die einzigen Auswirkungen...
    by tobi (2008.09.13, 22:34)
    Antville is looking forward to your donation Please use one of the three transfer methods...
    by tobi (2008.09.05, 14:23)
    Antville freut sich über Ihre Spende Bitte verwenden Sie eine der drei folgenden Überweisungsmöglichkeiten: 1....
    by tobi (2008.09.05, 14:22)
    *seufz* Das meinte ich mit "14:58".
    by kristof (2008.08.25, 23:50)
    Nachtrag Es spricht selbstverständlich nichts dagegen, für diesen (wie auch jeden anderen) Sachverhalt, Feature-Request oder...
    by tobi (2008.08.25, 18:23)
    Ja, das haben Sie bereits betont, und ich habe daraufhin versucht zu erklären, dass...
    by tobi (2008.08.25, 18:16)

    RSS feed

    Made with Antville
    Helma Object Publisher