Позвольте мне предварить это, сказав, что это следующий вопрос к Эта тема.
Это было «решено» переключением с Solaris (SmartOS) на Ubuntu для сервера memcached. Теперь мы увеличили нагрузку примерно в 5 раз и снова столкнулись с проблемами.
У нас есть сайт, который выполняет около 1000 запросов в минуту, каждый запрос попадает в Memcached примерно за 3 чтения и 1 запись. Таким образом, нагрузка составляет примерно 65 запросов в секунду. Общий объем данных в кеше составляет около 37 МБ, и каждый ключ содержит очень небольшой объем данных (массив целых чисел в кодировке JSON размером менее 1 КБ).
На этих страницах мы установили сценарий тестирования и загрузили данные в StatsD для регистрации. Проблема в том, что бывают всплески, когда Memcached очень долго реагирует. Похоже, что они не коррелируют с скачками трафика.
Что могло быть причиной этих всплесков? Почему memcached тратит секунду на ответ? Мы только что загрузили второй сервер, чтобы добавить его в пул, и это не повлияло на частоту или серьезность всплесков.
Это результат работы getStats () на серверах:
Array
(
[-----------] => Array
(
[pid] => 1364
[uptime] => 3715684
[threads] => 4
[time] => 1336596719
[pointer_size] => 64
[rusage_user_seconds] => 7924
[rusage_user_microseconds] => 170000
[rusage_system_seconds] => 187214
[rusage_system_microseconds] => 190000
[curr_items] => 12578
[total_items] => 53516300
[limit_maxbytes] => 943718400
[curr_connections] => 14
[total_connections] => 72550117
[connection_structures] => 165
[bytes] => 2616068
[cmd_get] => 450388258
[cmd_set] => 53493365
[get_hits] => 450388258
[get_misses] => 2244297
[evictions] => 0
[bytes_read] => 2138744916
[bytes_written] => 745275216
[version] => 1.4.2
)
[-----------:11211] => Array
(
[pid] => 8099
[uptime] => 4687
[threads] => 4
[time] => 1336596719
[pointer_size] => 64
[rusage_user_seconds] => 7
[rusage_user_microseconds] => 170000
[rusage_system_seconds] => 290
[rusage_system_microseconds] => 990000
[curr_items] => 2384
[total_items] => 225964
[limit_maxbytes] => 943718400
[curr_connections] => 7
[total_connections] => 588097
[connection_structures] => 91
[bytes] => 562641
[cmd_get] => 1012562
[cmd_set] => 225778
[get_hits] => 1012562
[get_misses] => 125161
[evictions] => 0
[bytes_read] => 91270698
[bytes_written] => 350071516
[version] => 1.4.2
)
)
Изменить: вот результат набора и извлечения 10000 значений.
Нормальный:
Stored 10000 values in 5.6118 seconds.
Average: 0.0006
High: 0.1958
Low: 0.0003
Fetched 10000 values in 5.1215 seconds.
Average: 0.0005
High: 0.0141
Low: 0.0003
При пике:
Stored 10000 values in 16.5074 seconds.
Average: 0.0017
High: 0.9288
Low: 0.0003
Fetched 10000 values in 19.8771 seconds.
Average: 0.0020
High: 0.9478
Low: 0.0003
Проблема заключалась в том, что вызывающая машина съедала весь доступный процессор. Это вызывало странные проблемы, и казалось, что проблема в memcached, хотя на самом деле это не так. Это был всего лишь симптом более серьезной проблемы.
Горизонтальное масштабирование веб-уровня решило проблему.
Если вы используете Joyent, полезная команда, чтобы узнать, сколько ресурсов вашего ЦП вы используете, jinf -c
Возможно ли обновление до версии 1.4.10 (или выше), в которой есть улучшения производительности, помимо проверки вашей сетевой статистики? Из Примечания к выпуску 1.4.10:
Этот выпуск ориентирован на масштабируемость потоков и повышение производительности. Этот выпуск должен иметь возможность передавать данные быстрее, чем может поддерживать любая сетевая карта на момент написания этой статьи.
Несмотря на то, что наши серверы не получают трафик, полученный вами, в нашем случае помогло обновление до 1.4.10, а также включение сжатия (у нас были значения больше 1 МБ) и бинарный протокол. Смотрите мой ответ на Drupal SE для подробностей.
Может быть проблема с сетевым стеком. У меня похожая проблема с memcached, и причина в том, что у меня заканчивались обработчики conntrack linux. Можете ли вы проверить вывод netstat -s -t до и после всплесков, чтобы проверить ошибки TCP и повторные передачи. Вы также можете попробовать использовать wirehark для просмотра дампа трафика для получения дополнительной информации о проблеме.