it-swarm.com.de

Kann MySQL mehr als einen Kern verwenden?

Mir wurden einige dedizierte MySQL-Server vorgestellt, die nie mehr als einen einzelnen Kern verwenden. Ich bin mehr Entwickler als DBA für MySQL, brauche also Hilfe

Installieren

Die Server sind mit einer Last vom Typ OLAP/DataWarehouse (DW) ziemlich stark:

  • Primär: 96 GB RAM, 8 Kerne + einzelnes RAID 10-Array
  • Test: 32 GB RAM mit 4 Kernen
  • Die größte Datenbank ist 540 GB, die Gesamtzahl beträgt rund 1,1 TB und meistens InnoDB-Tabellen
  • Solaris 10 Intel-64
  • MySQL 5.5.x.

Hinweis: Die größte Datenbank ist die replizierte vom OLTP DR-Server, und die DW wird von dieser geladen. Es handelt sich nicht um eine vollständige DW: Sie dauert nur 6 Monate bis 6 Wochen, ist also kleiner als die OLTP DB.

Beobachtungen auf einem Testserver

  • 3 separate Verbindungen
  • jeder hat eine gleichzeitige (und unterschiedliche) ALTER TABLE...DROP KEY...ADD INDEX
  • die 3 Tabellen haben 2,5, 3,8 und 4,5 Millionen Zeilen
  • Die CPU-Auslastung steigt auf 25% (ein Kern ist maximal) und nicht höher
  • die 3 ALTERs dauern 12-25 Minuten (eine Single auf der kleinsten dauert 4,5)

Fragen

  1. Welche Einstellung oder welcher Patch ist erforderlich, damit mehr als ein Kern verwendet werden kann?
    Das heißt, warum verwendet MySQL nicht alle verfügbaren Kerne? (wie andere RDBMS)
  2. Ist es eine Folge der Replikation?

Weitere Hinweise

  • Ich verstehe den Unterschied zwischen einem RDBMS "Thread" und einem OS "Thread"
  • Ich frage nicht nach irgendeiner Form von Parallelität
  • Einige der Systemvariablen für InnoDB und Threads sind nicht optimal
    (Auf der Suche nach einem schnellen Gewinn)
  • Kurzfristig kann ich das Festplattenlayout nicht ändern
  • Das Betriebssystem kann bei Bedarf angepasst werden
  • Eine einzelne ALTER TABLE auf dem kleinsten Tisch dauert 4,5 Minuten (schockierende IMO)

Bearbeiten 1

  • innodb_thread_concurrency ist auf beiden auf 8 gesetzt. Ja, es ist falsch, aber MySQL wird nicht mehrere Kerne verwenden
  • innodb_buffer_pool_size ist 80 GB bei primären und 10 GB bei einem Test (eine andere Instanz wird heruntergefahren). Dies ist vorerst in Ordnung.
  • innodb_file_per_table = ON

Bearbeiten 2

Zu testen

  • innodb_flush_method wird nicht als O_DIRECT angezeigt, wenn dies der Fall sein sollte
  • folgt den Einstellungen von RolandoMySQLDBA

Lassen Sie mich wissen, wenn ich etwas Wichtiges verpasst habe

Prost

Aktualisieren

Innodb_flush_method + 3 x Thread-Einstellungen in der Antwort von RolandoMySQLDBA geändert
Ergebnis:> 1 Kern für die Tests verwendet = positives Ergebnis

136
gbn

Ich habe innodb_thread_concurrency tatsächlich mit einem MySQL-Experten auf der Percona Live NYC-Konferenz im Mai 2011 besprochen. .

Ich habe etwas Überraschendes gelernt: Trotz der Dokumentation ist es am besten, innodb_thread_concurrency bei 0 (unendliche Parallelität). Auf diese Weise entscheidet InnoDB über die beste Anzahl von innodb_concurrency_tickets , um für ein bestimmtes MySQL-Instanz-Setup zu öffnen.

Sobald Sie innodb_thread_concurrency auf 0 können Sie innodb_read_io_threads und innodb_write_io_threads (beide seit MySQL 5.1.38) auf den Maximalwert von 64. Dies sollte mehr Kerne beanspruchen.

130
RolandoMySQLDBA

MySQL verwendet automatisch mehrere Kerne, sodass entweder Ihre Auslastung von 25% zufällig ist1 oder eine mögliche Fehlkonfiguration unter Solaris. Ich werde nicht vorgeben zu wissen, wie man Solaris abstimmt, aber hier ist ein Artikel, der einige Solaris-spezifische Abstimmungsinformationen behandelt.

Die InnoDB-Optimierungsseiten wurden in MySQL 5.5 überarbeitet, daher gibt es auch dort einige gute Informationen. Von der InnoDB-Festplatte IO Tipps :

Wenn das Unix-Top-Tool oder der Windows Task-Manager anzeigt, dass der Prozentsatz der CPU-Auslastung bei Ihrer Workload weniger als 70% beträgt, ist Ihre Workload wahrscheinlich festplattengebunden. Möglicherweise führen Sie zu viele Transaktions-Commits durch, oder der Pufferpool ist zu klein. der Pufferpool größer zu machen kann helfen, aber setzen Sie es nicht auf mehr als 80% des physischen Speichers.

