Как масштабировать систему для снижения нагрузки?

Question

[gigigi]

Всем привет!

У нас есть сервер, на нем крутится nginx + php-fpm + mysql.
Столкнулись с проблемой: вырос трафик, выросли нагрузки.
MySQL забивается от большого количества запросов, в следствии чего в медленные запросы начали попадать даже выборки по PRIMARY KEY.

Хотелось бы понять как возможно масштабировать систему, чтобы распределить нагрузку? Какие есть способы это сделать?
Заранее спасибо.

Answer 1

[script88]

Ну как минимум можно развернуть еще 1 сервер приложений и 1 сервер mysql, в nginx upstreem подключаете app сервера (php-fpm), mysql настраиваете master-master тем самым нагрузка будет распределена между сервера.
На больших нагрузках советую использовать percona server вместо msyql,
П.С. по мимо серверной инфраструктуры надо заниматься оптимизацией и самого приложения.

Comments

[signalizator]

Самое простое и быстрое — включайте кеширование результатов выборок из БД, кеширование даже на короткое время временно спасет.

[signalizator]

Промахнулся :)

[gigigi]

Спасибо, сейчас как раз пытаемся поднять ещё один nginx с php-fpm на слейве и настроить upstream на два сервера.
Многие говорят про Percona, интересно, а миграция сложная? У нас просто достаточно крупный проект, который должен работать 24 часа в сутки и постоянно работает на запись и чтение.
Приложение оптимизировано достаточно хорошо, мы конечно же приложили все усилия для его оптимизации. Просто очень большие объёмы трафика и БД.

[gigigi]

Кэширование запросов конечно есть, дело в том, что у нас очень много пишется и много читается всего разного. Как правило кэширование если нас и спасает, то наверняка не очень сильно.

[script88]

при upstream, не забывайте ip_hash, либо сессии пользователей держите в базе, либо в memcache.
По поводу Percona Server она обратно совместимая с mysql, по этому переход на нее должен быть болезненным.

[gigigi]

Нам сессии в общем-то и не нужны. У нас хэш пользователя генерится + куки.
Спасибо, будем смотреть в сторону Percona Server.

[script88]

Если есть возможность, то разбейте при master-master либо master-slave репликации можно распаралелить запросы на разные бд, допустим все запросы вида select травить на вторую бд, все остальные на первую. Вариантов на самом деле много, есть куда смотреть.

[script88]

разбейте запросы*

[gigigi]

У нас сейчас master-slave, пишем всё в мастер, читаем что-то со слейва, но некоторые вещи нужно читать с мастера. И к сожалению они тоже достаточно тяжёлые. У нас ещё параллельно mongoDB пишет и читает, саппорт вот посоветовал под монго отдельный сервер взять или на отдельный раздел перенести, чтобы они файловыми операциями друг другу не мешали.

[script88]

mongo и mysql на одном сервере?? ))
Ну Вы ребята молодцы, убирайте его и чем быстрее тем лучше, mongo — это жадное создание, которое жрет все что доступно.
> файловыми операциями друг другу не мешали.
На это на вряд ли стоит надеяться, ибо IOPS не увеличится в этом случае.

[gigigi]

Именно этим и занимаемся сейчас :)

Answer 2

[sledopit]

Без картины реального распраделения нагрузки (мониторинга) это будет небольшим гаданием на кофейной гуще.

Скорее всего и nginx и mysql активно кушают диск и мешают друг другу.
Имхо, первым шагом было бы логично вынести mysql на отдельный физический диск или, если этого окажется недостаточно, даже отдельный физический сервер.

Comments

[gigigi]

Ну при снижении нагрузок мы точно увидим стало ли лучше)
Да, спасибо, про вынос MySQL на отдельный сервер думаем.

[Алексей Сундуков]

Диск кстати очень легко отследить. В atop-е это сразу видно.

[gigigi]

Да, они то вдвоём туда и пишут\читают. Сегодня вынесем монгу на отдельный сервер и надеюсь всё хорошо будет)