Die MySQL InnoDB Storage Engine (Teil 2)

of 10 /10
Die InnoDB Storage Engine: Konfiguration Die wunderbare Welt von Isotopp Sonntag, 3. Februar 2008 Die 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 noch nicht comitted und damit hat die Datenbank gegenüber der Anwendung noch kein Versprechen gemacht. Entsprechend brauchen die Daten aus einer solchen Transaktion auch noch nicht persistent gemacht zu werden. InnoDB versucht, eine Transaktion im Speicher zusammen zu bauen. Dies ist der innodb_log_buffer. Er sollte ausreichend groß gewählt werden, daß eine solche Transaktion in den meisten Fällen im Speicher gehalten werden kann und nicht partiell in ein Redo Log geschrieben werden muß. Eine Größe von 1 MB bis 8 MB ist normal. Wenn die Transaktion comitted wird, muß InnoDB die Speicherseite von der Platte laden, in der der zu ändernde Record enthalten ist und die Änderung im Speicher

Embed Size (px)

Transcript of Die MySQL InnoDB Storage Engine (Teil 2)

  • Die InnoDB Storage Engine:Konfiguration

    Die wunderbare Welt von Isotopp

    Sonntag,3.Februar2008DieInnoDBStorageEngine:Konfiguration

    Links:StrukturenimSpeicher,Rechts:StrukturenaufDisk.

    Oben:LogStrukturen,Unten:TablespaceStrukturen.

    WieeineTransaktionphysikalischorganisiertwird

    Wenn in InnoDBeineneueTransaktionbegonnenunderzeugtwird, istsie janochnicht comitted unddamit hat dieDatenbankgegenber derAnwendungnoch keinVersprechen gemacht. Entsprechend brauchen die Daten aus einer solchenTransaktionauchnochnichtpersistentgemachtzuwerden.

    InnoDB versucht, eineTransaktion imSpeicher zusammen zu bauen.Dies ist derinnodb_log_buffer. Er sollte ausreichend gro gewhlt werden, da eine solcheTransaktion in den meisten Fllen im Speicher gehalten werden kann und nichtpartiellineinRedoLoggeschriebenwerdenmu.EineGrevon1MBbis8MBistnormal.

    WenndieTransaktioncomittedwird,mu InnoDBdieSpeicherseitevonderPlatteladen, inderder zunderndeRecordenthalten ist unddienderung imSpeicher

  • durchfhrendieSeitewirdimInnoDBBufferpoolgespeichert.SeitenaufderPlatteundimInnoDBBufferpoolsindjeweils16KBgro,unddieinnodb_buffer_pool_sizelegt fest, wieviel RAM als Cache fr solche Seiten zur Verfgung steht. DiemodifizierteSpeicherseitewirdabernochnichtzurckgeschrieben.StattdessenwirddieTransaktionanEndedesaktuellenRedoLogaufPlattegeloggtunddieSeiteimBufferpoolimSpeicheralsDirty(=nochzuschreiben)markiert.

    AlsDirtymarkierteSeitenwerdenindenTablespacehinausgeschrieben,wenneinervondreiFlleneintritt:

    1.Das RedoLog, das als Ring Puffer organisiert ist, ist voll. Um zustzlichenPlatzzugewinnenmssenalsDirtymarkierteSeiteninRedoLogReihenfolgeherausgeschrieben werden, soda der hintere Zeiger des RedoLogRingpuffersnachvorneverschobenwerdenkannundsoausreichendPlatzimRedoLoggeschaffenwird.DieseSituationnenntmaneinen Innodb_log_waitundsiewirdimgleichnamigenStatuscounterregistriert.

    2.InnoDBbentigt fr irgendwelcheAufgaben imBufferpooleineSpeicherseite,aber findet keine, die frei ist. Normalerweise kann eine solche Seite freigemachtwerden,indemmanirgendeineSeiteaussucht,dienichtDirtyistundsie freigibt: Wenn eine Seite nicht dirty ist, bedeutet da, da ihr InhaltirgendwoaufderPlattezumNeuladenrumsteht.WennaberausschlielichalsDirtymarkierteSeitenimBufferpoolstehen,gehtdasnichtundesmssenersteinmal 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_pctProzentvieleSeitenalsDirtymarkiertsind,wirdein Checkpoint erzwungen und die als Dirty markierten Seiten werdenherausgeschrieben.

    3.InnoDBfhltsichunterbeschftigtundbeginntimSekundentaktdamit,Batchesvon jeweils 64 alsDirtymarkiertenSeiten auf diePlatte zu schubsen.DieseSituation ist normal und wird nicht besonders registriert (dreht aber wie alledieseSchreibzugriffenatrlichInnodb_pages_writtenhoch).

    RelevanteKonfigurationseintrgeindermy.cnf:CODE:#GlobalerPufferzumZusammenbau

    #vonTransaktionenvordemCommit

    innodb_log_buffer_size=8M

    #GredesInnoDBBufferPools

    #etwa7080%desHauptspeichers,

    #aufeinerMaschinemit4GRAM

    #alsoetwa3G

    #

    #(/etc/sysctl.conf:vm.swappiness=0!)

    innodb_buffer_pool_size=3072M

    #AnzahlderInnoDBBufferpoolSeiten

    #dieDrityseindrfenbevorein

    #Checkpointerzwungenwird

    #

    #Default=90,ok

    innodb_max_dirty_pages_pct=90

    RelevanteZhlerinSHOWGLOBALSTATUS:CODE:#StatuszhlerfrdasEvent"RedoLogvoll"

    Innodb_log_waits

  • #StatuszhlerfrdasEvent"KeineSeite#imBufferpoolfrei"Innodb_buffer_pool_wait_free

    EinesinnvolleGrefrdasRedoLogwhlen

    EinWriteBurstkanndurchdasRedoLog"inderZeitgestreckt"undsoabgeflachtwerden.DiezuleistendeArbeitdieFlcheunterderKurveistjedoch(nahezu)gleich.

    Das RedoLog loggt Transaktionen und die Eintrge im Log sind proportional zurGrederTransaktion,denneswerdenRowsgeloggt,keinePages.DerSinndesLogs ist es, das Zurckschreiben der 16KB groen Seiten in den Tablespaceverzgern zu knnen:Vielfach ist es so, da in einerSpeicherseitemehr als eineRowabgelegtwirdunddamehrerezeitlichengbeeinanderliegendeTransaktionenDateninRowsndern,dieinderselbenPageliegen,oderdaeineRowwiederundwieder berschrieben wird. Durch das Schreiben ins RedoLog werden diesenderungen alle persistent gemacht, aber die Schreibzugriffe knnen als lineareWritesohneSeeksrechtschnellabgewickeltwerden.DieSeeks,diebeimSchreibenin den Tablespace unvermeidlich auftreten wrden, knnen so verzgert undminimiertwerden.

    NormalerweisesolltedasRedoLogimmergrogenugseinundniemalsvolllaufen.Entsprechend sollte Innodb_log_waits immer 0 sein oder zumindest sich nichtbewegen,wennmanzweiMalinFolgedenWertdesStatuscountersabruft.Hatmanregelmig Innodb_log_waitEvents,kanneinevonzweiSituationenvorliegen:DerServerhatWriteBursts,diegrersindalsdasaktuelleRedoLogdasRedoLogist zu klein undmu vergrert werden.Oder der Server hat dauerhaft eine sehrgroeSchreiblastunddasRedoLogwrdeberlaufen,egalwiegroes ist.DannbrauchtderServermehrSpindeln,umschnellerschreibenzuknnenoderdieDatenmssenpartitioniertundaufmehrereSerververteiltwerden.

    DasRedoLogbestehtperDefaultauszweiDateien(innodb_log_files_in_group),diejeweils5MBgrosind(innodb_log_file_size),istalso10MBgro.Diesistzuklein.IdealerweisesollteesauszweiDateienbestehen,diejeweilszwischen64und256MBgrosind,also128MBbis512MBgrosein.Eskannnichtgrerseinals4096MB=4GB,auchnichtaufeinerMaschinemit64BitArchitektur.

    Frher (vorMySQL5.0)wareseinmalwesentlich,dasRedoLognichtzugrozu

  • machen:Wenn der Server crashte, ging InnoDB in die Log Recovery Phase undmute 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 Gre des RedoLogs nicht mehrbestimmendfrdieDauerderServerRecoveryist.

    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 imwesentlichensagt, dadieGrevonvorgefundenenLogfilesnichtmitderGrederkonfiguriertenLogfilesbereinstimmt.Um dieGre desRedoLogs zu ndernmu der Server runtergefahrenwerden,danach kontrolliert werden, da der Shutdown sauber war und da keinServerprozemehr luft.Dann kannmandie existierenden ib_logfile?Dateien zurSeitemovenunddenWertderKonfigurationsvariablenndern,umschlielichdenServerzustarten. InnoDBwirdnunMeldungenberneuangelegteLogfiles indasErrorLog schreiben und die Files generieren. Ist der Server wieder online undbetriebsbereit,kannmandiealtenib_logfile?Dateienlschen.

    RelevanteKonfigurationseintrgeindermy.cnf:CODE:#Anzahlderib_logfile?

    innodb_log_files_in_group=2

    #Greeinesib_logfile?innodb_log_file_size=256M

    WieInnoDBdieDatendateienablegt

    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 fr jede Tabelle neben der.frmDateifrdieTabelleein.ibdFileangelegt,dasdieDatenenthlt.

    Die TablespaceFiles werden, wenn ihre Namen nicht als absolute Pfadnamenangegebenwerden,ininnodb_data_home_dirangelegt.IstauchdieseVariableleer,wirdalsDefault datadir angenommen.DerDefaultString fr innodb_data_file_pathist"ibdata1:10M:autoextend".

    In den meisten DefaultInstallationen bedindet sich also eine Datei ibdata1 in/var/lib/mysql.DieseDatei istzunchst10MgroundwchstdanninSchrittenvon8MB(weilinnodb_autoextend_increment=8perDefaultauf8steht).

    Diese Defaults sind fr den effizienten Betrieb jedoch nicht sehr gut gewhlt.Zunchst einmal sollte man innodb_file_per_table = 1 setzen. Auf diese Weisebekommt man pro Tabelle ein .ibdFile. Dadurch hat man die Mglichkeit, denPlatzverbrauch in der Datenbank Tabellenweise auch von auen zu messen undmangewinntdieMglichkeit,durchein"ALTERTABLEtENGINE=innodb"bzw.ein"OPTIMIZE TABLE t" den leeren Platz in solchen Dateien dem BetriebssystemwiederzurDispositionzurStellen.

    Whlt man innodb_file_per_table = 1, dann sind die Defaults frinnodb_data_file_path und innodb_autoextend_increment ausreichend, denn imibdata1FilewirdlediglichdasInnoDBinterneShadowDatadictionaryunddasUndo

  • Logabgelegt.AufsolchenInstallationenerhltmanamEndemeisteinibdata1inder

    Grevon256Mbis1024M,jenachMaximalbelastungdesUndoLogs.

    MuoderwillmanInnoDBmitinnodb_file_per_table=0betreiben,dannwerdendie

    Daten ebenfalls im ibdata1File abgelegt.Man sollte vorher sicherstellen, da das

    BetriebssystemundauchalleUtilitieszurDatensicherungmitsehrgroenDateien

    korrekt umgehen knnen. Ist das nicht der Fall, wird man ein sehr kompliziertes

    innodb_data_file_pathStatement bentigen, das ausreichend viele ibdataFiles

    definiert jedesvonihnenwahrscheinlichsoumdie2Ggro,oderwas immerdas

    Limithierist.

    Angenommen der Support im Betriebssystem fr sehr groe einzelne Files ist

    ausreichend,dannwirdmanmitSicherheitdieSchrittweitevergrernwollen,inder

    die ibdataDatei vergrert wird inoodb_autoextend_increment = 8 sind als

    Schrittweitesicherzuklein.Stattdessenistesempfehlenswert,sichdasDateisystem

    anzusehen,aufdemdieDateiangelegtwird,undalsSchrittweiteetwa1%bis5%

    dergesamtenDateisystemgrezuwhlen.AufdieseWeisewirddasDateisystem

    nachBedarfin20bis100Schrittenaufgefllt.Dasisthinreichendkleingranular,um

    flexibelzusein,aberdasBetriebssystemhatdennochausreichendwenigeAllocation

    Requests um die Datei weitgehend unfragmentiert zu erzeugen. Auf einem

    Dateisystemmit200GPlatzwirdmanalsoeineSchrittweitevon2048(2048M=1%

    von200G)odergar10240(10G=10240M=5%von200G)whlen.

    In jedem Fall sollte ein TablespaceFile so definiert sein, da es auf "autoextend"

    konfiguriert ist, insbesondere auch bei innodb_file_per_table = 1. Wenn nmlich

    durchvieleSchreibzugriffewhrendeiner langandauerndenTransaktiondasUndo

    LogvorbergehendanschwilltunddabeinichtgenugPlatzimibdataFileist,kommt

    es zu sehr seltsamenund schwer zu diagnostizierbarenFehlermeldungen, obwohl

    aufDateisystemebenenochgenugPlatzvorhandenist.

    Auerdem ist zu bedenken, da InnoDB mehr Filehandles verbraucht, wenn

    innodb_file_per_table = 1 gesetzt ist entsprechend sollteman innodb_open_files

    grerwhlen,zumBeispieleinFilehandleproTabelle.DasziehtunterUmstnden

    auch eine Anpassung von open_files_limit nach sich hier mssen aber noch

    Filehandlesfr.frmDateienundfrMyISAMTabellenmitdazugerechnetwerden.

    RelevanteKonfigurationseintrgeindermy.cnf(FileperTable):

    CODE:

    #SollInnoDBmiteineribdDateiproTabellebetriebenwerden

    innodb_file_per_table=1

    #WosolldieibdataDateiabgelegtwerden(Default:$datadir)#innodb_data_home_dir

    #WiesolldieDateiangelegtwerden?innodb_data_file_path="ibdata1:10M:autoextend"

    #InwasfrSchritten(MB)solldieDateiwachsen?innodb_autoextend_increment=8

    #Filehandleshochdrehen#EinFilehandleproInnoDBTabelleinnodb_open_files=2048

    #DashierkannmaninLinuxauch#getrostrichtighochdrehenopen_files_limit=32768

    RelevanteKonfigurationseintrgeindermy.cnf(SingleTablespace):

    CODE:

  • #SollInnoDBmiteineribdDateiproTabellebetriebenwerden

    innodb_file_per_table=0

    #WosolldieibdataDateiabgelegtwerden(Default:$datadir)#innodb_data_home_dir

    #WiesolldieDateiangelegtwerden?#Tablespacewirdhierals2GgroeDateiangelegt.innodb_data_file_path="ibdata1:2048M:autoextend"

    #InwasfrSchritten(MB)solldieDateiwachsen?#Tablespacewchsthierin2GSchritten#(1%einer200GPlatte)innodb_autoextend_increment=2048

    WieInnoDBseineDatenaufdiePlattemalt

    Wiewirobengesehenhaben,werdenDatenbeiderAusfhrungvonschreibendenKommandosinInnoDBnurgeleseneinINSERToderUPDATEStatementerzeugteinenLogbuffer undalsDirtymarkiertePages im InnoDBBufferpool fr dieDatenunddasUndoLog.BeieinemCommitwirdderLogbufferinsRedoLoggeschrieben jedenfallswenninnodb_flush_log_at_trx_commit=1gesetzt ist.MySQLfhrtdenCommitdannalseinenWriteinsRedoLogundeineFlushOperationdurch.LetztereleertdanndieBetriebssystemPuffer indiePlattenPufferunddiePlattenPufferaufdiePlatte.

    Selbst dies ist jedoch eine relativ langsame Operation, bei der Wartezeiten voneinigenMillisekunden auf eine langsamemechanischePlatte auftreten jedenfallswenn man nicht eine spezielle Platte fr das RedoLog hat, die ausbatteriegepuffertemRAM besteht. Daher besteht dieMglichkeit, InnoDB auf eineWeisezubetreiben,beidasWartenaufdiePlattevomCommitmehroderwenigerstarkentkoppeltwird.

    Bei innodb_flush_log_at_trx_commit = 2 ist es so, da einCommit dieDaten ausdemMySQL in dieBetriebssystemPuffer bertrgt ("WRITE"), aber einSchreibender BetriebssystemPuffer auf die Platte ("FLUSH") nur einmal pro Sekundeerzwingt.Dies bewirkt, da bei einemAbsturz desMySQLServerprozesses keineDatenverlorengehenknnen,beieinemAbsturzderServerHardwarejedochbiszueinerSekundeRedoLogfehlenkann.EsexistierenalsomglicherweiseDaten, frdiederAnwendungsignalisiertwurde,dasiegeschriebenwurden,dieabernichtgeschrieben worden sind. Dafr ist diese Betriebsart durch die WegfallendenWartezeitenaufdielangsamenFestplattensehrvielschneller.

    Je nach Geschftsproze, 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"eineVerletzungdesACIDPrinzipsnachCoddunddaherfalsch.AusderSichtderBetriebswirtschaftkanndasVerhaltendennochkorrekt sein. Das wre zum Beispiel dann der Fall, wenn die verlorenen Datenreproduzierbar wren, oder wenn die Korrektur der falschen Daten durchKundenservicekostengnstigerwrealsdieHardware,dienotwendigwre,umdiebentigtePerformancebeiinnodb_flush_log_at_trx_commit=1zuliefern.

    Beiinnodb_flush_log_at_trx_commit=0wirddasSchreibverhaltenvonInnoDBnochweitergelockert"Commit"istnuneinereinlogischeOperation,diekeineWritesundkeineFlushesperinitiiert.StattdessenwirddasRedoLogeinmalproSekundedurch"WRITE" an das Betriebssystem bertragen und danach durch "FLUSH" einSchreibenderBetriebssystemPufferaufdiePlatteerzwungen.DiesistjedochnichtwesentlichschnelleralsdieEinstellung"2".

  • In jedemFallwird dieDatenbanknacheinemCrashdesMySQLServerprozessesoder der Hardware beim Wiederanlauf recovern mssen. In jedem Fall wird dieDatenbank wieder in einen konsistenten transaktionalen Zustand recovern,unabhngig von den Einstellungen fr 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 demWiederanlaufundderRecoveryerreicht.

    Das Verhalten von InnoDB lt sich auerdem noch mit Hilfe derinnodb_flush_method beeinflussen. InUnix sind die zugelassenenWerte fr dieseVariable "fdatasync" (derDefault), "O_DSYNC", "O_DIRECT", "littlesync", "nosync",in Windows werden "normal" und "unbuffered" (der Default) sowie"async_unbuffered"(derDefaultinWindowsXPundWindows2000)erkannt.

    Die Idee bei O_DSYNC und O_DIRECT ist, die Dateien des RedoLog auf eineWeise zu ffnen, die den Puffermechanismus des Betriebssystems komplettausschaltet dieDatenbankpuffertDaten im innodb_buffer_poolund imRedoLogselbstundesbestehtgarkeineNotwendigkeitfrdenFileSystemBufferCachedesBetriebssystems. Setzt man innodb_flush_method zum Beispiel auf O_DIRECT inLinux,wirdInnoDBnurnochWRITEAufrufedurchfhren,aberdieDatennichtmehrmitFLUSHaufdiePlattezwingen.Dies istauchnichtmehrnotwendig,da ja jederWRITEbeiO_DIRECTungepuffertdirektaufdiePlattegeht.

    RelevanteKonfigurationseintrgeindermy.cnf(frLinux):CODE:#GewnschtesSchreibverhaltenfrvieleAnwendungen

    innodb_flush_log_at_trx_commit=2

    innodb_flush_method=O_DIRECT

    #AlternativfrACIDCompliance:

    innodb_flush_log_at_trx_commit=1

    innodb_flush_method=O_DIRECT

    ConcurrencyTickets

    InnoDB funktioniert besser,wenn dieAnzahl derThreads begrenzt ist, die geradeOperationen innerhalb der Storage Engine ausfhren. Es knnen sich gleichzeitiginnodb_thread_concurrency viele Threads in InnoDB aufhalten. Es existierenverschiedene Formeln, mit denen man auf sinnvolle Werte fr diese Variablekommen kann ("Anzahl der Cores mal zwei", "Summe aus Cores und Platten =AnzahlderDinge,diewirinBewegunghaltenwollen"),aberesistklar,daaktuelleVersionenvonInnoDBschlechterePerformancezeigen,wennderWertzuhochwirdderzeitscheintdasLimitjenachLoad16oder32zusein.

    Hat man mehr gleichzeitige Transaktionen als innodb_thread_concurrency zult,mssenberzhligeThreadswarten.Oftistesjedochso,daeinThreadberdasHandler Interface in die Storage Engine hineingeht, dort eine Operation wie KeyLookupdurchfhrt,umdannindieMySQLSQLSchichtzurckzukehren.UmeineeinzelneQueryzubeantwortensindunterUmstndensehrvielesolchebergngenotwendig.

    DamiteinThreadnunnicht jedesmalwartenmu,wenner indie InnoDBStorageEngine will, bekommt er innodb_concurrency_tickets viele "Tickets", wenn ihmZugangzurEnginegewhrtwird.ErkannalsoentsprechendvieleWechselzwischenSQLSchicht und Storage Engine machen, ohen da er erneut warten mu. MankannhiermitverschiedenenWertenexperimentieren,wennmaneineMaschinemit

  • sehrvielenCPUsundFestplattenhatundeinesehrhoheThreadConcurrency frInnoDBhat.SinnvolleWertesind"AnzahlderRecordsineinemBlock","...ineinemSegment"oder"AnzahlderRecords,dieindieserQuerygelesenwerden".

    Eine weitere Variable ist die innodb_commit_concurrency, die die Anzahl derThreads limitiert, die gleichzeitig comitten knnen. Sie begrenzt denSpeicherverbrauchimLogbufferundreguliertContentionaufdemRedoLog.

    AushistorischenGrndenexistiertnocheineVariablethread_concurrency.DerWert,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 undSolaris garnicht, inVersionenvonpthreadsbiseinschlielichSolaris8hat sie sich internaufdasMappingvonThreadszuKernelthreadsausgewirkt.FraktuelleVersionenvonBetriebssystemenundMySQL istdieVariableundderdorteingestellteWertenichtmehrrelevant.

    RelevanteKonfigurationseintrgeindermy.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_sizeeineVariable,diesehrhufigaufseltsameWertegesetztwird.DieVariablebestimmtdieGreeinesPuffersfrMetadatenstrukturen,istalsoeinCachefrdasinterneInnoDBDataDictionary.DerDefaultWertist1MBund imnormalenBetriebbrauchtdieserPufferniemalsgrerals8MBgesetztzuwerden. Ein Kunde, der Testsmit 40.000 InnoDBTabellen vorgenommen hat, hathiertatschlicheinmaleinenWertvon20MBbentigt.

    RelevanteKonfigurationseintrgeindermy.cnf:

    CODE:innodb_additional_mem_pool_size=4M

    Gesamtbersicht

    Eine Gesamtbersicht ber alle InnoDBStatusvariablen undKonfigurationsparameter findet man auf 12.2.4. InnoDB Startup Options andSystemVariablesimHandbuch.GeschriebenvonKristianKhntoppinMySQLum11:50|Kommentare(4)|Trackbacks(5)

    TrackbacksTrackbackURLfrdiesenEintrag

    InnoDBkonfigurieren

    EigentlichsollteandieserStelleein(leienhafter)BeitragvonmirzurKonfigurationvonInnoDB(ent)stehen.MySQLGottIsotppistmirzuvorgekommen.Besserkannmanesdenkeichnichterklren.Danke!Weblog:Ichbinroot

  • Aufgenommen:Feb03,13:33

    InnoDBKonfigurationSehrnetterArtikelueberdieKonfigurationderInnoDBStorageEnginevonKristianKhntopp.Weblog:PlogofChristianBerendtAufgenommen:Feb05,10:43

    InnoDBKonfigurationeinfacherklrtKristianKhntopphatmalwiedereinenArtikelderSorte"sowillichdaserklrtbekommen"geschrieben.Diesmalber"DieInnoDBStorageEngine:Konfiguration"Lesenlohntsich!Weblog:::handcode.de::Aufgenommen:Feb05,14:52

    InnoDBInternalsChristianKhntopphateinensehrschnenArtikelberdieFunktionsweisevonInnoDBsowiederBedeutungdereinzelnenInnoDBspezifischenOptionenindermy.cnfgeschrieben.VielenDank!...Weblog:I,BlogAufgenommen:Feb06,17:43

    ConfiguringInnoDBAnInnoDBtutorialThisistheenglishtranslationofanotherarticleinmygermanlanguageblog.HowaretransactionsorganizedphysicallyWhenInnoDBcreatesanewtransactionitisnotyetcommitted.ThedatabasehasnotyetmadeanypromisestotheapplicationandWeblog:MySQLdumpAufgenommen:Feb07,08:59

    KommentareAnsichtderKommentare:(Linear|Verschachtelt)

    Wow,vielenDankfrdiesentollenArtikel.Genaudenhtteichvor3Tagengesucht.:)#1Tegam03.02.200813:02

    Siehtjaziemlichsoaus,wiewirdashaben.

    UnsereHauptanwendungisteinAAAbackend.WirhabeneinenMastermitrelativwenigenwrites(wenigeDutzendproMinute),aufjedemAAAserveristeinreadonlyslave.DieDatenbankpasstgutindenSpeicher,demensprechendhabenwirinnodb_buffer_pool_sizenurca.30%greralsdieinnodbFilesgesetzt.Istaberm.E.unkritisch,solangemanmysqldnichtmitmemlocklaufenhat.

    Interessantfindeichnochinnodb_thread_concurrency.Effektivhabenwirjanurdenslavethread,derwritesmacht,wirmchtenabernatrlichmglichstvielegleichzeitigereads.Aktuellhabenwirinnodb_thread_concurrency=0,alsokeinLimit,dassollmutexoverheadsparenundtutbisjetztohneProbleme.Meinungendazu?(Fallsdasberhauptnochjemandliest...)Mysqlist5.0.51a(debianlenny).#2Jakobam07.12.200916:07

    MySQL5.1istintypischenBenchmarksetwaslangsameralseinMySQL5.0dieseBenchmarkserzeugenaberinderRegelnichtgengendConcurrency.Frunsist5.1aufNehalemMaschinenetwa30%schnellerals5.0,undMySQL5.4

  • nocheinmal20%schnellerals5.1(aberleidernichtGA).

    DieseUmstellungbringtwahrscheinlichweitausmehralsSpielereienanden

    TuningParameternvon5.0betreffendConcurrency.

    #2.1Isotopp(Link)am07.12.200920:19

    Lt.MySQL5.1Dokuistinnodb_open_filesunabhngigvonopen_files_limit.Dasliest

    sichindiesemArtikelanders.Wasistnunrichtig?

    Undunabhngigdavon,dassbeidesfunktioniertwasistdiebevorzugte

    SchreibweisevonConfigVariablen:UnderscoreoderDash?

    #3Lapham04.02.201108:36

    KommentarschreibenName

    EMail

    Homepage

    Antwortzu

    Kommentar

    UmschlieendeSternehebeneinWorthervor(*wort*),per_wort_kann

    einWortunterstrichenwerden.

    UmmaschinelleundautomatischebertragungvonSpamkommentaren

    zuverhindern,bittedieZeichenfolgeimdargestelltenBildinder

    Eingabemaskeeintragen.NurwenndieZeichenfolgerichtigeingegeben

    wurde,kannderKommentarangenommenwerden.BittebeachtenSie,

    dassIhrBrowserCookiesuntersttzenmuss,umdiesesVerfahren

    anzuwenden.

    HierdieZeichenfolgederSpamschutzGrafikeintragen:

    BBCodeFormatierungerlaubt Datenmerken?