Einige andere Dinge zu überprüfen:

  • Das Umschalten von innodb_flush_method auf O_DIRECT ist einen Test wert. Wenn dies hilft, müssen Sie das Dateisystem möglicherweise mit der Option forcedirectio mounten

  • Ändern Sie innodb_flush_log_at_trx_commit von 1 auf 0 (wenn es Ihnen nichts ausmacht, die letzte Sekunde bei einem MySQL-Absturz zu verlieren) oder 2 (wenn es Ihnen nichts ausmacht, die letzte Sekunde beim Absturz des Betriebssystems zu verlieren).

  • Überprüfen Sie den Wert von innodb_use_sys_malloc . Dieser Artikel enthält weitere Informationen zur Variablen.

    Zu diesem Zeitpunkt gab es keine Speicherzuordnungsbibliotheken, die für Mehrkern-CPUs optimiert waren. Daher hat InnoDB einen eigenen Speicherzuweiser im mem-Subsystem implementiert. Dieser Allokator wird von einem einzelnen Mutex geschützt, der zu einem Engpass werden kann.

    Am Ende des Abschnitts gibt es jedoch einige Einschränkungen, was es bedeutet, die Variable einzuschalten (in 5.5 ist sie standardmäßig aktiviert).

    Beachten Sie, dass InnoDB den Wert des Parameters innodb_additional_mem_pool_size ignoriert, wenn der InnoDB-Speicherzuweiser deaktiviert ist.

  • Möglicherweise verursacht die Replikation einen Teil des Problems. Mir ist klar, dass Sie nicht an Parallelität interessiert sind, sondern aus der Beschreibung von diesem Arbeitsprotokoll :

    Derzeit lässt sich die Replikation auf Multi-Core-Computern nicht gut skalieren. Der einzelne Slave-Thread führt Replikationsereignisse einzeln aus und kann möglicherweise nicht mit einer Last umgehen, die durch gleichzeitige mehrere Clientverbindungen erzeugt wird, die von der CPU des separaten Master-Servers bedient werden.

Letztendlich ist InnoDB aufgrund der auftretenden festplattenbasierten Vorgänge möglicherweise nicht die beste Engine für Datawarehousing. Sie können die Datawarehouse-Tabelle (n) in Compressed MyISAM ändern.

1Zufällig meine ich, dass es einen Engpass gibt, der verhindert, dass Ihre Last über 25% steigt, aber nicht unbedingt ein erzwungenes Single-Core-Problem ist.

31
Derek Downey

Hinweis: Bei dieser Antwort handelt es sich um eine einzelne Verbindung mit mehreren Kernen. Die Frage des OP war nicht eindeutig. Es wurde fälschlicherweise angenommen, dass MySQL insgesamt nicht mehr als einen Kern verwenden kann. Die anderen Antworten weisen korrekt darauf hin, dass die 3-Alter Der Testfall ist wirklich E/A-gebunden und kann daher die Titelfrage nicht beweisen.

Eine einzelne Verbindung verwendet nur einen einzelnen Kern. (OK, InnoDB verwendet für einige E/A-Verarbeitungen andere Threads, also Kerne, aber das ist nicht signifikant.)

Sie hatten 3 ALTERs, also haben Sie nicht viel mehr als 3 Kerne verwendet.

Leider verwendet nicht einmal PARTITION mehrere Kerne.

Bis vor kurzem waren mehrere Verbindungen nach 4-8 Kernen maximal. Perconas Xtradb (in MariaDB enthalten) nutzt mehrere Kerne besser, aber immer noch nur einen pro Thread. Sie erreichen maximal 32 Kerne.

(Update im Jahr 2015 :) Mehrere Verbindungen mit maximal 5,6 bei ca. 48 Kernen. 5.7 verspricht noch besser zu werden. (So ​​sagt Oracle Benchmarks.) Aber immer noch keine Verwendung mehrerer Kerne für eine einzelne Verbindung.

Update (nach dem Aufrufen von Oracle OpenWorld): Die neue Version 8.x weist keine Parallelität auf.

Weiteres Update - 8.0.17 hat Fälle, in denen bei sehr wenigen ausgewählten Abfragen mehrere Kerne verwendet werden. (Das heißt, sei nicht aufgeregt.)

17
Rick James

IMHO und im beschriebenen Anwendungsfall werden Sie nie mehr als einen Kern verwenden. Der Grund dafür ist, dass Ihre Arbeitslast IO gebunden, nicht CPU-gebunden ist. Da Ihre 3 Verbindungen einen neuen Index erstellen, muss jeder von ihnen die gesamte Tabelle von der Festplatte lesen: Dies ist erforderlich Zeit, nicht die Indizes zu berechnen.

10
jfg956

Bedenken Sie, dass Ihr Engpass die IO Leistung Ihres Dateisystems sein könnte.

Zusätzlich zu die von @RolandoMySQLDBA vorgeschlagenen Einstellungen habe ich auch die Mount-Einstellungen noatime in /etc/fstab Für die Partition festgelegt, die mein MySQL-Datenverzeichnis enthält (/data01/mysql in meinem Fall mit /dev/sdb1 an /data01).

Standardmäßig zeichnet Linux die Zugriffszeit für JEDES Lesen oder Schreiben von Datenträgern auf, was sich negativ auf die Leistung von IO auswirkt, insbesondere für Anwendungen mit hohem IO wie Datenbanken. Dies bedeutet, dass selbst das Lesen von Daten aus einer Datei ein Schreiben auf die Festplatte auslöst ... WAT!

Um dies zu deaktivieren, fügen Sie die Mount-Option noatime in /etc/fstab Für den gewünschten Mount-Punkt wie folgt hinzu (Beispiel in meinem Fall):

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

Montieren Sie dann die Partition erneut:

mount -o,remount /data01

Dies sollte die Lese-/Schreibleistung von Anwendungen verbessern, die diese Partition verwenden. ABER ... nichts geht über das Speichern all Ihrer Daten im Speicher.

9
OkezieE