Який сервер MySQL забезпечує кращу продуктивність Magento


30

Що ви використовуєте як сервер MySQL для Magento?

  • MySQL (Oracle)
  • Перкона
  • інші (MariaDB)

Percona пропонує набір покращень для зберігання InnoDB, який інтенсивно використовується Magento, але ці покращення дійсно мають значення при запуску магазину Magento.

Як ви покращуєте продуктивність (загальні підходи щодо архітектури, не конкретна інформація про встановлення конкретних змінних, таких як innodb_flush_log_at_trx_commit=2і так далі). Я знаю, що тривалість реплікації master-master NBS - це не стабільно.

У мене виникли досить багато проблем із реплікацією головного підлеглого з читаннями, перенаправленими до веденого, оскільки були певні затримки в реплікації даних.

Якнайбільше вийти з MySQL? (пошук розв’язання тощо).


1
FlorinelChis, Дякую за запитання, але це дуже широка тема (покращення продуктивності), і вибір механізму бази даних - це поле для себе. Якщо не існує сильної складової цього питання, пов’язаної конкретно з Magento, це може бути краще задати в нашому питанні DBA Q&A . Але де б ви не ставили своє запитання, вам доведеться надати набагато більше інформації про конкретні проблеми, з якими ви стикаєтесь. Вибачте за плутанину та удачі!
Роберт Картенто

Я розумію, що питання неоднозначне і здається дуже широкою темою. Щодо Magento не настільки широкий, він стосувався дуже конкретних деталей. MySQL - це вузьке місце, коли вам потрібно масштабувати Magento, і, з мого досвіду, просто зміна на percona в деяких налаштуваннях підвищує продуктивність. Я хочу знати, як роблять інші сиджедміни Magento. Я не шукав дуже конкретної інформації, як вам потрібно встановити innodb-flush-log-at-trx-commit = 2, але більше до підходу щодо використання Mysql, percona або інших (MariaDB) для досягнення кращих показників.
FlorinelChis

FlorinelChris, я не доменний експерт, але, грунтуючись на голосуванні та прапорах, я підозрюю, що це питання потребує / гарантує більше інформації для отримання корисної відповіді. Але я радий знову відкрити його, щоб дозволити громаді справлятися з цим належним чином. Ви можете побачити, яку інформацію ви можете додати, щоб люди не залишилися здогадуватися, як найкраще вам допомогти.
Роберт Картенто

Відповіді:


73

Ви потрапляєте в широкий, широкий світ оптимізації тут, і там, звичайно, не існує єдиного розміру, який підходить для всіх підходів.

Визначте продуктивність

Ви маєте на увазі час завантаження сторінки для одного користувача або загальну ємність / загальну сумісність? Два дуже різниться - і не є суто пов'язаними. Цілком можливо мати швидкий магазин з обмеженою місткістю; або повільний магазин з великою ємністю.

Отже, звертаючись до будь-якого типу продуктивності:

  1. Час завантаження сторінки одним користувачем
  2. Загальна потужність / одночасність

Ви повинні самостійно вирішувати власні рішення - тим більше, що у кожного є свої вузькі місця.

Давайте припустимо, що ви працюєте з компетентним хостом, який уже налаштував інші аспекти вашого сервера оптимально для вашого магазину.

Час завантаження сторінки одним користувачем

Чи є MySQL вузьким місцем.
Не безпосередньо. Все стосується затримки, в більшості випадків при тестуванні часу завантаження сторінки - потраплять лише кеші. Тому ключовим тут є мінімізація затримок.

  • Налаштуйте розміри кешу MySQL відповідно (правильної відповіді немає, налаштування налаштовуються зовсім по-різному, щомісяця, у магазині)
  • Зменшити затримку в мережі. Для 64-байтних кадрів; 51,2 мкс для 10 Мбіт / с, 5,12 мкс для 100 Мбіт / с і 4,096 мкс для 1 Гбіт / с. Це дає покращення на 20% лише за рахунок переходу від 100Mbps до 1Gbps. s1
  • Збільшити ємність мережі. Ви були б здивовані тим, що багато мегабайт в секунду обмінюються між веб-сервером та сервером БД, як правило, перевищує 10 МБ / с - тому s1 потрібно як мінімум 100 Мбіт / с . Або просто перемістіть сервер БД локально.
  • Використання SOLR. Зовнішні двигуни іноді краще підходять, SOLR, безумовно, швидше для більш великих каталогів (і, наголошую, більші каталоги ). Навіть не налаштований SOLR виробляє багатошарову навігацію та результати пошуку швидше, ніж може MySQL.

