Возможный дубликат:
MySQL убивает IO сервера.
Я управляю довольно большими / загруженными форумами vBulletin (работающими в облаке gigenet), база данных составляет ~ 10 ГБ (~ 9 миллионов сообщений, ~ 60 запросов в секунду), в последнее время MySQL измельчает диск, как будто завтра не будет, согласно iotop и замедление сайта.
Последняя идея, о которой я могу думать, - это использовать репликацию, но я не уверен, насколько это поможет, и беспокоился о синхронизации базы данных.
У меня нет идей, любые советы о том, как улучшить ситуацию, были бы очень признательны.
Технические характеристики:
Debian Lenny 64bit
~12Ghz (6 cores) CPU, 7520gb RAM, 160gb disk.
Kernel : 2.6.32-4-amd64
mysqld Ver 5.1.54-0.dotdeb.0 for debian-linux-gnu on x86_64 ((Debian))
Другое программное обеспечение:
vBulletin 3.8.4
memcached 1.2.2
PHP 5.3.5-0.dotdeb.0 (fpm-fcgi) (built: Jan 7 2011 00:07:27)
lighttpd/1.4.28 (ssl) - a light and fast webserver
PHP и vBulletin настроены на использование memcached.
Настройки MySQL:
[mysqld]
key_buffer = 128M
max_allowed_packet = 16M
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 1024
query_cache_limit = 2M
query_cache_size = 128M
expire_logs_days = 10
max_binlog_size = 100M
key_buffer_size = 128M
join_buffer_size = 8M
tmp_table_size = 16M
max_heap_table_size = 16M
table_cache = 96
Другой :
> vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
9 0 73140 36336 8968 1859160 0 0 42 15 3 2 6 1 89 5
> /etc/init.d/mysql status
Threads: 49 Questions: 252139 Slow queries: 164 Opens: 53573 Flush tables: 1 Open tables: 337 Queries per second avg: 61.302.
редактировать Дополнительная информация.
Если трафик вашего форума похож на трафик, который я наблюдал при управлении vBulletin, вы действительно не должен вызывать PHP или MySQL для 50-75% запросов (т.е. более половины запросов поступают от неаутентифицированных «скрытых»).
Взгляните на реализацию обратного прокси-сервера для неаутентифицированных пользователей, если вы еще этого не сделали - если вы не внесли серьезных изменений в vBulletin, неаутентифицированные пользователи все равно не увидят динамический контент.
Обновить: Связанное чтение: Как настроить Nginx как кэширующий обратный прокси?
Независимо от того, можете ли вы уменьшить накладные расходы, я бы рекомендовал репликацию MySQl на вторичный сервер. С помощью некоторых балансировщиков нагрузки вы можете значительно сократить время простоя и снизить нагрузку на сервер. Просто мысль. Напишите мне, если вам нужны инструкции по настройке репликации.
Во-первых, хотя это касается лишь косвенно, вам, вероятно, следует подумать о переходе с MyISAM на InnoDB. Он будет лучше работать при таком типе параллелизма, который у вас, вероятно, есть, и с гораздо меньшей вероятностью потеряет данные в случае сбоя.
Сколько памяти вы скармливаете экземпляру memcached? Увеличение этого параметра может помочь, если у вас много выселений и промахов, но это потребует некоторых экспериментов.
128 МБ определенно слишком мало для key_buffer, учитывая размер вашего набора данных и доступную оперативную память. Я бы сказал, что это должно быть больше 1-2 ГБ, если вы можете сэкономить ОЗУ (или, если вы переключитесь на InnoDB, замените «key_buffer» на «Размер буферного пула InnoDB»). Ваши «входящие блоки» в 3 раза больше, чем ваши блоки, что, вероятно, означает, что MySQL должен поразить диск для значительной части операций чтения. Вы можете использовать mysqltuner или статистику в phpmyadmin, чтобы увидеть, нужно ли настраивать такие вещи, как буфер сортировки и т. Д., Но, скорее всего, это не самая большая проблема.
Проверьте свою подробную статистику, например частоту совпадений, в кеше запросов. Есть неплохой шанс, что он на самом деле не приносит вам никакой пользы и должен быть отключен, тем более, что вы также используете кеш памяти.
Хорошая новость в том, что вы привязаны к чтению, а не к записи, что означает, что вы можете относительно легко повысить производительность с помощью кеширования. В худшем случае, если у вас недостаточно свободной оперативной памяти для увеличения key_buffer или memcached и вы не можете расширить свой текущий сервер, вы можете переместить lighttpd и memcached на отдельный соседний сервер и выделить все ~ 8 ГБ для MySQL. С набором данных 10 ГБ этого будет достаточно. Нет необходимости прибегать к ведомому устройству репликации ради производительности, хотя, как уже упоминал кто-то другой является полезно для резервного копирования и восстановления после сбоя.
Если у вас 8 ГБ ОЗУ, объем памяти для сервера mysql кажется небольшим. Находятся ли ваша база данных и веб-сервер на одном хосте? Простым решением может быть просто установка второго хоста и разделение служб Интернета и базы данных, если вы еще этого не сделали.
Это типичная проблема SQL (не имеет значения 3, является ли это Oracle, sql-server, mysql).
Базы данных связаны io. Часто необходимо иметь много быстрых дисков. VPS часто не позволяют узнать, что у вас здесь. Если вы говорите «диск 169 ГБ», тогда возникает вопрос - какой у вас бюджет ввода-вывода? Если это простой небольшой виртуальный диск на простом диске или рейд 5 ... общий ... дешевый ... добро пожаловать, чтобы замедлить ввод-вывод. если это на FAST дисках, рейд 10 .... это проблема. Кроме того, такого размера ваш сервер очень "необычен" в том смысле, что он маленький. База данных 10 ГБ Я бы все это держал в памяти (серверная память 12-16 ГБ только для сервера db). и 6 ядер и 7 ГБ - это немного странно (мало памяти для такого количества ядер).
Для оптимизации вы можете: