2017-02-01 13 views
7

Мы используем стек PHP на наших серверах приложений, которые используют локальный (через сокет) twemproxy, для подключения к нескольким вышерасположенным серверам memcached (небольшие экземпляры EC2) для нашего слоя кеширования.Twemproxy Lag Force a Restart

Каждый раз я получаю предупреждение от нашего монитора приложений, что время загрузки страницы занимает> 5 секунд. Когда это происходит, немедленное исправление заключается в перезапуске службы twemproxy на каждом сервере приложений, что является проблемой.

Единственное исправление, которое у меня есть, - это кронаб, который запускается каждую минуту и ​​перезапускает службу, но, как вы можете себе представить, ничто не записывается в течение нескольких секунд каждую минуту, что не является желательным, постоянным решением.

Неужели кто-нибудь сталкивался с этим раньше? Если да, то в чем проблема? Я попытался переключиться на AWS Elasticache, но он не имел такой же производительности, как и наше текущее решение twemproxy.

Вот моя конфигурация twemproxy.

default: 
    auto_eject_hosts: true 
    distribution: ketama 
    hash: fnv1a_64 
    listen: /var/run/nutcracker/nutcracker.sock 0666 
    server_failure_limit: 1 
    server_retry_timeout: 600000 # 600sec, 10m 
    timeout: 100 
    servers: 

    - vcache-1:11211:1 
    - vcache-2:11211:1 

А вот соединение конфигурации для PHP слоя:

# Note: We are using HA/twemproxy (nutcracker)/memcached proxy 
# So this isn't a default memcache(d) port 
# Each webapp will host the cache proxy, which allows us to connect via socket 
# which should be faster, as no tcp overhead 
# Hash has been manually override from default jenkins to FNV1A_64, which directly aligns with proxy 
port: 0 
<?php echo Hobis_Api_Cache::TYPE_VOLATILE; ?>: 
    options: 
    - <?php echo Memcached::OPT_HASH; ?>: <?php echo Memcached::HASH_FNV1A_64; ?><?php echo PHP_EOL; ?> 
    - <?php echo Memcached::OPT_SERIALIZER; ?>: <?php echo Memcached::SERIALIZER_IGBINARY; ?><?php echo PHP_EOL; ?> 
    servers: 
    - /var/run/nutcracker/nutcracker.sock 

Мы бежим 0.4.1 twemproxy и 1.4.25 Memcached.

Спасибо.

+0

Это проблема установки crontab –

ответ

0

Я кончался переключение с Сокета на TCP-порт на локальном хосте, и это, кажется, решили проблему перезапуска. Однако я заметил всплеск времени ответа при создании коммутатора из-за накладных расходов, связанных с tcp. Не принимая этот ответ в надежде, что кто-то по дороге опубликует более авторитетный ответ о гнездах ...

1

Я не очень осведомлен о twemproxy и memcached.but, но я даю ссылку на вас для более подробной информации. Может быть, это будет полезно для вас.

https://github.com/twitter/twemproxy

+0

Ссылка на репо не помогает, вот где я получил код изначально и нет упоминания о проблеме, которую я имею. –

+0

Соединительные разъемы @MikePurcell могут быть проблемой –

+0

Сокеты @MikePurcell TCP остаются открытыми до тех пор, пока они не будут закрыты. очень сложно обнаружить сломанное соединение (сломанное, как в случае с маршрутизатором, и т. д., в отличие от закрытого) без фактической отправки данных, поэтому большинство приложений делают какую-то реакцию ping/pong так часто, чтобы убедиться, что соединение все еще на самом деле жив. –

3

Количество открытых/несвежих соединений патрубков может быть проблемой

+0

Хммм, что они могут складываться, я посмотрю на это. –

+1

Значит, он не должен был пытаться помочь ОП? У него есть что-то, что может направить OP на решение, но вы бы предпочли его заткнуться? Я клянусь, что Stack Overflow полон нарциссических людей, которые просто хотят испортить чужой опыт ... OP выглядит счастливым, чтобы получить этот комментарий, и Киран сделал все, что мог, чтобы высказать свое мнение, поскольку Stack не позволит ему прокомментировать ... Поэтому, пожалуйста, Йорн ... Оставьте и позвольте людям быть. Это сайт, где мы помогаем людям. Запись Кирана была полезна. Твой - все, но полезно. Upvoting вас Киран. Dunno, если он решит его проблему, но вы попытались помочь - против других - –