mysql settings für 64Gb RAM

[Jacky007]

Hi,

habe einen Server mit i7-6700 Quad-Core - RAM: 64 GB DDR4 - HDD: 2x 4 TB SATA Enterprise

Würde gerne meine my.cnf für 64Gb/CPU anpassen, mir ist bekannt, dass man das nicht so einfach sagen kann, aber zumindesten, etwas helfen, was ich am besten anpassen soll. Auf dem Server läuft ein WordPress Blog mit ca. 150.000 Artikeln (wächst natürlich jeden tag) , die DB ist daher auch fast 1GB groß. Da dort sonst nix läuft, kann mysql dann gerne viel ram nutzen usw.

Danke im Voraus.

#
# * Fine Tuning
#
key_buffer_size        = 384M
#max_allowed_packet     = 16M
#thread_stack           = 192K
thread_cache_size      = 8
#myisam_recover_options = BACKUP
myisam_sort_buffer_size = 64M
read_rnd_buffer_size = 8M
read_buffer_size = 2M
sort_buffer_size = 2M
table_open_cache = 512
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10

#
# * Query Cache Configuration
#
#query_cache_limit      = 1M
query_cache_size        = 16M

#general_log_file       = /var/log/mysql/mysql.log
#general_log            = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Enable the slow query log to see queries with especially long duration
#slow_query_log_file    = /var/log/mysql/mariadb-slow.log
#long_query_time        = 10
#log_slow_rate_limit    = 1000
#log_slow_verbosity     = query_plan
#log-queries-not-using-indexes

#server-id              = 1
#log_bin                = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
#max_binlog_size        = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = exclude_database_name

 

[majusss]

https://www.percona.com/blog/2016/05/03/best-practices-for-configuring-optimal-mysql-memory-usage/ Einfach mal durchlesen.

 

[RalphS]

1GB? Interessiert für dbms nicht.

Je nachdem wie gut das besucht ist wär evtl in memory denkbar. Das hat dann aber natürlich nochmal eigene Tücken.

Wenn das DBMS gut läuft, laß es so.

 

[Innensechskant]

Sehe es wie @RalphS bei der kleinen Datenbank würde ich alles so lassen wie es ist. Hast du denn Performance-Probleme?

 

[Jacky007]

Ja, es ist halt dann sehr langsam, z.B. wenn ich einen Artikel lösche usw. daher wollte ich das optimieren.

 

[Madman1209]

Hi,

sicher, dass das an der DB liegt? Ich vermute eher, dass da WordPress der Schuldige ist - oder woher kommt deine Vermutung, dass es die Datenbank ist?

Was genau ist ein "Artikel" bei dir? Geht es dabei um einen redaktionellen Artikel, also einen Blogbeitrag, oder sprechen wir von kaufbaren Warenartikeln in einem WooCommerce System?

VG,
Mad

 

[Jacky007]

Vermute, dass es an der Datenbank liegt, weil als ich noch wenige Artikel hatte, ging alles recht schnell.. Meinte damit natürlich einen Blogbeitrag, im Grunde polizeimeldungen/firmenmitteilungen

 

[Madman1209]

Hi,

150.000 Einträge sind eigentlich für eine Datenbank überhaupt kein Thema, 150.000 Blogbeiträge in WordPress sind aber natürlich schon eine Hausnummer. Ist das ein Blog bzw. eine Instanz? Oder ist das eine Multisite?

Ich frage, weil es bei 150.000 Beiträgen bei circa 40 Beiträgen pro Tag zehn Jahre dauern würde, um das hinzubekommen. Ich würde mal behaupten, WordPress ist auf so eine "Masse" vielleicht nicht ausgelegt, wobei ich Seiten kannte (Feed Aggregatoren), die auf WordPress aufbauend gut 1 Million Posts intus hatten, ohne größere Probleme.

Wenn man sich die Seite mal ansehen könnte wäre das natürlich hilfreich. Verwendest du viele Plugins oder ähnliches? Und vielleicht mal eine Definition: was genau bedeutet "langsam beim Löschen"?

VG,
Mad

 

[Marco01_809]

Ganz unabhängig von der Größe der Datenbank will man - erst recht bei HDDs! - sicher gehen dass MySQL alles im Speicher halten kann und nichts von der Festplatte laden muss.

Daher innodb_buffer_pool_size auf etwas größer als die Datenbank - wenn nichts dagegen spricht auch gleich auf 8 GB.
Das trifft natürlich nur zu, wenn die Datenbank auch das InnoDB Schema verwendet. Ist sie noch MyISAM, sollte man sie vielleicht zuerst auf InnoDB konvertieren (siehe Google, backups nicht vergessen!).

Zur Optimierung weiterer Parameter (und Erklärungen) finden sich Guides im Internet, die man ausprobieren kann. Dabei gilt man sollte keine dahergelaufene Config copy-pasten, sondern nur Parameter verändern wenn diese der Erklärung nach als Performance-Bottleneck in Frage kommen. Und dann sollte man natürlich auch ausprobieren, ob diese die Performance wirklich verbessern.

Für tiefgehende Optimierung braucht es schon detaillierte Analysen wie die Datenbank abgefragt wird, welche Queries am meisten Zeit brauchen, welche Buffer überlaufen, etc.

Wie wird WordPress ausgeführt? Apache+mod_php? Die Performance hängt natürlich auch stark hiervon ab und bei WordPress gibt es mit diversen Caching plugins einige möglichkeit zu verhindern, dass WordPress bei einem Page visit überhaupt ausgeführt wird. Entsprechend wird auch die Datenbank nicht abgefragt. Das sollte man sich auf jeden Fall auch einmal ansehen.

 

[Jacky007]

Ich verwende Apache + fcgi - das mit innodb werde ich mal machen, vllt. wird es dadurch viel schneller.

Plugins hält sich im Rahmen, habe auch paar Testweiße ausgeschaltet - aber hat keine Besserung gebracht. Ich hatte früher sogar über 200.000 Mitteilungen, nur da ging fast nix mehr, um einen Artikel zu löschen, hat es schon 5-7 Sekunden gedauert. Auch die Auslastung war immer hoch, auch wenn man neue Artikel veröffentlicht hat.

 

[Jacky007]

Ganz unabhängig von der Größe der Datenbank will man - erst recht bei HDDs! - sicher gehen dass MySQL alles im Speicher halten kann und nichts von der Festplatte laden muss.

Daher innodb_buffer_pool_size auf etwas größer als die Datenbank - wenn nichts dagegen spricht auch gleich auf 8 GB.
Das trifft natürlich nur zu, wenn die Datenbank auch das InnoDB Schema verwendet. Ist sie noch MyISAM, sollte man sie vielleicht zuerst auf InnoDB konvertieren (siehe Google, backups nicht vergessen!).

Zur Optimierung weiterer Parameter (und Erklärungen) finden sich Guides im Internet, die man ausprobieren kann. Dabei gilt man sollte keine dahergelaufene Config copy-pasten, sondern nur Parameter verändern wenn diese der Erklärung nach als Performance-Bottleneck in Frage kommen. Und dann sollte man natürlich auch ausprobieren, ob diese die Performance wirklich verbessern.

Für tiefgehende Optimierung braucht es schon detaillierte Analysen wie die Datenbank abgefragt wird, welche Queries am meisten Zeit brauchen, welche Buffer überlaufen, etc.

Wie wird WordPress ausgeführt? Apache+mod_php? Die Performance hängt natürlich auch stark hiervon ab und bei WordPress gibt es mit diversen Caching plugins einige möglichkeit zu verhindern, dass WordPress bei einem Page visit überhaupt ausgeführt wird. Entsprechend wird auch die Datenbank nicht abgefragt. Das sollte man sich auf jeden Fall auch einmal ansehen.

