key_buffer_size, innodb_buffer_pool_size - dar coment.
innodb_log_file_size - aceasta depinde de cantitatea de date necesare pentru a recupera, dar 256MB va fi un compromis rezonabil între performanță Ramer și fișier jurnal.
innodb_log_buffer_size - valoarea implicită este potrivită pentru majoritatea proiectelor cu o intensitate medie de scriere și tranzacții scurte. Cu toate acestea, dacă aveți vârfuri de activitate sau lucrați cu o cantitate mare de date, probabil că doriți să măriți valoarea acestui parametru. Nu o face prea mare, va cauza consum de memorie inutil. Tamponul este resetat în fiecare secundă și nu mai aveți nevoie de memorie. De obicei este suficient 8 - 16 MB. Cu cât sistemul este mai mic, cu atât este mai mică valoarea.
innodb_flush_log_at_trx_commit - Credeți că InnoDB este de o sută de ori mai lent decât MyISAM? Probabil ați uitat să modificați valoarea acestui parametru. Valoarea implicită de 1 înseamnă că, după fiecare tranzacție finalizată (sau după modificarea stării tranzacției), jurnalul trebuie să fie aruncat. Aceasta este o operație destul de scumpă, mai ales dacă nu aveți o memorie cache stocată în baterie. Multe aplicații, în special cele în care MyISAM a fost folosit înainte, vor funcționa bine la o valoare de 2, ceea ce înseamnă că nu este necesar să resetați tamponul pe disc și ar trebui să îl trimiteți în cache-ul sistemului de operare. Jurnalul va fi în continuare dezumflat pe disc în fiecare secundă și maxim pe care îl puteți pierde - este vorba de 1-2 secunde de înregistrări. Valoarea 0 oferă o viteză mai mare, dar și o fiabilitate mai mică.
innodb_log_file_size - depinde de cantitatea de date de care aveți nevoie pentru a restabili, dar 256MB va fi un compromis rezonabil între performanță și dimensiunea fișierului jurnal
innodb_log_buffer_size = 4M - 4 megabiți - valoarea normală, dacă nu utilizați blocuri mari de date în flux InnoDB prin canale (conducte). Dacă utilizați, această valoare este mai bine să crească.
innodb_thread_concurrency = 8 - chiar și cu scalabilitatea InnoDB disponibilă, nu este absolut necesar să aveți un număr limitat de fire. Valoarea poate fi mai mare sau mai mică în funcție de necesitățile dvs., dar 8 va fi valoarea optimă pentru start.
innodb_flush_method = O_DIRECT - Evitați tamponarea dublă și reduceți activitatea de swap, în majoritatea cazurilor acest lucru crește performanța. Dar aveți grijă, dacă nu aveți un RAID cu capacitatea de a salva date, operațiile de I / O pot eșua și datele pot fi corupte.
innodb_file_per_table - dacă aveți câteva mese, utilizați această opțiune, iar creșterea spațiului ocupat de mese nu va fi incontrolabilă. Această opțiune este adăugată la MySQL 4.1 și este acum destul de stabilă pentru utilizare.
Verificați și dacă aplicațiile pot fi pornite în modul de izolare READ-COMMITED. Dacă este cazul, setați opțiunea transaction-isolation = READ-COMITTED. Această opțiune va crește performanța.
Dezactivați tamponarea dublă: pe Linux, FreeBSD, Solaris, trebuie să setați parametrul innodb_flush_method = O_DIRECT.
read_buffer_size = 64K - 128K
Created_tmp_disk_tables - phpMtAdmin scrie: "Pentru o valoare mare a unei variabile, se recomandă mărirea dimensiunii cache-ului de tabelă (table_cache)." Există două puncte aici
1) tmp_table_size și max_heap_table_size trebuie să fie egale, deoarece ambele mecanisme participă la crearea de tabele temporare.
2) Nu face tmp_table_size și max_heap_table_size prea mare, deoarece crește excesiv, pe de o parte, poate încetini, iar pe de altă parte, nu dă efect, deoarece, în conformitate cu documentația, tabele temporare nu pot fi create în memorie atunci când cererea conține TEXT sau BLOB.
Cel mai probabil, în acest caz, ar trebui să încercați să creați un sistem de fișiere în memoria mfs și să îl reassignați la my.cnf cu tmpdir.
Această opțiune nu poate fi ratată în nici un fel, dacă aveți o încărcătură serioasă în înregistrarea competitivă. Este foarte dificil să explic acest lucru, și nu înțeleg acest lucru la adâncimi, dar dacă în scurt ...
Dacă aveți nevoie de o izolare completă a transcrierilor, atunci această opțiune nu este pentru dvs. Apoi, va trebui să neglijați performanța în favoarea integrității tranzacțiilor.
De exemplu, dacă utilizați citirea în intervalul (SELECT FROM b unde c> 100), în banca medie, apoi cu opțiunea innodb_locks_unsafe_for_binlog, urmând aceeași interogare va returna același rezultat, chiar dacă între cineva care este în acest tabel încearcă să scrie.
Când off (implicit) opțiunea innodb_locks_unsafe_for_binlog, a doua oară cererea menționată poate returna un rezultat diferit de prima dată într-o singură tranzacție în care încearcă să scrie în acest tabel nu a fost pus obstacole procese.
Asta este, această opțiune în stare pornit îndepărtează tuyevu huchu lokov la lectură competitivă în tabele. Prețul emisiunii nu este de a furniza o imagine consistentă a datelor pe întreaga durată a tranzacției. Ca ceva în general.
În cazul meu, câștigul de performanță cu includerea acestei opțiuni a fost enorm. Cu toate acestea, acest lucru are sens pe înregistrările mixte într-adevăr masive - citește - citește.
Da, da. Și pentru replicare, nu este un canal, respectiv.
Articole similare
Trimiteți-le prietenilor: