Post on 15-Apr-2017
Die InnoDB Storage Engine:Konfiguration
Die wunderbare Welt von Isotopp
Sonntag, 3. Februar 2008Die InnoDB Storage Engine: Konfiguration
Links: Strukturen im Speicher, Rechts: Strukturen auf Disk.
Oben: LogStrukturen, Unten: TablespaceStrukturen.
Wie eine Transaktion physikalisch organisiert wird
Wenn in InnoDB eine neue Transaktion begonnen und erzeugt wird, ist sie ja nochnicht comitted und damit hat die Datenbank gegenüber der Anwendung noch keinVersprechen gemacht. Entsprechend brauchen die Daten aus einer solchenTransaktion auch noch nicht persistent gemacht zu werden.
InnoDB versucht, eine Transaktion im Speicher zusammen zu bauen. Dies ist derinnodb_log_buffer. Er sollte ausreichend groß gewählt werden, daß eine solcheTransaktion in den meisten Fällen im Speicher gehalten werden kann und nichtpartiell in ein Redo Log geschrieben werden muß. Eine Größe von 1 MB bis 8 MB istnormal.
Wenn die Transaktion comitted wird, muß InnoDB die Speicherseite von der Platteladen, in der der zu ändernde Record enthalten ist und die Änderung im Speicher
durchführen die Seite wird im InnoDB Bufferpool gespeichert. Seiten auf der Platteund im InnoDB Bufferpool sind jeweils 16 KB groß, und die innodb_buffer_pool_sizelegt fest, wieviel RAM als Cache für solche Seiten zur Verfügung steht. Diemodifizierte Speicherseite wird aber noch nicht zurück geschrieben. Stattdessen wirddie Transaktion an Ende des aktuellen RedoLog auf Platte geloggt und die Seite imBufferpool im Speicher als Dirty (= noch zu schreiben) markiert.
Als Dirty markierte Seiten werden in den Tablespace hinaus geschrieben, wenn einervon drei Fällen eintritt:
1. Das RedoLog, das als Ring Puffer organisiert ist, ist voll. Um zusätzlichenPlatz zu gewinnen müssen als Dirty markierte Seiten in RedoLog Reihenfolgeherausgeschrieben werden, sodaß der hintere Zeiger des RedoLogRingpuffers nach vorne verschoben werden kann und so ausreichend Platz imRedoLog geschaffen wird. Diese Situation nennt man einen Innodb_log_waitund sie wird im gleichnamigen Statuscounter registriert.
2. InnoDB benötigt für irgendwelche Aufgaben im Bufferpool eine Speicherseite,aber findet keine, die frei ist. Normalerweise kann eine solche Seite freigemacht werden, indem man irgendeine Seite aussucht, die nicht Dirty ist undsie freigibt: Wenn eine Seite nicht dirty ist, bedeutet daß, daß ihr Inhaltirgendwo auf der Platte zum Neu laden rumsteht. Wenn aber ausschließlich alsDirty markierte Seiten im Bufferpool stehen, geht das nicht und es müssen ersteinmal Seiten auf Platte geschrieben werden, damit Platz im Bufferpoolgeschaffen werden kann. Diese Situation nennt man einenInnodb_buffer_pool_wait_free und sie wird im gleichnamigen Statuscounterregistriert. InnoDB versucht diese Situation zu vermeiden: Wenn mehr alsinnodb_max_dirty_pages_pct Prozent viele Seiten als Dirty markiert sind, wirdein Checkpoint erzwungen und die als Dirty markierten Seiten werdenherausgeschrieben.
3. InnoDB fühlt sich unterbeschäftigt und beginnt im Sekundentakt damit, Batchesvon jeweils 64 als Dirty markierten Seiten auf die Platte zu schubsen. DieseSituation ist normal und wird nicht besonders registriert (dreht aber wie allediese Schreibzugriffe natürlich Innodb_pages_written hoch).
Relevante Konfigurationseinträge in der my.cnf:CODE:# Globaler Puffer zum Zusammenbau
# von Transaktionen vor dem Commit
innodb_log_buffer_size = 8M
# Größe des InnoDB Buffer Pools
# etwa 7080% des Hauptspeichers,
# auf einer Maschine mit 4G RAM
# also etwa 3G
#
# (/etc/sysctl.conf: vm.swappiness = 0!)
innodb_buffer_pool_size = 3072M
# Anzahl der InnoDB Bufferpool Seiten
# die Drity sein dürfen bevor ein
# Checkpoint erzwungen wird
#
# Default = 90, ok
innodb_max_dirty_pages_pct = 90
Relevante Zähler in SHOW GLOBAL STATUS:CODE:# Statuszähler für das Event "Redo Log voll"
Innodb_log_waits
# Statuszähler für das Event "Keine Seite# im Bufferpool frei"Innodb_buffer_pool_wait_free
Eine sinnvolle Größe für das RedoLog wählen
Ein WriteBurst kann durch das RedoLog "in der Zeit gestreckt" und so abgeflacht werden. Die zuleistende Arbeit die Fläche unter der Kurve ist jedoch (nahezu) gleich.
Das RedoLog loggt Transaktionen und die Einträge im Log sind proportional zurGröße der Transaktion, denn es werden Rows geloggt, keine Pages. Der Sinn desLogs ist es, das Zurückschreiben der 16KB großen Seiten in den Tablespaceverzögern zu können: Vielfach ist es so, daß in einer Speicherseite mehr als eineRow abgelegt wird und daß mehrere zeitlich eng beeinander liegende TransaktionenDaten in Rows ändern, die in derselben Page liegen, oder daß eine Row wieder undwieder überschrieben wird. Durch das Schreiben ins RedoLog werden dieseÄnderungen alle persistent gemacht, aber die Schreibzugriffe können als lineareWrites ohne Seeks recht schnell abgewickelt werden. Die Seeks, die beim Schreibenin den Tablespace unvermeidlich auftreten würden, können so verzögert undminimiert werden.
Normalerweise sollte das RedoLog immer groß genug sein und niemals voll laufen.Entsprechend sollte Innodb_log_waits immer 0 sein oder zumindest sich nichtbewegen, wenn man zwei Mal in Folge den Wert des Statuscounters abruft. Hat manregelmäßig Innodb_log_waitEvents, kann eine von zwei Situationen vorliegen: DerServer hat WriteBursts, die größer sind als das aktuelle RedoLog das RedoLogist zu klein und muß vergrößert werden. Oder der Server hat dauerhaft eine sehrgroße Schreiblast und das RedoLog würde überlaufen, egal wie groß es ist. Dannbraucht der Server mehr Spindeln, um schneller schreiben zu können oder die Datenmüssen partitioniert und auf mehrere Server verteilt werden.
Das RedoLog besteht per Default aus zwei Dateien (innodb_log_files_in_group), diejeweils 5 MB groß sind (innodb_log_file_size), ist also 10 MB groß. Dies ist zu klein.Idealerweise sollte es aus zwei Dateien bestehen, die jeweils zwischen 64 und 256MB groß sind, also 128 MB bis 512 MB groß sein. Es kann nicht größer sein als 4096MB = 4 GB, auch nicht auf einer Maschine mit 64 Bit Architektur.
Früher (vor MySQL 5.0) war es einmal wesentlich, das RedoLog nicht zu groß zu
machen: Wenn der Server crashte, ging InnoDB in die Log Recovery Phase undmußte diese erst abarbeiten bevor der Server wieder Verbindungen annahm. SeitMySQL 5.0 ist das nicht mehr so: Die Log Recovery Phase kann vom Server imHintergrund abgearbeitet werden, sodaß die Größe des RedoLogs nicht mehrbestimmend für die Dauer der ServerRecovery ist.
Ändert man diese Variable wenn ib_logfile0 und ib_logfile1 schon existieren, wirdInnoDB sich weigern zu starten und im ErrorLog des Servers eine Meldunghinterlassen, die im wesentlichen sagt, daß die Größe von vorgefundenen Logfilesnicht mit der Größe der konfigurierten Logfiles übereinstimmt.Um die Größe des RedoLogs zu ändern muß der Server runtergefahren werden,danach kontrolliert werden, daß der Shutdown sauber war und daß keinServerprozeß mehr läuft. Dann kann man die existierenden ib_logfile?Dateien zurSeite moven und den Wert der Konfigurationsvariablen ändern, um schließlich denServer zu starten. InnoDB wird nun Meldungen über neu angelegte Logfiles in dasErrorLog schreiben und die Files generieren. Ist der Server wieder online undbetriebsbereit, kann man die alten ib_logfile?Dateien löschen.
Relevante Konfigurationseinträge in der my.cnf:CODE:# Anzahl der ib_logfile?
innodb_log_files_in_group = 2
# Größe eines ib_logfile?innodb_log_file_size = 256M
Wie InnoDB die Datendateien ablegt
Wie bereits in dem ersten Artikel dieser Reihe angedeutet hat InnoDB zweiverschiedene Betriebsarten, in denen es seine Daten unterschiedlich organisiert:Wenn die Konfigurationsvariable innodb_file_per_table = 0 gesetzt ist, werden dieDaten in einem oder mehreren ibdataTablespacefiles abgelegt. Wenn dieinnodb_file_per_table = 1 gesetzt ist, wird stattdessen für jede Tabelle neben der.frmDatei für die Tabelle ein .ibdFile angelegt, das die Daten enthält.
Die TablespaceFiles werden, wenn ihre Namen nicht als absolute Pfadnamenangegeben werden, in innodb_data_home_dir angelegt. Ist auch diese Variable leer,wird als Default datadir angenommen. Der DefaultString für innodb_data_file_pathist "ibdata1:10M:autoextend".
In den meisten DefaultInstallationen bedindet sich also eine Datei ibdata1 in/var/lib/mysql. Diese Datei ist zunächst 10M groß und wächst dann in Schritten von8MB (weil innodb_autoextend_increment = 8 per Default auf 8 steht).
Diese Defaults sind für den effizienten Betrieb jedoch nicht sehr gut gewählt.Zunächst einmal sollte man innodb_file_per_table = 1 setzen. Auf diese Weisebekommt man pro Tabelle ein .ibdFile. Dadurch hat man die Möglichkeit, denPlatzverbrauch in der Datenbank Tabellenweise auch von außen zu messen undman gewinnt die Möglichkeit, durch ein "ALTER TABLE t ENGINE=innodb" bzw. ein"OPTIMIZE TABLE t" den leeren Platz in solchen Dateien dem Betriebssystemwieder zur Disposition zur Stellen.
Wählt man innodb_file_per_table = 1, dann sind die Defaults fürinnodb_data_file_path und innodb_autoextend_increment ausreichend, denn imibdata1File wird lediglich das InnoDBinterne ShadowDatadictionary und das Undo
Log abgelegt. Auf solchen Installationen erhält man am Ende meist ein ibdata1 in der
Größe von 256M bis 1024M, je nach Maximalbelastung des UndoLogs.
Muß oder will man InnoDB mit innodb_file_per_table = 0 betreiben, dann werden die
Daten ebenfalls im ibdata1File abgelegt. Man sollte vorher sicherstellen, daß das
Betriebssystem und auch alle Utilities zur Datensicherung mit sehr großen Dateien
korrekt umgehen können. Ist das nicht der Fall, wird man ein sehr kompliziertes
innodb_data_file_pathStatement benötigen, das ausreichend viele ibdataFiles
definiert jedes von ihnen wahrscheinlich so um die 2G groß, oder was immer das
Limit hier ist.
Angenommen der Support im Betriebssystem für sehr große einzelne Files ist
ausreichend, dann wird man mit Sicherheit die Schrittweite vergrößern wollen, in der
die ibdataDatei vergrößert wird inoodb_autoextend_increment = 8 sind als
Schrittweite sicher zu klein. Stattdessen ist es empfehlenswert, sich das Dateisystem
anzusehen, auf dem die Datei angelegt wird, und als Schrittweite etwa 1% bis 5%
der gesamten Dateisystemgröße zu wählen. Auf diese Weise wird das Dateisystem
nach Bedarf in 20 bis 100 Schritten aufgefüllt. Das ist hinreichend klein granular,um
flexibel zu sein, aber das Betriebssystem hat dennoch ausreichend wenige Allocation
Requests um die Datei weitgehend unfragmentiert zu erzeugen. Auf einem
Dateisystem mit 200G Platz wird man also eine Schrittweite von 2048 (2048M = 1%
von 200G) oder gar 10240 (10G = 10240M = 5% von 200G) wählen.
In jedem Fall sollte ein TablespaceFile so definiert sein, daß es auf "autoextend"
konfiguriert ist, insbesondere auch bei innodb_file_per_table = 1. Wenn nämlich
durch viele Schreibzugriffe während einer lang andauernden Transaktion das Undo
Log vorübergehend anschwillt und dabei nicht genug Platz im ibdataFile ist, kommt
es zu sehr seltsamen und schwer zu diagnostizierbaren Fehlermeldungen, obwohl
auf Dateisystemebene noch genug Platz vorhanden ist.
Außerdem ist zu bedenken, daß InnoDB mehr Filehandles verbraucht, wenn
innodb_file_per_table = 1 gesetzt ist entsprechend sollte man innodb_open_files
größer wählen, zum Beispiel ein Filehandle pro Tabelle. Das zieht unter Umständen
auch eine Anpassung von open_files_limit nach sich hier müssen aber noch
Filehandles für .frmDateien und für MyISAMTabellen mit dazu gerechnet werden.
Relevante Konfigurationseinträge in der my.cnf (File per Table):
CODE:
# Soll InnoDB mit einer ibdDatei pro Tabelle betrieben werden
innodb_file_per_table = 1
# Wo soll die ibdataDatei abgelegt werden (Default: $datadir)# innodb_data_home_dir
# Wie soll die Datei angelegt werden?innodb_data_file_path = "ibdata1:10M:autoextend"
# In was für Schritten (MB) soll die Datei wachsen?innodb_autoextend_increment = 8
# Filehandles hoch drehen# Ein Filehandle pro InnoDB Tabelleinnodb_open_files = 2048
# Das hier kann man in Linux auch # getrost richtig hoch drehenopen_files_limit = 32768
Relevante Konfigurationseinträge in der my.cnf (SingleTablespace):
CODE:
# Soll InnoDB mit einer ibdDatei pro Tabelle betrieben werden
innodb_file_per_table = 0
# Wo soll die ibdataDatei abgelegt werden (Default: $datadir)# innodb_data_home_dir
# Wie soll die Datei angelegt werden?# Tablespace wird hier als 2G große Datei angelegt.innodb_data_file_path = "ibdata1:2048M:autoextend"
# In was für Schritten (MB) soll die Datei wachsen?# Tablespace wächst hier in 2G Schritten # (1% einer 200GPlatte)innodb_autoextend_increment = 2048
Wie InnoDB seine Daten auf die Platte malt
Wie wir oben gesehen haben, werden Daten bei der Ausführung von schreibendenKommandos in InnoDB nur gelesen ein INSERT oder UPDATEStatement erzeugteinen Logbuffer und als Dirty markierte Pages im InnoDB Bufferpool für die Datenund das UndoLog. Bei einem Commit wird der Logbuffer ins RedoLog geschrieben jedenfalls wenn innodb_flush_log_at_trx_commit = 1 gesetzt ist. MySQL führt denCommit dann als einen Write ins RedoLog und eine FlushOperation durch. Letztereleert dann die BetriebssystemPuffer in die PlattenPuffer und die PlattenPuffer aufdie Platte.
Selbst dies ist jedoch eine relativ langsame Operation, bei der Wartezeiten voneinigen Millisekunden auf eine langsame mechanische Platte auftreten jedenfallswenn man nicht eine spezielle Platte für das RedoLog hat, die ausbatteriegepuffertem RAM besteht. Daher besteht die Möglichkeit, InnoDB auf eineWeise zu betreiben, bei das Warten auf die Platte vom Commit mehr oder wenigerstark entkoppelt wird.
Bei innodb_flush_log_at_trx_commit = 2 ist es so, daß ein Commit die Daten ausdem MySQL in die BetriebssystemPuffer überträgt ("WRITE"), aber ein Schreibender BetriebssystemPuffer auf die Platte ("FLUSH") nur einmal pro Sekundeerzwingt. Dies bewirkt, daß bei einem Absturz des MySQL Serverprozesses keineDaten verloren gehen können, bei einem Absturz der ServerHardware jedoch bis zueiner Sekunde RedoLog fehlen kann. Es existieren also möglicherweise Daten, fürdie der Anwendung signalisiert wurde, daß sie geschrieben wurden, die aber nichtgeschrieben worden sind. Dafür ist diese Betriebsart durch die WegfallendenWartezeiten auf die langsamen Festplatten sehr viel schneller.
Je nach Geschäftsprozeß, der hier implementiert wird, kann es sein, daß dieserFehler relevant ist oder nicht aus der Sicht der Informatik ist"innodb_flush_log_at_trx_commit = 2" eine Verletzung des ACIDPrinzips nach Coddund daher falsch. Aus der Sicht der Betriebswirtschaft kann das Verhalten dennochkorrekt sein. Das wäre zum Beispiel dann der Fall, wenn die verlorenen Datenreproduzierbar wären, oder wenn die Korrektur der falschen Daten durchKundenservice kostengünstiger wäre als die Hardware, die notwendig wäre, um diebenötigte Performance bei innodb_flush_log_at_trx_commit = 1 zu liefern.
Bei innodb_flush_log_at_trx_commit = 0 wird das Schreibverhalten von InnoDB nochweiter gelockert "Commit" ist nun eine rein logische Operation, die keine Writes undkeine Flushes per initiiert. Stattdessen wird das RedoLog einmal pro Sekunde durch"WRITE" an das Betriebssystem übertragen und danach durch "FLUSH" einSchreiben der BetriebssystemPuffer auf die Platte erzwungen. Dies ist jedoch nichtwesentlich schneller als die Einstellung "2".
In jedem Fall wird die Datenbank nach einem Crash des MySQLServerprozessesoder der Hardware beim Wiederanlauf recovern müssen. In jedem Fall wird dieDatenbank wieder in einen konsistenten transaktionalen Zustand recovern,unabhängig von den Einstellungen für innodb_flush_log_at_trx_commit.Unterschiedlich wird lediglich der Punkt in der Zeit sein (die letzte geseheneTransaktionsnummer, zu der hin recovert wird), den die Datenbank nach demWiederanlauf und der Recovery erreicht.
Das Verhalten von InnoDB läßt sich außerdem noch mit Hilfe derinnodb_flush_method beeinflussen. In Unix sind die zugelassenen Werte für dieseVariable "fdatasync" (der Default), "O_DSYNC", "O_DIRECT", "littlesync", "nosync",in Windows werden "normal" und "unbuffered" (der Default) sowie"async_unbuffered" (der Default in Windows XP und Windows 2000) erkannt.
Die Idee bei O_DSYNC und O_DIRECT ist, die Dateien des RedoLog auf eineWeise zu öffnen, die den Puffermechanismus des Betriebssystems komplettausschaltet die Datenbank puffert Daten im innodb_buffer_pool und im RedoLogselbst und es besteht gar keine Notwendigkeit für den File System Buffer Cache desBetriebssystems. Setzt man innodb_flush_method zum Beispiel auf O_DIRECT inLinux, wird InnoDB nur noch WRITEAufrufe durchführen, aber die Daten nicht mehrmit FLUSH auf die Platte zwingen. Dies ist auch nicht mehr notwendig, da ja jederWRITE bei O_DIRECT ungepuffert direkt auf die Platte geht.
Relevante Konfigurationseinträge in der my.cnf (für Linux):CODE:# Gewünschtes Schreibverhalten für viele Anwendungen
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
# Alternativ für ACIDCompliance:
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
Concurrency Tickets
InnoDB funktioniert besser, wenn die Anzahl der Threads begrenzt ist, die geradeOperationen innerhalb der Storage Engine ausführen. Es können sich gleichzeitiginnodb_thread_concurrency viele Threads in InnoDB aufhalten. Es existierenverschiedene Formeln, mit denen man auf sinnvolle Werte für diese Variablekommen kann ("Anzahl der Cores mal zwei", "Summe aus Cores und Platten =Anzahl der Dinge, die wir in Bewegung halten wollen"), aber es ist klar, daß aktuelleVersionen von InnoDB schlechtere Performance zeigen, wenn der Wert zu hoch wird derzeit scheint das Limit je nach Load 16 oder 32 zu sein.
Hat man mehr gleichzeitige Transaktionen als innodb_thread_concurrency zuläßt,müssen überzählige Threads warten. Oft ist es jedoch so, daß ein Thread über dasHandler Interface in die Storage Engine hineingeht, dort eine Operation wie KeyLookup durchführt, um dann in die MySQL SQLSchicht zurück zu kehren. Um eineeinzelne Query zu beantworten sind unter Umständen sehr viele solche Übergängenotwendig.
Damit ein Thread nun nicht jedesmal warten muß, wenn er in die InnoDB StorageEngine will, bekommt er innodb_concurrency_tickets viele "Tickets", wenn ihmZugang zur Engine gewährt wird. Er kann also entsprechend viele Wechsel zwischenSQLSchicht und Storage Engine machen, ohen daß er erneut warten muß. Mankann hier mit verschiedenen Werten experimentieren, wenn man eine Maschine mit
sehr vielen CPUs und Festplatten hat und eine sehr hohe Thread Concurrency fürInnoDB hat. Sinnvolle Werte sind "Anzahl der Records in einem Block", "... in einemSegment" oder "Anzahl der Records, die in dieser Query gelesen werden".
Eine weitere Variable ist die innodb_commit_concurrency, die die Anzahl derThreads limitiert, die gleichzeitig comitten können. Sie begrenzt denSpeicherverbrauch im Logbuffer und reguliert Contention auf dem RedoLog.
Aus historischen Gründen existiert noch eine Variable thread_concurrency. Der Wert,der hier übergeben wird, endet im Code direkt in einem Aufruf vonpthread_setconcurrency(), wird aber sonst nicht weiter verwendet. Diese Funktionbewirkt in den aktuellen Implementierungen von pthreads in Linux und Solaris garnicht, in Versionen von pthreads bis einschließlich Solaris 8 hat sie sich intern aufdas Mapping von Threads zu Kernelthreads ausgewirkt. Für aktuelle Versionen vonBetriebssystemen und MySQL ist die Variable und der dort eingestellte Werte nichtmehr relevant.
Relevante Konfigurationseinträge in der my.cnf:CODE:innodb_commit_concurrency = 0
innodb_thread_concurrency = 16innodb_concurrency_tickets = 500
Metadatenstrukturen
Wenn ich nach dem gehe, was ich bei Kunden vorfinde, dann istinnodb_additional_mem_pool_size eine Variable, die sehr häufig auf seltsame Wertegesetzt wird. Die Variable bestimmt die Größe eines Puffers für Metadatenstrukturen,ist also ein Cache für das interne InnoDB Data Dictionary. Der DefaultWert ist 1 MBund im normalen Betrieb braucht dieser Puffer niemals größer als 8 MB gesetzt zuwerden. Ein Kunde, der Tests mit 40.000 InnoDBTabellen vorgenommen hat, hathier tatsächlich einmal einen Wert von 20 MB benötigt.
Relevante Konfigurationseinträge in der my.cnf:
CODE:innodb_additional_mem_pool_size = 4M
Gesamtübersicht
Eine Gesamtübersicht über alle InnoDBStatusvariablen undKonfigurationsparameter findet man auf 12.2.4. InnoDB Startup Options andSystem Variables im Handbuch.Geschrieben von Kristian Köhntopp in MySQL um 11:50 | Kommentare (4) | Trackbacks (5)
TrackbacksTrackbackURL für diesen Eintrag
InnoDB konfigurieren
Eigentlich sollte an dieser Stelle ein (leienhafter) Beitrag von mir zur Konfiguration vonInnoDB (ent)stehen. MySQLGott Isotpp ist mir zuvor gekommen. Besser kann manes denke ich nicht erklären. Danke!Weblog: Ich bin root
Aufgenommen: Feb 03, 13:33
InnoDB KonfigurationSehr netter Artikel ueber die Konfiguration der InnoDB Storage Engine von KristianKöhntopp.Weblog: Plog of Christian BerendtAufgenommen: Feb 05, 10:43
InnoDB Konfiguration einfach erklärtKristian Köhntopp hat mal wieder einen Artikel der Sorte "so will ich das erklärtbekommen" geschrieben. Diesmal über "Die InnoDB Storage Engine: Konfiguration"Lesen lohnt sich!Weblog: :: handcode.de ::Aufgenommen: Feb 05, 14:52
InnoDB InternalsChristian Köhntopp hat einen sehr schönen Artikel über die Funktionsweise vonInnoDB sowie der Bedeutung der einzelnen InnoDB spezifischen Optionen in dermy.cnf geschrieben. Vielen Dank! ...Weblog: I, BlogAufgenommen: Feb 06, 17:43
Configuring InnoDB An InnoDB tutorialThis is the english translation of another article in my german language blog. How aretransactions organized physically When InnoDB creates a new transaction it is not yetcommitted. The database has not yet made any promises to the application andWeblog: MySQLdumpAufgenommen: Feb 07, 08:59
KommentareAnsicht der Kommentare: (Linear | Verschachtelt)
Wow, vielen Dank für diesen tollen Artikel. Genau den hätte ich vor 3 Tagen gesucht. :)#1 Teg am 03.02.2008 13:02
Sieht ja ziemlich so aus, wie wir das haben.
Unsere Hauptanwendung ist ein AAA backend. Wir haben einen Master mit relativwenigen writes (wenige Dutzend pro Minute), auf jedem AAA server ist ein readonlyslave. Die Datenbank passt gut in den Speicher, demensprechend haben wirinnodb_buffer_pool_size nur ca. 30% größer als die innodbFiles gesetzt. Ist aber m.E.unkritisch, solange man mysqld nicht mit memlock laufen hat.
Interessant finde ich noch innodb_thread_concurrency. Effektiv haben wir ja nur denslave thread, der writes macht, wir möchten aber natürlich möglichst viele gleichzeitigereads. Aktuell haben wir innodb_thread_concurrency=0, also kein Limit, das sollmutexoverhead sparen und tut bis jetzt ohne Probleme. Meinungen dazu? (Falls dasüberhaupt noch jemand liest...)Mysql ist 5.0.51a (debian lenny).#2 Jakob am 07.12.2009 16:07
MySQL 5.1 ist in typischen Benchmarks etwas langsamer als ein MySQL 5.0 diese Benchmarks erzeugen aber in der Regel nicht genügend Concurrency. Füruns ist 5.1 auf NehalemMaschinen etwa 30% schneller als 5.0, und MySQL 5.4
noch einmal 20% schneller als 5.1 (aber leider nicht GA).
Diese Umstellung bringt wahrscheinlich weitaus mehr als Spielereien an den
TuningParametern von 5.0 betreffend Concurrency.
#2.1 Isotopp (Link) am 07.12.2009 20:19
Lt. MySQL 5.1 Doku ist innodb_open_files unabhängig von open_files_limit. Das liest
sich in diesem Artikel anders. Was ist nun richtig?
Und unabhängig davon, dass beides funktioniert was ist die bevorzugte
Schreibweise von ConfigVariablen: Underscore oder Dash?
#3 Laph am 04.02.2011 08:36
Kommentar schreibenName
EMail
Homepage
Antwort zu
Kommentar
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann
ein Wort unterstrichen werden.
Um maschinelle und automatische Übertragung von Spamkommentaren
zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der
Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben
wurde, kann der Kommentar angenommen werden. Bitte beachten Sie,
dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren
anzuwenden.
Hier die Zeichenfolge der SpamschutzGrafik eintragen:
BBCodeFormatierung erlaubt Daten merken?