Електронна търговия и повече Оптимизиране на MySQL за Magento
AddThis интелигентни слоеве
Оптимизиране на MySQL за Magento. Ревизия 2
Времето тече с луда скорост. Изглежда, че съвсем наскоро писах за оптимизиране на настройките на MySQL за Magento сървъри, но се оказва, че оттогава е изминала година и половина.
Какво се промени оттогава и защо има смисъл да се преразгледат настройките? Всъщност фактът, че Magento е достигнал версия 1.8.1.0 към момента на писане на това, няма абсолютно никакъв ефект върху промените в настройките на MySQL.
Да, системата стана още по-стабилна, дори по-бърза, има по-малко неоптимизирани заявки. Но в същото време той все още е същият добър стар Magento от първото поколение. И докато Magento 2.0 бъде пуснат, ние ще продължим да оптимизираме и сървъра на базата данни.
Освен това, ако беше самият Magento. За съжаление, не всички разработчици на разширения на трети страни могат да оптимизират своите заявки, да използват индекси, тригери и временни таблици.
В резултат на това дори доста мощен сървър може да се провали дори с дузина едновременни потребители, ако настройките на MySQL не са оптимизирани.
Една от промените беше изданието на MySQL 5.6.x, в което освен различни оптимизации в самото ядро, имаше промени в различни директиви за конфигурация.
И втората важна причина беше значителен пробив в технологиите за виртуализация на сървъри и в резултат на това намаляване на тяхната цена.
Днес няма абсолютно никакъв смисъл да се пести от сървърни ресурси, когато цената на виртуален сървър с 2-4 гигабайта памет и 2-4 процесора започва от $20 на месец.
Така можем напълно да използваме паметта на сървъра за съхраняване и бърз достъп до SQL заявки. Наличието на няколкопроцесорите ще позволят по-бърза обработка на онези заявки, които не са кеширани.
И така, по-долу ще говорим за оптимизиране на сървъра MySQL 5.6
Използвана конфигурация на виртуален сървър (VPS): Брой процесори: 2 Количество RAM памет: 4Gb
А сега нека се опитаме да разберем какво е какво и защо.
max_connectionsБроят на максималните връзки по подразбиране е 151. Това много ли е или малко? Това силно зависи от трафика на сървъра, скоростта на обработка на заявките и оптимизацията на уебсайта. Ако сайтът е добре оптимизиран, използват се различни технологии за кеширане на страници, тогава броят на заявките за база данни е значително намален. В същото време оптимизирането на заявките към базата данни играе важна роля. В идеалния случай не трябва да има заявки, които отнемат повече от 0,5 секунди за изпълнение. Ако сървърът е достатъчно мощен, повечето заявки се кешират, RAM паметта се използва за съхранение на данни, броят на едновременните връзки ще бъде умерен.
За пример ще взема сайта на един от нашите клиенти. Средната дневна посещаемост на сайта е около 5000 посетители. В същото време броят на едновременните връзки към базата данни не надвишава 50.
Трябва ли max_connections да се остави по подразбиране? Да, но само ако има излишна RAM. Тъй като някои от настройките, използвани в нашата конфигурация, не са глобални и ще бъдат умножени по максималния определен брой връзки при стартиране на сървъра и ще бъдат запазени. С други думи, без значение колко трафик ще има сайтът и какви други процеси ще изискват допълнителни ресурси, лъвският дял от паметта винаги ще бъде зает от сървъра на базата данни.
Следователно все още има смисъл да се намали стойността на max_connections до реалната.
отв сравнение с предишната ревизия, в настоящата версия на настройките липсват много различни опции. В същото време бяха добавени нови.
Например, вече няма да променяме параметъраkey_buffer, който също сега еkey_buffer_sizeв MySQL 5.6. Тъй като този параметър е от значение само за таблиците MyISAM, които котката извика в Magento. Освен това стойността по подразбиране за този атрибут е 8Mb, което е повече от достатъчно. Ще направим същото с параметъраmyisam_sort_buffer_size.
thread_cache_sizeСпочвайки от MySQL 5.6.8, този параметър приема стойност -1 (автоматично).
thread_concurrencyСъщо така вече не е от значение.
table_cacheПреименувано наtable_open_cache. Стойността на този параметър силно зависи от броя на базите данни и таблиците в тях.
table_definition_cacheВече не е необходимо да се указва, тъй като от MySQL 5.6.8 приема стойност -1 (автоматично).
open_files_limitСега се конфигурира автоматично.innodb_additional_mem_pool_sizeОтхвърлен от MySQL 5.6.3.
innodb_thread_concurrencyВсичко също се изчислява по формулата 2 * (брой CPU) + (брой дискове). Тъй като увеличихме броя на процесорите в сравнение с предишната ревизия, използваме стойността 5.
max_connect_errorsСпочвайки от MySQL 5.6.6, стойността по подразбиране за този параметър е 100. Повече от достатъчно.
tmp_table_sizeТъй като сега имаме значително повече налична памет, можем да си позволим да запазим много повече временни таблици в паметта. Стойността на този параметър силно зависи от броя на базите данни и таблиците в тях.
max_heap_table_sizeВсичко също трябва да има стойност, подобна наtmp_table_size.
innodb_log_file_sizeИзчислява се с помощта на формулата 1/N от размера наinnodb_buffer_pool_size, където N е стойността на параметъраinnodb_log_files_in_group, който от своя страна има 2 по подразбиране. По този начин, ако разпределим заinnodb_ buffer_pool_size1024Mb памет, тогава за параметъраinnodb_log_file_sizeможете да разпределите една четвърт от тази стойност, т.е. 256Mb.
innodb_log_buffer_sizeПозволява ви да извършвате големи транзакции, включително операции с голям брой редове, без да е необходимо да записвате регистрационния файл във файл и да използвате файловата система на сървъра. Определено има смисъл да използвате бърза RAM вместо относително бавна файлова система.
innodb_sort_buffer_sizeТази опция е въведена едва след MySQL 5.6.4. Стойността му по подразбиране е 1Mb, нека се опитаме да го зададем на 2Mb.
Както можете да видите, колкото повече RAM е налична, толкова по-голям е обхватът за оптимизиране на сървъра на базата данни.
Така че евреите, не пестете чаени листа, трябва да пестите от евтина памет. Колкото повече памет, толкова по-малко ще се използва бавната файлова система на сървъра и съответно сайтът ще работи в пъти по-бързо.
Разбира се, всички стойности на количеството памет за определени параметри зависят от размера на базата данни или базите данни на сървъра, интензивността на използване на данни, броя на таблиците в базата данни и други променливи.
Няма и не може да има универсални настройки, които могат да бъдат намерени в изобилие в Google.
За удобство при тестване на настройките е много удобно да използвате следните инструменти: MySQLTuner MySQL Performance Tuning Primer MySQL Report
ОсновенИзточникът на информация за всички настройки е официалният уебсайт. Системни променливи на сървъра Опции за стартиране на InnoDB и системни променливи