Möglichkeiten InnoDB zu Precachen

Deex

Member
Also mein Problem ist aktuell folgendes, wir haben mehere Datenbanken und eine ist die Quell Datenbank, aktuell etwa 43M Einträge die ausgewertet werden pro Eintrag und in diverse andere Datenbanken geschrieben werden.

Nun haben wir die derzeitigen möglichkeiten der Geschwindikeitsoptimierung scheinbar ausgereizt und selbst tricks wie die maximale Zeichen größe bei 241 zu belassen helfen nichts.

Nach Aktuellen Hochrechnungen wird er mit der Kalkulation etwa 110 Tage beschäftigt sein, was nicht akzeptabel ist. Das Problem ist nicht das die CPU voll augelastet ist sondern die IOWait Time massiv ist, laut Entwickler können die Einträge nur einzeln ausgewertet werden. Das ganze läuft schon als Prozess über die Shell und vorbei am Apache.

Also stelle ich mir die frage ob es möglich ist die InnoDB vorzucachen und als Beispiel jeweils 2 Gigabyte ständig vorzucachen um die IOWait zu reduzieren. Hat einer von euch erfahrung damit?

Ich würde mir das Optimal so vorstellen, den Prozess zu starten und eben zu sagen halte mir von der Tabelle Raw row 0 - 10 00000 im cache.

Hier nur mal ein Auszug wie "langsam" er ist http://pastebin.com/raw.php?i=55ibqmFa

Dieser Artikel sieht recht interessant aus, bin mir aber nicht sicher wie aktuell das noch ist, das ist schließlich von 2008
http://www.mysqlperformanceblog.com/2008/05/01/quickly-preloading-innodb-tables-in-the-buffer-pool/
 
Zuletzt bearbeitet:

nowayback

Well-Known Member
hi,

Keine Ahnung ob es dir hilft, aber ich bin vor einiger zeit mal auf LSI FastPath gestoßen.

ich habe halt keine ahnung ob sich das auch auf die wait i/o auswirkt, aber read/write beschleunigt das spürbar.


Grüße
nwb
 

Deex

Member
hi Nowayback,

leider besitze ich keinen Server mit der Software, aber ein Interessanter Ansatz dort mit anderen Raid Konfigurationen zu arbeiten.
 

Deex

Member
Hier meine Erfahrungsberichte, (soll eine art Notizblock sein bis ich etwas gefunden habe was helfen könnte)

Count Row Hack

Quickly preloading Innodb tables in the buffer pool - MySQL Performance Blog
der Count Row Hack um InnoDB dazu zu bringen bestimmte Rows zu Cachen hat bei mir komplett versagt, nachdem diese Berechnet waren hat er es aus dem Memcache wieder rausgeworfen. - Schade, da muss noch der weg her wie man es auch dauerhaft im RAM behält.

Hardware Optimierung mit hdparm

Erstmal eine Übersicht Schaffen wie flott der Cache ist

/dev/sda:
Timing cached reads: 2054 MB in 2.00 seconds = 1027.21 MB/sec
SDA2
Timing cached reads: 2044 MB in 2.00 seconds = 1021.67 MB/sec
Aktuelle Einstellungen Prüfen
/dev/sda:
multcount = 0 (off)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30401/255/63, sectors = 488397168, start = 0
/dev/sda2:
multcount = 0 (off)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30401/255/63, sectors = 480067584, start = 7813120
Dann schauen was die Festplatte überhaupt unterstützt
Offiziell wird Empfohlen auf eigenes Risiko folgende Einstellungen zu verwenden
multcount = 16 (laut http://dev.mysql.com/doc/refman/5.5/en/disk-issues.html)

Wie oben ausgelesen unterstützt die SDA 16
R/W multiple sector transfer: Max = 16 Current = ?
Allerdings warnt mich es ausdrücklich davor das zu machen
Use of -m is VERY DANGEROUS.
Only the old IDE drivers work correctly with -m with kernels up to at least 2.6.
29.
libata drives may fail and get hung if you set this flag.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.
Nach langem überlegen..no risk no fun, also aktivieren

:~# hdparm -m 16 --yes-i-know-what-i-am-doing /dev/sda
Anschließend mal den Durchsatz Testen
/dev/sda:
Timing cached reads: 2036 MB in 2.00 seconds = 1018.18 MB/sec
Hier wäre jedenfalls keine veränderung sichtbar.

Also abwarten auf die Ersten Ergebnisse der Beschleunigung beim IOWait Problem der alte IOWait Status war 80.25 im Durchschnitt.
>> Ein paar Tage später lässt sich tatsächlich durch diese maßnahme eine verbesserung erkennen, die IOWait time ist von 80.25 runter gegangen auf 77,86, dass ist mit Sicherheit nicht viel aber dennoch eine verbesserung.
 
Zuletzt bearbeitet:

Deex

Member
So ich möchte gerne die Ergebnisse Präsentieren,
ich halte fest das dieses Gebastel bei unserer Konfiguration mit der Berechnung von InnoDB einträgen die Geschwindigkeit massiv erhöht hat

Vorher: Dauer der Berechnung von 100 Einträgen, ca. 21-24 Sec
Nacher: Dauer der Berechnung von 100 Einträgen, ca. 0.5ms

Das hier ist nur für die Komplexen Berechnungen gedacht, und führt zu massiven Schwierigkeiten wenn man den Server als Webserver verwendet, ich würds daher nur machen wenn nötig.
Bitte das nicht einfach so übernehmen, ich sehe es nur als Anreiz mit den einstellungen etwas zu Spielen. Ich jedenfalls war dankbar nach endlosem suchen für ein paar Performance Tricks die mir den hintern gerettet haben. Es sei nochmal erwähnt der macht nichts anderes als eine Roh Datenbank (InnoDB) zeile für zeile zu Kalkulieren und anschließend in anderen Tabellen einzusortieren.

Mit Sicherheit kann man das weiter Optimieren doch mir spart es fast ein halbes Jahr meines lebens und ich bin so ganz happy ;)
635043.jpeg

max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 800
myisam-recover = BACKUP
max_connections = 4500
table_cache = 19400
query_cache_limit = 1280M
query_cache_type = 1
query_cache_size = 2560M
tmp_table_size = 1356M
max_heap_table_size = 1356M
sort_buffer_size = 160M
read_buffer_size = 20M
join_buffer_size = 450M
table_open_cache = 90000
innodb_flush_log_at_trx_commit = 0
 
Zuletzt bearbeitet:

Werbung

Top