Але ці зміни матимуть такий дробовий вплив на час завантаження сторінки - там, де вузьке місце насправді в іншому місці.

  • Налаштуйте додаток. У Magento є досить великі помилки з тим, як він створює колекції та кешує їх; ми зіткнулися з низкою великих проблем з основним кодом, які можуть калічити продуктивність. У кількох випадках просто видалення відображення кількості продуктів із шаруватого результату навігації виголене за 2 секунди завантаження великої колекції.
  • Перегляньте повільні журнали MySQL. Перевірте повільні запити та додайте індекси за потребою. Різниця між виконанням складного запиту з кількома об'єднаннями з відповідними індексами і без них може становити десятки секунд .

Додаток є вузьким місцем. Не програмне забезпечення. Тому просто поліпшення основного коду або зменшення шаблону менш важким матиме набагато більш значний ефект на продуктивність, ніж будь-які зміни конфігурації MySQL.

Що б ми не турбувались

  • Зміна двигуна зберігання. MariaDB та Percona діляться одним і тим же двигуном InnoDB - Percona XtraDB. До них можна ставитися як до одних і тих же. Що стосується часу виконання одного запиту - продуктивність буде точно відображати ванільну збірку MySQL. Це грає в умовах навантаження / одночасності.
  • Запуск підлеглого MySQL. Це не покращить продуктивність, якщо підлеглий не знаходиться фізично ближче (з мережевої точки зору) або якщо у підлеглого є краще обладнання, ніж у головного. Це грає в умовах навантаження / одночасності.
  • Запуск зовнішнього сервера БД. Це, безумовно, найгірша порада, яку ми неодноразово бачимо багатьма господарями / агенціями. Поки ви не досягли межі на апаратному забезпеченні / ресурсах або у вас є кілька веб-серверів (читайте: висока доступність), MySQL на локальній машині для магазину Magento - хороша ідея. Це вирізає всі накладні витрати та затримку мережі. Навіть мережа 100 Гбіт / с (так, сто гігабіт в секунду) не порівнюватиметься з локальним роз'ємом unix за об’ємом сировини, пропускною здатністю та затримкою.

s1 Тільки для окремих серверів баз даних. Не застосовується до локальних серверів БД.

Загальна потужність / одночасність


Можливо, MySQL є вузьким місцем Але лише після того, як ви прибили свою продуктивність та потужність PHP до того моменту, коли MySQL сповільнює роботу. Якщо ви налаштували Varnish та FPC належним чином (не запускайте нас із того, скільки невдалих спроб ми бачили) - тоді MySQL стає вузьким місцем.

Тож крім перерахованих вище модифікацій.

  • Зміна двигуна MySQL. XtraDB може покращитися під навантаженням і дійсно показує переваги над запасом MySQL.
  • Будьте в курсі MySQL. 5,5 працює краще, ніж 5,0 під навантаженням.
  • Зміна драйвера PHP MySQL. PHP 5.3 і новіші версії мають вбудований драйвер MySQL, але за деяких обставин ми знайшли PHP 5.2 з окремим драйвером, щоб перевершити MySQLND для Magento. Перевірте це на собі
  • Змінити пошукову систему. Переміщення пошуку до SOLR / Sphinx (або навіть до сторонніх зовнішніх служб) дійсно може полегшити тягар не транзакційного навантаження (тобто людей, які не розміщують замовлення)
  • Змініть шаруватий двигун навігації. Знову ж таки, SOLR - це блискучий двигун для багатошарової навігації і завдяки своїй незамикаючій природі набагато швидший, ніж MySQL.
  • Додайте підлеглий MySQL. Це робить допомогу відвідується (нетранзакціонную) навантаження, але не допоможе вам обробляти більше замовлень на годину - як це залежить від Учителя до процесу і повторити ці дані

Що б ми не турбувались

  • Майстер / Майстер. Через досить високу точку насичення апаратним налагодженням Master / Slave (понад 1000 замовлень на годину) - ми ніколи не вважали вимогою використовувати Master / Master у виробництві. Ми провели обширне тестування, але ніколи не виявили це вигідним з точки зору продуктивності та з притаманними йому ризиками та проблемами Майстра / Майстра, просто цього не варто.

Масштабування читання проти запису

Останній абзац дійсно веде до ключової області масштабування читання та запису. Масштабування читання може виконуватися досить нескінченно, не надто сильно ускладнюючи додавання все більшої кількості рабів.

