SQL Performance ?

  • Betroffene App
    WoltLab Suite Forum

    Ich hab ja gerade alles upgraden müssen und dafür auch Geld investiert Jammern will ich nicht aber wenn ich dann in mein mysql-slow Log sehe wird mir schlecht

    Code
    Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 1.9850 Sekunden.) [time: 1397974538... - 1397974538...]
    SELECT time FROM wbb1_post WHERE threadID = '23063' AND time > '1397974460' ORDER BY time LIMIT 1
    
    Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 2.6835 Sekunden.) [time: 1397974538... - 1397974538...]
    SELECT time FROM wbb1_post WHERE threadID = '23063' AND time > '1397974460' ORDER BY time LIMIT 1

    Keine ahnung woher das kommt ich kann nur sagen ich habe quasi keine Plugins mehr da die gefühlt sowieso immer nur von Kindern geschrieben werden die nach 2 Wochen die Lust an der weiterentwicklung verlieren und dann kein update mehr möglich ist .....

    Ich bin kein SQL Guru aber wenn die Id so verwendet wird wie ich mir das vorstelle dann wäre das folgende anscheinend um einiges schneller ...

    Code
    Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.6511 Sekunden.)
    SELECT time FROM wbb1_post WHERE threadID = '23063' AND time > '1397974460' ORDER BY postId LIMIT 1

    Ich möchte an dieser Stelle anmerken das ich bei einem Produkt in das ich regelmässig geld investiere schon einen gewissen Grad an Qualität liefert auf die ich mich verlassen kann .....

    Einmal editiert, zuletzt von marksoft (7. Februar 2020 um 23:20)

  • Wenn du statt nach time einfach nach postID sortieren würdest, dann würden die Beiträge doch teilweise völlig anders sortiert werden.

    Als Beispiel, wenn ein Beitrag (ID = 1) via zeitgesteuerter Veröffentlichung erst später veröffentlicht wird als ein danach erstellter Beitrag (ID = 2).

    Beiträge:

    1. Beitrag #1 um 12:00 Uhr erstellt, aber via zeitgesteuerter Veröffentlichung erst um 14:00 Uhr veröffentlicht
    2. Beitrag #2 um 13:00 Uhr erstellt und sofort (also um 13:00 Uhr) veröffentlicht

    Da würde die Sortierung nach time oder postID einen großen Unterschied machen:

    Sortierung nach time:

    1. Beitrag #2 (veröffentlicht um 13:00 Uhr)
    2. Beitrag #1 (veröffentlicht um 14:00 Uhr)

    Sortierung nach postID:

    • Beitrag #1 (veröffentlicht um 14:00 Uhr)
    • Beitrag #2 (veröffentlicht um 13:00 Uhr)

    Das selbe gilt z.B., wenn man in der Datenbank den Timestamp eines Beitrags anpassen würde. Wenn nach postID sortiert werden würde, würde die Änderung des Timestamps nichts bringen bzw. die Reihenfolge nicht beeinflussen. Stattdessen müsste man dann in der Datenbank die postIDs von den Beiträgen hin und her werfen, wenn man die Reihenfolge beeinflussen wollen würde.

  • 58459 ist das Resultat

    Um der das ist der Grund antwort vorzubeugen ich hab das gleiche Problem auch mit kleineren Threads

    und wenn das mit der time stimmt

    Code
    # Query_time: 1.077320  Lock_time: 0.000089 Rows_sent: 25  Rows_examined: 2511
    SET timestamp=1581117422;
    SELECT    post.postID AS objectID
                FROM    wbb1_post post
                     JOIN wbb1_thread thread
                    WHERE post.userID = '3493' AND post.isDisabled = 0 AND post.isDeleted = 0 AND thread.threadID = post.threadID AND thread.boardID IN ('3','89','10','233','15','67','52','66','31','14','12','54','181','87','24','73','79','70','28','104','105','114','120','88','179','183','69','68','91','95','90','75','96','93','122','214','225','226','232','134','25','333','26','51','27','30','229')
                    ORDER BY post.time DESC, post.postID DESC LIMIT 25;

    warum dann hier die postID im Order By ?

    Code
    Zeige Datensätze 0 - 24 (25 insgesamt, Die Abfrage dauerte 0.6009 Sekunden.)
    SELECT post.postID AS objectID FROM wbb1_post post JOIN wbb1_thread thread WHERE post.userID = '3493' AND post.isDisabled = 0 AND post.isDeleted = 0 AND thread.threadID = post.threadID AND thread.boardID IN ('3','89','10','233','15','67','52','66','31','14','12','54','181','87','24','73','79','70','28','104','105','114','120','88','179','183','69','68','91','95','90','75','96','93','122','214','225','226','232','134','25','333','26','51','27','30','229') ORDER BY post.time DESC LIMIT 25

    vs

    Code
    Zeige Datensätze 0 - 24 (25 insgesamt, Die Abfrage dauerte 1.1629 Sekunden.)
    SELECT post.postID AS objectID FROM wbb1_post post JOIN wbb1_thread thread WHERE post.userID = '3493' AND post.isDisabled = 0 AND post.isDeleted = 0 AND thread.threadID = post.threadID AND thread.boardID IN ('3','89','10','233','15','67','52','66','31','14','12','54','181','87','24','73','79','70','28','104','105','114','120','88','179','183','69','68','91','95','90','75','96','93','122','214','225','226','232','134','25','333','26','51','27','30','229') ORDER BY post.time DESC, post.postID DESC LIMIT 25

    Ich will nicht überanalysieren aber wenn das was ihr sagt stimmt ist im 2. SQL die postID egal .... Vielleicht sollte demnächst mal ein Augenmerk auf die SQL Performance gelegt werden. Soweit ich kann werde ich dabei auch unterstützend tätig sein

    5 Mal editiert, zuletzt von marksoft (8. Februar 2020 um 00:45)

  • 48834

    Code
    id    select_type    table    partitions    type    possible_keys    key    key_len    ref    rows    filtered    Extra
    1    SIMPLE    wbb1_post    NULL    ref    threadID,threadID_2,time,thread_3    threadID_2    4    const    118692    50.00    Using where; Using index
    • Offizieller Beitrag

    Mich wundert die doch eher miese Performance von MySQL, obwohl laut EXPLAIN der Index verwendet wird. Ich tippe ad hoc eher auf eine unzureichende Konfiguration des Arbeitsspeichers, gerade bei großen Foren ist es ungemein wichtig, dass MySQL genug Speicher hat um insbesondere die Indizes im Arbeitsspeicher zu halten.

    Mal als Vergleich, woltlab.com nutzt aktuell bei einer InnoDB data size von 12,2 GB geschmeidige 18,1 GB Arbeitsspeicher. Ich habe zum Vergleich mal das Thema Smalltalk - Labern, reden, diskutieren... verwendet, da dies mit über 44.000 Beiträgen dem "problematischen" Thema sehr nahe kommt. Die selben Abfragen dauern dort nur ~0,0007 Sekunden, als Folge der reinen Verwendung des Index zur Beantwortung des Queries - dieser ist so geschrieben, dass diese vollständig aus dem Index beantwortet werden kann!

  • Lieber Alexander Ebert, da ich dir keine Private Nachricht schreiben darf hiermit offiziell ! Mich kotzt diese überhebliche Art die ihr an den Tag legt schön langsam an !

    Funktionen die mal drin waren wurden immer wieder entfernt um dann als Deckmantel des Updates erneut verkauft werden können.

    Ich erinnere mich als man 2015 ein Plugin kaufen musste um die letzten X Beiträge anzuzeigen (war in einer vorgänger Version enthalten).

    Ihr habt noch immer kein vernünftiges Eco System um Plugins dauerhaft verwenden zu können anscheinend verlieren die Entwickler immer wieder die Lust.

    Und jetzt schon wieder diese Grosskotzige Antwort das meine MYSQL an allem schuld ist .....

    Ich zeig euch und somit auch dir auf das die Indizes ein Thema sind lasse mir erklären das man nach PostId nicht sortieren kann (ok verständlich mit dem Timing) und dann zeige ich euch folgendes SQL

    Code
    ORDER BY post.time DESC, post.postID DESC

    aus meiner sicht macht hier dann die PostID keinen Sinn mehr Warum ? wenn es gleiche Zeit ist ? dann soll die Post ID verwendet werden

    Dauer 1.1 vs. 0.6 sec. deine Antwort die bei mir angekommen ist => Kauf dir mehr Ram dann gehts auch mit unseren schlechten SQL Statements ?

    Vielleicht solltest du mal daran arbeiten wie du mit Kunden kommunizierst, vorallem jene die immer zuerst versucht haben positiv mitzuarbeiten.

    Ich habe übrigens keine MYSQL Settings die ihr empfehlen würdet gefunden...... und klar wenn quasi das Ganze Forum im Ram steht gehts immer schneller ..... Wenn ihr Performance Issues immer so löst indem ihr mehr Ram kauft ist mir alles klar - auch ein weg bin gespannt wieviele eurer Kunden das machen können.


    Ausserdem finde ich die Kust seines selektiven Lesens bemerkenswert wie ich angemerkt habe habe ich das Problem nicht bei einem sondern bei zig Threads:

    58459 ist das Resultat

    Um der das ist der Grund antwort vorzubeugen ich hab das gleiche Problem auch mit kleineren Threads

    3 Mal editiert, zuletzt von marksoft (9. Februar 2020 um 11:49)

    • Offizieller Beitrag

    Ob man nun die postID mit drin hat oder nicht, spielt keine wirkliche Rolle, selbst 0,6 Sekunden sind dafür viel zu viel. Der Punkt ist, dass die Abfrage so geschrieben ist, dass diese selbst bei extrem großen Foren absolut performant läuft, weil diese vollständig über den Index abgearbeitet werden kann.

    Das setzt aber auch voraus, dass MySQL über ausreichend Arbeitsspeicher verfügt, um die wichtigsten Sachen dauerhaft im Speicher zu halten. Die exakte Nutzung des Arbeitsspeichers verwaltet MySQL selbst, aber eben nur im Rahmen dessen, was per Konfiguration zugestanden wird - bevorzugt sind dies Indizes. Wenn die Indizes im Speicher gehalten werden, dauert die Abfrage nur noch winzige Bruchteile einer Sekunde, denn genau darauf sind Datenbanken nun einmal optimiert.

    Wie sehen denn die folgenden Einstellungen aus:

    Code
    table_open_cache
    table_definition_cache
    innodb_file_per_table
    innodb_buffer_pool_size
    innodb_buffer_pool_instances
    innodb_log_file_size

    Zusätzlich interessant sind diese beiden Abfrage, die erste liefert Informationen zum Table-Cache und die zweite zur Größe des InnoDB Data Sets (gerundet in MB):

    SQL
    show global status like 'opened_tables';
    SQL
    SELECT CEILING(SUM(data_length+index_length) / POWER(1024, 2)) as InnoDB_in_MB FROM information_schema.tables WHERE engine='InnoDB'
  • marksoft, dein Feedback in allen Ehren. Aber der Ton, den du hier an den Tag legst, ist unter aller Sau. Du möchtest Verbesserungen der Software erreichen? Großartig. Davon könnte am Ende jeder profitieren. Aber Beleidigungen und die aggressive Grundstimmung in deinen Beiträgen sind kontraproduktiv und helfen nicht dabei, deine Argumente zu vermitteln. Am Ende kann ein solches Verhalten sogar dazu führen, dass eigentlich gute Ideen gar nicht mehr die Beachtung finden, die sie ansonsten finden würden. In diesem Sinne großen Respekt an Alexander, dass er dir auf diese Unverschämtheiten in Beitrag #10 auch noch in dieser Ruhe und Freundlichkeit geantwortet hat. Fast überall sonst wäre das Thema vermutlich geschlossen worden (und dein Account unter Umständen gleich mit). Daher: Bitte achte darauf, wie du mit anderen sprichst. Das hat etwas mit Respekt gegenüber seinen Mitmenschen zu tun. Ich hoffe sehr, dass du es nicht nötig hast, mich für diesen Beitrag jetzt auch beleidigen zu müssen…

  • Grandiose Antwort, allerdings wo ich beleidigend wurde hätte ich gerne gewusst. Es sind alles Fakten:

    1. das Order By ist nach der Erklärung von Reen aus meiner sicht komplett unnötig und ist bei mir ein unterschied von 0.6 vs 1.07 Sekunden darauf wurde aber nicht eingegangen es wurde nur erklärt der "Arbeitsspeicher ist schuld" (So ist es angekommen)
    2. Ich weise aktuell nochmals darauf hin das es wiederholt passiert ist das Funktionen entfernt wurden um sie danach mit einem Update wieder zu erhalten. Hier mal was mir auf die schnelle einfällt auch das habe ich als Vorwurf eingebracht nachdem ich zum wiederholten Male mit meinen Argumenten gegen eine Wand fahre.
      1. Letzte Beiträge
      2. unterschiedliche Logos bei Kategorien
    3. Wenn es für den betrieb des Forums anscheinend zwingend notwendig ist Mysql korrekt einzustellen warum findet man nirgends dafür eine Hilfestellung ?
    4. Hr. Ebert hat durch seinen Satz Mal als Vergleich, woltlab.com nutzt aktuell bei einer InnoDB data size von 12,2 GB geschmeidige 18,1 GB Arbeitsspeicher. Den eindruck das nur ausreichend RAM ein einwandfreies Forum gewährleisten vermittelt und das die Performance der SQL Statements kein Thema sind wenn alles im RAM "stehen bleibt".
    5. mein Hinweis auf das selektive Lesen ist ein Hinweis das es nicht nur bei grossen sondern auch bei kleinen Threads passiert. ich hatte nur das dumme Pech euch aus dem Mysql Log genau dieses herauszupicken und habe das auch schnell erkannt und eben auch notiert das es nicht nur an diesem Thread so aussieht.
    6. Mein Eindruck bezüglich der Plugins bisher war immer das ich keines über mehr als 2 Versionen verwenden konnte weil es ein Update behindert hat. auch hier könnte ich eine Liste anführen ist mir aber zuviel arbeit.
      1. Ein 4 gewinnt Spiel wars einmal
      2. und ein Antispam ding bei der Aktuellen wo quasi die Entwicklung nicht mehr da war für neue Versionen und diesen Eindruck hab ich festgehalten. Wenn ich Plugins nicht dauerhaft einsetzten kann dann finde ich den zweck auch nicht mehr zielführend.

    Anhang A: https://www.duden.de/rechtschreibung/ueberheblich

    Du darfst mir jetzt noch alle Beleidigungen in meinen Postings aufzählen.

    Ergänzung: aufgrund der Antwort nach diesem Posting => ich wollte das per Konversation klären war aber nicht möglich auch auf das habe ich hingewiesen.

    4 Mal editiert, zuletzt von marksoft (9. Februar 2020 um 18:11)

  • Es wäre vielleicht zielführender, wenn man dieses Thema hier auf das ursprüngliche (berechtigte) Problem wieder zurück führt und sich inhaltlich damit weiter auseinandersetzt. Alles andere zerstört solch ein Thema und sollte auch anderer Stelle weiter diskutiert werden. Vielleicht können wir uns ab hier alle daran halten.

    Gruß aus Südhessen

  • Das ganze Forum hat bei mir 3.1 GB wobei der Suchindex knapp die hälfte darin füllt. ich hab die Innodb pool size auf 4GB gestellt. Mein System verfügt über 16GB Ram und liegt bei Hetzner MYSQL und PHP sind die letzten gültigen Versionen

    • Server-Version: 8.0.19 - MySQL Community Server - GP
    • nginx/1.14.0
    • Datenbank-Client Version: libmysql - mysqlnd 7.4.2
    • PHP-Version: 7.4.2

    und ich erneuere hiermit den Verdacht das "ORDER BY post.time DESC, post.postID DESC LIMIT 25" auch nur nach post.time ausreichend wäre was bei mir knapp 40% einsparen würde

    • Offizieller Beitrag

    1. das Order By ist nach der Erklärung von Reen aus meiner sicht komplett unnötig und ist bei mir ein unterschied von 0.6 vs 1.07 Sekunden darauf wurde aber nicht eingegangen es wurde nur erklärt der "Arbeitsspeicher ist schuld" (So ist es angekommen)

    Das ist leider nicht korrekt, denn bei identischen Timestamps ist die Aufteilung von Beiträgen auf Seiten nicht deterministisch. Dies ist beispielsweise der Fall, wenn der letzte Beitrag der Seite sowie der Beitrag auf der nächsten Seite den selben Timestamp haben, deshalb ist die postID zwingend notwendig.

    5. mein Hinweis auf das selektive Lesen ist ein Hinweis das es nicht nur bei grossen sondern auch bei kleinen Threads passiert. ich hatte nur das dumme Pech euch aus dem Mysql Log genau dieses herauszupicken und habe das auch schnell erkannt und eben auch notiert das es nicht nur an diesem Thread so aussieht.

    Bei kleineren Themen dürfte dies nicht auftreten, denn der Aufwand O(n) sinkt dabei enorm ab. Das lässt auf ein Problem mit der Speicherverwaltung schließen, der äußerst üppige Wert bei opened_tables ist ein gutes Indiz dafür.

    Code
    SHOW ENGINE InnoDB STATUS

    Interessant ist hier der Abschnitt "BUFFER POOL AND MEMORY".

    Laut deinen Aussagen kommt MySQL 8 zum Einsatz, dort steht zusätzlich EXPLAIN ANALYZE zur Verfügung, dass deutlich mehr Informationen zum Query-Plan liefert.

  • Sodala da wäre ich mal wieder mit dem gleichen PRoblem und diesmal auch mit einer Lösung die hoffentlich auch umgesetzt wird !

    JA bitte lasst und das Problem dieses mal ECHT angehen mir geht das herumwurschteln mit Configs ets schon so auf die nerven.

    SQL
    SELECT time FROM wbb1_post WHERE threadID = '46939' AND time > '1528443396' ORDER BY time LIMIT 1

    hat ja den Sinn den max Timestamp zu finden wenn ich das richtig sehe .... mir ist nicht ersichtlich warum diese Abfrage so ist wie sie ist nach wie vor. Aber ja meine Argumentation mit der PostID wurde ja abgelehnt was ja noch ok ist aber folgendes ist auf meinem System ebenfalls schneller !

    Query_time: 1.841918 vs 0.0060

    Code
    Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0060 Sekunden.)
    SELECT MAX(time) FROM wbb1_post WHERE threadID = '46939' AND time > '1528443396'

    Könnten wir das bitte konstruktiv angehen danke und bitte wenn ein SQL schneller ist das gleiche macht lasst uns echt daran denken das umzusetzen danke.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!