habe hier: https://www.taste-of-it.de/mysql-mariadb-feintuning-von-innodb_buffer_pool_size/ sogar gelesen, dass man das auf 80% des vorhandenen Rams einstellen sollte, wobei nicht ganz G

habe mehr als 8GB genommen, siehe hier: (alles korrekt?)

MariaDB [(none)]> SHOW VARIABLES LIKE "innodb_buffer%";
+-------------------------------------+----------------+
| Variable_name | Value |
+-------------------------------------+----------------+
| innodb_buffer_pool_chunk_size | 134217728 |
| innodb_buffer_pool_dump_at_shutdown | ON |
| innodb_buffer_pool_dump_now | OFF |
| innodb_buffer_pool_dump_pct | 25 |
| innodb_buffer_pool_filename | ib_buffer_pool |
| innodb_buffer_pool_instances | 8 |
| innodb_buffer_pool_load_abort | OFF |
| innodb_buffer_pool_load_at_startup | ON |
| innodb_buffer_pool_load_now | OFF |
| innodb_buffer_pool_size | 30064771072 |
+-------------------------------------+----------------+

 

[Marco01_809]

Über die Größe der Datenbank hinaus bringt das erstmal keine weiteren Vorteile. Bei WordPress brauchst du auch viel RAM für die PHP-worker für WordPress.

Wie gesagt wirst du den größten Performance-Gewinn mit einem Caching plugin erzielen.

 

[Jacky007]

Leider hat es nicht so wirklich was gebracht, da ich von außen die Artikeln sowieso per Cache ausliefere, ist das kein Problem. Aber wenn ich z.B. 50 Beiträge aufeinmal löschen möchte, dauert das echt ewig, paar minuten

 

[Madman1209]

Hi,

bei Datenbank-Aktionen wird dir ein Cache auch nicht viel nützen fürchte ich. Komisch ist es trotzdem, die DB sollte da durchaus klarkommen damit.

VG,
Mad

 

[Piktogramm]

Hast du dir eigentlich mal angeschaut welche Prozesse Last auf deinem System verursachen wenn du Artikel löschst? Es bringt dir genau nichts an der DB herumzupfuschen, wenn +80% der CPU-Zeit vom Webserver bzw. PHP Interpreter genutzt werden.
Analog genauso, wenn die Datenbank beim Löschen amok läuft müsste man sich mal anschauen WIESO sie das tut bevor man Configs verbiegt. Im Zweifelsfall will die Datenbank einfach nur brav alle Relationen löschen und sucht dazu in Tabellenspalten ohne gescheiten Index.

 

[coolmodi]

^Das, einen Eintrag löschen dauert nicht lange, auch wenn da 1500000 Einträge drin wären. In WP besteht ein Post aus einem Eintrag in "posts" und x Einträgen in "postmeta", wobei die post_id jeweils ein Index ist, bzw. sein sollte. Das Löschen dieser Einträge sollte im unteren Millisekundenbereich liegen, egal wie viel da drin ist. Selbst mit keinen Daten im RAM und HDD-Zugriff dauert das keine Sekunden.

Hab hier eine Seite, welche gerade 22k Posts hat, und selbst viel kompliziertere Abfragen mit mehreren JOINs laufen noch ohne caching, da es im schlimmsten Fall ~50ms dauert

Edit: Ich würde eher schauen ob da vielleicht ein Plugin sein Unwesen treibt, oder ob die DB tables falsch konfiguriert sind. Einfache "DELETE FROM x WHERE ID=y" sollten nämlich einfach nicht lange dauern. Das wird erst ein Problem, wenn du viele Tausend auf einmal löschen willst, wegen Rollback usw.

Kannst ja mal schauen wie viele Einträge ein Post in postmeta hat, vielleicht ist das ja zugemüllt, aber selbst das kann ich mir nicht in so einem Ausmaß vorstellen.