Как да се ускори MySQL и да се облекчи натоварването на дисковата подсистема,
Причини за увеличаване на времето за зареждане на страниците могат да бъдат много различни. В тази статия, ще разгледаме един от най-типичните ситуации, а именно заявки към база от данни се извършват в продължение на дълго време, и има голяма натоварване на дисковата подсистема.
Първо, трябва да се изясни естеството на натоварването на колелата. Това ще ви помогне iostat полезност. В Ubuntu е инсталиран с SYSSTAT пакет:
Как да се ускори прочетете
Да кажем, че дискът е поставен заявки за четене. Какво може да се направи, за да се ускори данните навън? За да кешира данни в паметта. MySQL дава възможност да се използват различни двигатели за съхранение, или (двигатели за съхранение), за достъп до данните, така че по-различен подход към кеширане. Двете най-популярния двигател: MyISAM и InnoDB.
InnoDB двигател разполага с вграден в кеш за данни и индекс - т.нар буферен пул. Нейният размер се определя от променливата innodb_buffer_pool_size. В идеалния случай, размера на буферния пул трябва да бъде поне на такъв обем, така че да може напълно да се настанят всички данни и показатели, както и 30% -60% от техния размер. Допълнителна памет се използва за служебни цели и въвеждане на буфера, както и да се осигури резерв за бъдещето съхранение. Частично innodb_buffer_pool_size - не динамично, така че когато той се превръща в конфигурационния файл, който е необходим, за да рестартирате MySQL.
можете да постигнете максимална ефективност за четене, когато обемът pagecache равна на базата данни за обема на MyISAM.
Как да се ускори влизането
Увеличете производителността на MySQL за голям обем от документи можете да използвате фини настройки на настройките на сървъра.
По подразбиране InnoDB нулира променените данни на диск с помощта на системата fsync повикване (). В този случай, операционната система не гарантира, че данните ще попадат в тази втора магазин, защото данни първо преминават през буфер, който се поддържа от ядрото. Буфериране е необходимо да се ускори I / О.
Въпреки това, ако MySQL на DataDir се намира на хардуер RAID-масив, е възможно да се използва за такъв буферен NVRAM-кеша RAID контролер, който е много по-ефективен. Въпреки това, уверете се, че контролерът е оборудван с BBU (Battery Backup Unit) - за кеша отделно захранване. Когато внезапно спиране на тока на контролера трябва да е време, за да възстановите съдържанието на кеша на диска, или данните в масива ще остане в състояние на несъответствие.
Когато овладяване на кеша RAID-контролер, за да се повиши ефективността на запис в базата данни, можете да деактивирате ненужни буфериране на ниво операционна система. Това изисква да настроите променливата в innodb_flush_method стойност O_DIRECT на MySQL, след което рестартирайте управление на база данни. Намаляване на натоварването на колелата и да промениш променлива innodb_flush_log_at_trx_commit. За да се съобразят с магазини на двигателя КИСЕЛИНА регистъра на операциите на InnoDB или ремонтирам-дневници, които записват всички искания за информация на климата. Тези записи се използват в процеса на възстановяване след аварийно спиране на системата за управление на бази данни.
Стойността по подразбиране е (1) приема, че буферните ремонтирам-трупи, разположен в InnoDB памет се записва на диск след всяко извършване на операциите. Това е най-сигурният начин на работа, осигуряване на безопасността на всяка сделка, дори и ако "падне" на сървъра. Можете да настроите innodb_flush_log_at_trx_commit в стойността на 2, а след това трупи ще бъдат записани след всяка ангажират, но fsync () - връща данните на диска - само веднъж в секунда ще се извършва (от версия MySQL 5.6.6, този интервал се определя от променливата innodb_flush_log_at_timeout). Аварийно изключване база данни няма да доведе до загуба на сделката, но сървърът се на разстояние може да причини загуба на последната секунда на сделките. Стойност 0 означава още по-бързо в режим на запис - данни и се записват и синхронизирано пъти в секунда, независимо от сделката ангажира. Въпреки innodb_flush_log_at_trx_commit = 0 може да причини загуба на сделки, дори в процеса на падане. администраторът на базата данни трябва да направи избор, въз основа на текущите натовареност и бизнес изисквания.
Оптимизиране на работа на записа на диска, за да помогне на правилните оразмеряване ремонтирам огрев. За да направите това, има едно просто правило. Достатъчно е да се измери количеството данни, което се записва в дневника на една минута. Тази операция трябва да се извърши по време на ежедневната пиково натоварване:
Примерът показва, че за една минута в дневник се записва InnoDB 2.44 Mb. Обем на дневника трябва да се избере така, че тя може да изтръгне от количеството данни на час. В този случай, InnoDB ще има достатъчно време, за да промените реда на заявките за I / O, за да се постигне постоянен запис. В този пример, един час след ремонтирам огрев минава 150 MB данни, така innodb_log_file_size променлива трябва да бъде настроен на стойност не по-малко от 75 м. Ако обемът на дневник е твърде голям, това ще увеличи времето, InnoDB Crash Recovery, което ще увеличи dauntaym при аварийно рестартиране (заслужава да се отбележи, че в MySQL 5.5 време Crash Recovery, зависи от размера на InnoDB-влезете в по-малка степен).
Разбира се, всички тези съвети не са изчерпателни. Ключът към базата данни е бързо разбиране на вашите данни, добре обмислено оформление и успешно събрани запитвания. Въпреки това, редица ефективни оптимизации може да се извършва на ниво сървър.
