MySQL масштабируется или масштабируется?

Question

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

Веб-приложение само по себе написано на PHP и частично написано на Perl, и у нас есть база данных MySQL, в которой я считаю, что источник удара производительности происходит.

У нас около 400 пользователей системы, большинство из которых распространены в разных часовых поясах, поэтому обычно в любой момент доступно только 30 пользователей в Интернете. Проблемы с производительностью выросли на нас, особенно за последний год, поскольку база данных продолжает расти.

Система работает на одном 32-разрядном сервере debian - 6 ГБ оперативной памяти с 8 х 2.4 ГГц процессором Intel. Это, вероятно, недостаточно для работы в руке. Однако даже в моменты, когда я единственный пользователь онлайн, время загрузки страницы может быть медленным.

Я пытаюсь определить, нужно ли масштабировать или масштабировать. Во-первых, я хотел бы знать, насколько хорошо наше оборудование справляется с требованиями, предъявляемыми к нему. А во-вторых, стоит ли масштабировать и создавать некоторые подчиненные репликации для балансировки нагрузки.

В Интернете доступно множество инструментов - возможно, слишком много для расследования. Может ли кто-нибудь рекомендовать какие-либо инструменты, которые могут обеспечить некоторый мониторинг профилирования/производительности, который может помочь мне в моих поисках.

Большое спасибо, нс

Answer 1

Ваше замедление, похоже, связано с данными, а не с номером из числа одновременных пользователей.

Правильно проиндексированные запросы имеют тенденцию логарифмически масштабироваться с объемом данных, то есть удвоение данных увеличивает время запроса на некоторую константу C, удваивая данные снова тем же C, удваивая снова тот же C и т. д. ... Прежде чем вы это узнаете, у вас есть огромное количество данных, но ваши запросы - это всего лишь . более медленный.

Если медленный d собственный не был столь постепенным в вашем случае (т. он был линейным по отношению к количеству данных или, что еще хуже), это может быть признаком плохо оптимизированных запросов. Бросив больше железа на проблему отложим, но если у вас есть неограниченный бюджет, вы будете на самом деле решить первопричину в какой-то момент:

1. Мера производительность запроса на фактических данных для выявления медленно запросы.
2. Изучите планы выполнения возможных улучшений.
3. При необходимости узнайте о indexing, clustering, covering и других технических характеристиках.
4. И, наконец, примените это знание к запросам, которые вы определили в шагах (1) и (2).

Если ничего другого не помогает, подумайте о своей модели данных. Иногда «идеальная» нормализованная модель не самая эффективная, поэтому может потребоваться небольшая судебная денормализация.

Answer 2

Простой (ленивый) способ, если у вас есть бюджет просто бросить еще некоторое количество железа в нем.

Лучшим способом было бы, прежде чем решать, где и как масштабироваться, было бы выявление узких мест. Это медленная работа с каждой страницей? Или только отдельные страницы? Если это всего лишь несколько страниц, тогда инвестируйте в профилировщик (для PHP оба xDebug и Zend Debugger могут выполнять профилирование). Я бы также (если вы этого не сделали) инвестировать в тестовую систему, максимально похожую на живую систему для запуска диагностики.

Вы также можете посмотреть на сбор статистики; либо на уровне сервера с такой программой, как sar (from the sysstat package, а также на уровне db (у вас работает медленный журнал запросов?).