Cum să accelereze mysql și alină sarcinii pe subsistemul disc

Motive pentru creșterea timpului de încărcare a paginilor pot fi foarte diferite. În acest articol, vom examina una dintre situațiile cele mai tipice, și anume interogări la o bază de date MySQL sunt efectuate pentru o lungă perioadă de timp, și există o sarcină mare pe subsistemul disc.

În primul rând, ar trebui să clarifice natura sarcinii pe roți. Acest lucru va ajuta la utilitate iostat. În Ubuntu este instalat cu pachetul SYSSTAT:

Cum sa viteza de citire

Să presupunem că discul este încărcat cererile de citire. Ce se poate face pentru a accelera datele afară? Pentru cache de date în memorie. MySQL oferă posibilitatea de a utiliza motoare de stocare diferite, sau (motoare de stocare), pentru a accesa datele, astfel încât o abordare diferită de cache. Cele două cele mai populare motor: MyISAM și InnoDB.

motor InnoDB are o memorie cache încorporat pentru datele și indicele - așa-numitul tampon Pool. Dimensiunea acesteia este reglementată de innodb_buffer_pool_size variabilă. In mod ideal, mărimea tampon Pool ar trebui să fie cel puțin unui astfel de volum, astfel încât să poată acomoda complet toate datele și indexurile, plus 30% -60% din dimensiunea lor. Memoria suplimentară este utilizată în scopuri oficiale și introduceți tampon, precum și pentru a asigura rezerva de depozitare pentru viitor. Parțial innodb_buffer_pool_size - nu dinamic, astfel încât atunci când se schimbă în fișierul de configurare trebuie să reporniți MySQL.

puteți obține performanțe maxime de citire atunci când volumul pagecache egal cu baza de date de volum MyISAM.

Cum să accelereze intrarea

Creșterea performanței MySQL pentru un volum mare de înregistrări, puteți utiliza reglează fin setările de server.

Implicit InnoDB resetează datele modificate pe disc folosind Fsync de apel de sistem (). În acest caz, sistemul de operare nu garantează că datele vor cădea în acest al doilea magazin, deoarece datele trec mai întâi printr-un tampon care este susținută de nucleu. Tamponare este necesară pentru a accelera I / O.

Cu toate acestea, în cazul în care MySQL datadir este situat pe hardware-ul RAID-matrice, este posibil să se utilizeze pentru o astfel de tamponare NVRAM-cache RAID-controler, care este mult mai eficient. Cu toate acestea, asigurați-vă că regulatorul este echipat cu un UBB (baterie de rezervă unitate) - o sursă de alimentare separată pentru cache. Atunci când o pană de curent brusc controlerul ar trebui să fie un timp pentru a reseta conținutul memoriei cache pe disc, sau datele din matrice va rămâne într-o stare de incoerență.

Când valorificând cache RAID-controler pentru a crește performanța de scriere în baza de date, dezactivați tamponare inutile la nivelul sistemului de operare. Acest lucru necesită pentru a seta variabila in MySQL valoarea innodb_flush_method O_DIRECT, apoi reporniți managementul bazei de date. Reducerea sarcinii pe roțile se pot schimba, de asemenea, innodb_flush_log_at_trx_commit variabila. Pentru a respecta registrele de tranzacții ACID magazine de motoare InnoDB sau a reface-jurnalele care înregistrează toate cererile de schimbare a datelor. Aceste jurnale sunt utilizate în procesul de recuperare după o situație de urgență a opri sistemul de gestionare a bazei de date.

Valoarea implicită este (1) presupune că tampon redo-logs, situat în memoria InnoDB este scris pe disc după fiecare tranzacție comite. Acesta este cel mai sigur mod de operare, asigurând siguranța fiecărei tranzacții, chiar și în cazul în care „cădere“ a serverului. Puteți seta innodb_flush_log_at_trx_commit în valoare de 2, atunci jurnalele vor fi scrise după fiecare comitere, dar Fsync () - resetează datele de pe disc - o singură dată pe secundă se va realiza (începând cu versiunea MySQL 5.6.6, acest interval este determinat de innodb_flush_log_at_timeout variabilă). Bază de date de oprire de urgență nu va duce la pierderea a tranzacției, dar serverul în sine off poate duce la pierderea în ultima secundă a tranzacțiilor. O valoare de 0 înseamnă modul de înregistrare chiar mai rapid - date și sunt înregistrate și sincronizate ori pe secundă, indiferent de comiterea tranzacției. Cu toate acestea innodb_flush_log_at_trx_commit = 0 poate duce la pierderea de tranzacții, chiar și în procesul de cădere. administratorul bazei de date trebuie să facă o alegere în funcție de cerințele de volumul de muncă și de afaceri curente.

Optimizarea operație de scriere pe disc pentru a ajuta la dimensionarea refaceti-busteni corecte. Pentru a face acest lucru, există o regulă simplă. Este suficient pentru a măsura cantitatea de date care este înregistrată în jurnalul într-un minut. Această operațiune trebuie efectuată în momentul sarcinii de vârf de zi cu zi:

Exemplul arată că un minut într-un jurnal este înregistrat InnoDB 2.44 Mb. Volumul jurnalului ar trebui să fie selectate astfel încât s-ar putea stoarce cantitatea de date pe oră. În acest caz, InnoDB va avea timp suficient pentru a schimba ordinea cererilor de I / O pentru a realiza o înregistrare consecventă. În acest exemplu, o oră după refaceti-busteni trece 150 MB de date, astfel încât innodb_log_file_size variabilă ar trebui să fie setat la o valoare nu mai puțin de 75m. În cazul în care volumul de jurnal este prea mare, aceasta va crește timpul de InnoDB Crash Recovery, care va crește dauntaym la repornire de urgență (este de remarcat faptul că, în MySQL 5.5 timp Crash Recovery depinde de dimensiunea InnoDB-log într-o măsură mai mică).

Desigur, toate aceste sfaturi nu sunt exhaustive. Cheia pentru baza de date este înțelegerea rapidă a datelor, un aspect bine conceput și interogări compilate cu succes. Cu toate acestea, o serie de optimizări eficiente poate fi realizată la nivel de server.