Зважаючи на те, що коефіцієнт "Читання до писемності" Magento становить приблизно 0,1% - розгляд записів не повинен викликати особливих проблем. Ось чому я не переймався згадкою MySQL Cluster та його розумних функцій, таких як автоматичне загострення (розділення таблиць на окремі машини).

Апаратне, апаратне, апаратне забезпечення

Апаратне забезпечення - це найшвидша відповідь, коли йдеться про вдосконалення, тому я навмисно не згадував це вище в обох сценаріях.

Але всі зміни програмного забезпечення у світі не матимуть жодних значень, якщо базового обладнання не вистачає. Це може означати ...

  • Неякісні комутатори з обмеженими буферами
  • Надмірно насичені мережеві посилання
  • Географічно віддалені сервери
  • Погана мережа QoS / CoS
  • Обмежений загальний об'єм оперативної пам'яті
  • Оперативна пам'ять з низькою пропускною здатністю пам'яті
  • Підсистема жорсткого диска з низьким рівнем ВОП
  • Програмний RAID-контролер
  • Процесор низької тактової частоти
  • Чіпсет з низькою пропускною здатністю
  • Віртуалізація обладнання (майже всі типи, крім віртуалізації ядра)

На сьогоднішній день існує дійсно висока стеля щодо того, наскільки високою можна фактично масштабувати обладнання. Дозволяє ігнорувати міф про нескінченне масштабування "у хмарі", оскільки хмарна апаратура має тенденцію бути досить посередньою. Наприклад, флагманські моделі Amazon мають лише 12 ядер при 3,3 ГГц. Але поза цим є кілька дуже потужних серверів - наш верхній сервер має 160 ядер та 2 ТБ (так, терабайт) оперативної пам’яті. Ми ще не бачили, щоб хтось перевищував можливості цього.

Таким чином, у вас є масштабна сфера вертикального масштабування, перш ніж вам навіть потрібно буде розглянути питання про горизонтальне масштабування.

Завжди рухається ціль

Варто зазначити, що в гонитві за виконанням, вузьке місце завжди буде рухатися.

Для акцій магазину Magento.

Увімкніть кеші. PHP - це вузьке місце
Додавання резервного кешу. PHP - це вузьке місце
Додавання кешу на повну сторінку на рівні програми. PHP - це вузьке місце
Додавання кеша на рівні сервера (наприклад, лак). MySQL - це вузьке місце
Додати альтернативну систему пошуку / шарувату навігацію (наприклад, SOLR / Sphinx). PHP - це вузьке місце
Додати більше серверів додатків. MySQL - це вузьке місце
Додайте раб MySQL. Фронтальний кеш - це вузьке місце
Додати більше кеш-серверів. PHP - це вузьке місце
Додати більше серверів додатків. SOLR / Sphinx - це вузьке місце

Etcetera.

Це в значній мірі стає випадком повторного промивання-промивання. Але зрозуміло, що MySQL, безумовно, не є першим портом виклику для оптимізації - і він дійсно вступає в гру лише тоді, коли MySQL споживає більше процесора пропорційно PHP - і це ТІЛЬКИ трапляється коли FPC і Varnish використовуються а сервер (и) - це суто обробка замовлень і нічого іншого (тому що все інше знаходиться в кешах).

Не вносити змін наосліп

Просто додавання рабовласничого MySQL, оскільки ви читаєте, ми говоримо вище, що це допоможе, може коштувати вам продуктивності та надійності на величезному рівні. Перевантажена мережа, сервер з низьким спектром специфічних даних або навіть неправильні налаштування можуть спричинити проблеми з тиражуванням, які можуть зробити ваш магазин повільніше, ніж це було раніше - або викликати проблеми синхронізації між головним і веденим.

Поставити речі в перспективу - приклади реального світу.

Приклад 1 - 300 замовлень на годину

Ми використовували наступне обладнання для обслуговування 300 замовлень на годину ; і лише в цьому підказі - тоді ми відчули необхідність додати виділений сервер MySQL та локальний підлеглий MySQL.

1 серверний
процесор: 2x
оперативної пам'яті Intel E5-4620 : 64 ГБ жорсткого диска: 4x 80 к IOP / с SSD диски
RAID: апаратний RAID 10
Magento версія: Magento EE
ОС: MageStack

Протягом усього часу середнє навантаження залишалось менше 3,00.

Приклад 2 - 180 замовлень на годину

Буквально два дні тому новий наш клієнт легко намочив великий стрибок руху. Обробка 180 замовлень на годину за допомогою одного сервера та Magento Community Edition .

1 серверний
процесор: 2x
оперативної пам'яті Intel E5-4620 : 64 ГБ жорсткого диска: 4x 80 к IOP / с SSD диски
RAID: апаратний RAID 10
Magento Версія: Magento CE
ОС: MageStack
Веб-сайт: Wellgosh.com

