В нашем блоге мы много пишем о построении облачного сервиса 1cloud, но немало интересного можно почерпнуть и из опыта по работе с инфраструктурой других компаний.
Мы уже рассказывали о дата-центре фотосервиса imgix, а сегодня затронем тему повышения производительности MySQL и взглянем на советы инженеров соцсети Pinterest.
/ фото Jason Cartwright CC
Работа новичков в компании Pinterest основана на их собственном выборе команды инженеров, в которой они хотели бы присоединиться. Новые сотрудники решают большое количество задач, одна из которых заключается с оптимизацией производительности MySQL, развернутой на Amazon Web Services (AWS).
Даже при довольно низкой рабочей нагрузке в 2000 QPS (запросов в секунду), инженерам компании не удавалось дойти до сколько-нибудь адекватных уровней производительности ввода/вывода – превышение порога в 800 IOPS (операций ввода/вывода в секунду) приводило к неприемлемому увеличению латентности.
Данная проблема могла быть решена двумя способами: переходом на более производительный инстанс, что удваивает затраты и уменьшает эффективность; либо повышением производительности существующей системы.
Суть решения, которое в итоге применила Pinterest заключается в отмеченном влиянии версии ядра Linux: ни стандартная 3.2, ни рекомендуемая 3.8 не давали достаточной эффективности; но сам факт влияния настроек на уровне операционной системы подтолкнул инженеров к поиску различных вариантов оптимизации. В рамках этой работы было проверено более 60 различных тестовых конфигураций SysBench с выводом в файл.
Чтобы оценить влияние изменений на скорость обработки транзакций в тесте SysBench вычисляли 99-й процентиль времени отклика при различных конфигурациях системы и разных количествах потоков: 16 и 32. В итоге производительность чтения/записи была увеличена примерно на 500% для обоих потоков.
Скорость обработки запросов чтения выросла с 4100-4600 QPS до более чем 22000-25000 QPS, в зависимости от степени параллелизма. Скорость обработки запросов записи выросла с 1000 QPS до 5100-6000 QPS.
Со стороны клиента 99-й процентиль латентности уменьшился с 15-35 мс (с отдельными выбросами до 100 мс) до стабильных 15 мс (с выбросами до 80 мс и меньше). Со стороны сервера время ожидания уменьшилось с 5-15 мс до стабильных 5 мс, с ежедневным 18-ти миллисекундным пиком на время обслуживания системы. Число отмеченных инцидентов, связанных с производительностью системы или перегрузкой сервера, упало с 300 до суммарных 10-и (в рамках пары месяцев).
P.S. Мы стараемся делиться не только собственным опытом работы над сервисом по предоставлению виртуальной инфраструктуры 1cloud, но и рассказывать о смежных областях знаний в нашем блоге на Хабре. Не забывайте подписываться на обновления, друзья!
Мы уже рассказывали о дата-центре фотосервиса imgix, а сегодня затронем тему повышения производительности MySQL и взглянем на советы инженеров соцсети Pinterest.
/ фото Jason Cartwright CC
Работа новичков в компании Pinterest основана на их собственном выборе команды инженеров, в которой они хотели бы присоединиться. Новые сотрудники решают большое количество задач, одна из которых заключается с оптимизацией производительности MySQL, развернутой на Amazon Web Services (AWS).
Даже при довольно низкой рабочей нагрузке в 2000 QPS (запросов в секунду), инженерам компании не удавалось дойти до сколько-нибудь адекватных уровней производительности ввода/вывода – превышение порога в 800 IOPS (операций ввода/вывода в секунду) приводило к неприемлемому увеличению латентности.
Данная проблема могла быть решена двумя способами: переходом на более производительный инстанс, что удваивает затраты и уменьшает эффективность; либо повышением производительности существующей системы.
Суть решения, которое в итоге применила Pinterest заключается в отмеченном влиянии версии ядра Linux: ни стандартная 3.2, ни рекомендуемая 3.8 не давали достаточной эффективности; но сам факт влияния настроек на уровне операционной системы подтолкнул инженеров к поиску различных вариантов оптимизации. В рамках этой работы было проверено более 60 различных тестовых конфигураций SysBench с выводом в файл.
Чтобы оценить влияние изменений на скорость обработки транзакций в тесте SysBench вычисляли 99-й процентиль времени отклика при различных конфигурациях системы и разных количествах потоков: 16 и 32. В итоге производительность чтения/записи была увеличена примерно на 500% для обоих потоков.
Скорость обработки запросов чтения выросла с 4100-4600 QPS до более чем 22000-25000 QPS, в зависимости от степени параллелизма. Скорость обработки запросов записи выросла с 1000 QPS до 5100-6000 QPS.
Со стороны клиента 99-й процентиль латентности уменьшился с 15-35 мс (с отдельными выбросами до 100 мс) до стабильных 15 мс (с выбросами до 80 мс и меньше). Со стороны сервера время ожидания уменьшилось с 5-15 мс до стабильных 5 мс, с ежедневным 18-ти миллисекундным пиком на время обслуживания системы. Число отмеченных инцидентов, связанных с производительностью системы или перегрузкой сервера, упало с 300 до суммарных 10-и (в рамках пары месяцев).
P.S. Мы стараемся делиться не только собственным опытом работы над сервисом по предоставлению виртуальной инфраструктуры 1cloud, но и рассказывать о смежных областях знаний в нашем блоге на Хабре. Не забывайте подписываться на обновления, друзья!