Вопрос: Memcached Lagging


Позвольте мне предисловие к этому, сказав, что это следующий вопрос: Эта тема,

Это было «решено», переключившись с Solaris (SmartOS) на Ubuntu для сервера memcached. Теперь мы увеличили нагрузку примерно на 5 раз и снова столкнулись с проблемами.

Мы запускаем сайт, который выполняет около 1000 запросов в минуту, каждый запрос попадает в Memcached с приблизительно 3-мя чтениями и 1 записью. Таким образом, загрузка составляет примерно 65 запросов в секунду. Общее количество данных в кеше составляет около 37M, и каждый ключ содержит очень маленький объем данных (массив JSON-целых чисел, составляющий менее 1K).

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

Execution Time from StatsD

Что может вызвать эти шипы? Зачем 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
        )

)

Изменить: Вот результат набора и извлечения 10 000 значений.

Нормальный:

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

Когда Spiking:

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

6
2018-05-09 20:53


Источник


Могу я предложить вам запустить тестовый (!) Экземпляр этого memcached под любым эквивалентом strace на Solaris (IINM называется фермой, не занимался солярием на века, хотя ...) - rackandboneman


Ответы:


Может возникнуть проблема с сетевым стеком. У меня возникла проблема с memcached, и причина закончилась обработчиками linux conntrack. Можете ли вы проверить вывод netstat -s -t до и после всплесков, чтобы проверить ошибки tcp и повторные передачи. Вы также можете попытаться использовать wirehark для просмотра дампа трафика для получения дополнительной информации о проблеме.


0
2018-05-16 07:15





В дополнение к рассмотрению статистики вашей сети, возможно ли обновление до версии 1.4.10 (или выше), которое может улучшить производительность? Из 1.4.10 примечания к выпуску:

Этот выпуск ориентирован на масштабируемость и производительность потоков   улучшения. Этот выпуск должен иметь возможность быстрее загружать данные   чем любая сетевая карта может поддерживать на момент написания этой статьи.

В то время как наши серверы не получают ваш трафик, в нашем случае это помогло обновление до 1.4.10, равно как и включение сжатия (у нас были значения больше 1 МБ) и бинарный протокол. См. Мой ответ на Drupal SE для деталей.


0
2018-05-23 13:39





Проблема оказалась в том, что вызывающая машина ест весь свой доступный процессор. Это вызывало странные проблемы, и казалось, что memcached был проблемой, когда на самом деле это не так. Это было всего лишь симптомом большой проблемы.

Масштабирование веб-уровня горизонтально решило проблему.

Если вы находитесь на Joyent, полезная команда, чтобы узнать, какая часть вашего кепка процессора вы используете jinf -c


0
2018-06-18 00:13