Протягом усього часу середнє навантаження залишалось менше 6.00. Навантаження в цьому сценарії було вищою, і це зменшилося до декількох факторів.

  1. Настроювання на стороні магазину не проводилось, як у Прикладі 1
  2. Відсутність FPC на рівні додатків

І з огляду на це, ми все ще отримали детальну статистику, щоб дати відгуки за допомогою графіків. Вони розповідають про відмінну історію розподілу навантаження між ключовими компонентами відокремленої архітектури Magento (балансир завантаження, веб-сервер, db-сервер тощо - за допомогою MageStack ).

Отже, спереду та назад ... дата, яку ви хочете подивитися, - о 12:00 22 лютого.

Пакети брандмауера
Пакети брандмауера

Лакувати трафік
Лакувати трафік

Nginx трафік
Nginx трафік

Завантаження MySQL
MySQL Threads Байти MySQL Запити MySQL

Навантаження процесора
Навантаження процесора

І найголовніше - розподіл навантаження

Цей образ справді все це говорить. І це те, що MySQL, безумовно, не є тягарем - ще не принаймні. Тож наші поради, зосередьтесь на важливості вашої роботи в іншому місці, якщо ви не обробляєте більше декількох тисяч замовлень на годину.

Розподіл навантаження

І в підсумку

Внесення змін до продуктивності - це "не один розмір". Це випадок аналізу ваших поточних вузьких місць та внесення тонких змін / коригувань відповідно до вашого магазину та інфраструктури.

Але продуктивність осторонь, є й інші переваги використання Percona

Ми використовуємо Percona XtraDB майже виключно. Ми запускаємо спеціально складені збірки MySQL, розроблені спеціально для Magento, і під час цього процесу консультувалися з Percona. Але це не просто ефективність вплинула на цей вибір.

  • Інструментарій Percona
    • pt-дайджест запитів
    • xtrabackup
    • тощо.
  • Частота вивільнення Percona
  • Консультативна підтримка Percona
  • Теплий кеш перезапускається із збереженням пулу InnoDB

І багато іншого. Тому використання його через MySQL мало інші переваги, ніж просто продуктивність. Насправді - MySQL є і завжди був найменшим занепокоєнням у справі працездатності та стабільності.

Атрибути: wellgosh.com , sonassi.com , iebmedia.com .


це довга відповідь :) Дуже вдячний, Дякую Щодо масштабу та навантаження на MySQL, тут представлена ​​діаграма munin від MySQL: twitter.com/ze_m0n5t3r/status/232864932482396160 . Оптимізація Magento - це постійний процес (різні помилки, неоптимізований код тощо). Зниження навантаження (переміщення пошуку / навігації до вибору, покращення кешування) - перший підхід. Але також, БД має поводитись краще з холодним кешем. І коли це трапляється, я шукаю повільніший веб-сайт, який має більший потенціал.
FlorinelChis

Будь ласка. Немає підстав говорити, що ви не можете мати швидкий веб-сайт і великий потенціал - як це роблять наші клієнти . Очевидно, що в продуктивності MySQL є трохи більше, ніж я вирішив згадати вище. Але це дещо віддасть наш "секретний соус". Я відповів на цю відповідь власникам невеликих магазинів (<25k унікальних в день) як "початкові" вказівки щодо MySQL.
Бен Лессані - Сонассі

Так само, як і стороною. Переглядаючи ваш графік, ваші вкладиші досягли приблизно 10-кратного звичайного навантаження, оновлення залишилися низькими, а вибір - показав найбільше навантаження. Я б взяв на себе азарт, щоб вставки були журналом клієнтів, релевантністю пошуку / запитами або, не дай Бог, сесіями. Але все ж достатньо невелика кількість, щоб не ставити питання або навіть розглядати майстра / майстра. Отже, виходячи з вашого графіка, просте додавання більшої кількості апаратних засобів було б більш ніж адекватним; з рабом (ими), що слідує за цим. І зберегти кеш-пам’ять між перезавантаженнями легко за допомогою Percona, s.onas.si/5g8s
Ben Lessani - Sonassi

пошук був solr, сеанси - memcache. Чи знаєте ви когось із успішним майстром-майстром? (NBS зазнала невдачі в цьому, ми не змогли і з цим, це нестабільно з Magento, добре працює в інших більш легких додатках php)
FlorinelChis

1
Це неймовірна відповідь. Просто хотів це сказати.
пиломатеріал
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.