Predis: Ошибка при чтении строки с сервера

Вы уже выполнили описанные здесь шаги для устранения проблемы, прежде чем открывать новую проблему с тем же названием? См. Также эту ветку в списке Redis, это также может быть что-то не связанное с проблемами на стороне клиента.

Спасибо nrk. Я попробую установить socket_timeout и read_write_timeout и сообщу о своих выводах здесь позже.

Если вы используете Predis в скрипте, подобном демону, вы должны установить read_write_timeout равным -1 если вы хотите полностью отключить тайм-аут (это значение работает как со старыми, так и с новыми версиями Predis). Также помните, что вы должны отключить тайм-аут Redis по умолчанию, установив timeout = 0 в redis.conf, иначе Redis

nrk, попробовал, как упоминалось, и теперь работает отлично. Спасибо!

Тем не менее, время от времени остается много тайм-аутов подключения. Я уже установил timeout = 0 и read_write_timeout на -1. Есть ли что-нибудь, что мы можем сделать, чтобы отладить это, когда это произойдет?

timeout не является параметром подключения, распознаваемым Predis, вместо него следует использовать connection_timeout . Значение по умолчанию для connection_timeout составляет 5 секунд, вы можете попытаться поднять его значение, но я не думаю, что это решение вашей проблемы. Вы должны попробовать и посмотреть, что происходит на вашем сервере, когда возникают эти таймауты, это действительно зависит от вашего приложения, поэтому я ничем не могу помочь. Возможные причины тайм-аутов:

1. проблемы с сетевым подключением, если ваш сервер Redis не находится на локальном хосте
2. Вы уверены, что не используете дорогостоящие вызовы команды KEYS где-то в своих сценариях? В зависимости от количества хранилищ ключей в Redis, KEYS может в конечном итоге заблокировать сервер, который тем временем не сможет обрабатывать другие запросы или входящие соединения.

Я оставлю этот вопрос пока открытым, но я совершенно уверен, что он определенно не имеет отношения к Predis.

nrk. Как и было рекомендовано, я увеличил connection_timeout до 30. Будем следить за этим.

1. Да, мы используем несколько узлов Redis, которые не являются localhost, но находятся в частной сети (так что, по крайней мере, должны быть более стабильными?)
2. Не использовать КЛЮЧИ. Однако мы делаем снимки каждые 900 секунд. Из журнала следует, что системе требуется 8 секунд для сохранения в HD. Разве это не должно быть причиной тайм-аута соединения, верно?
3. Любой совет относительно того, как контролировать сервер при истечении времени ожидания? Таймаут довольно случайный. Я проверил журнал Redis, и в основном это просто снимки сообщений.

Еще одно обновление, я измерил соединение, и оказалось, что действительно исключение произошло через 5 секунд. Я попытался изменить connection_timeout с помощью:

новый Predis_Client ($ param, array ('read_write_timeout' => -1, 'connection_timeout' => 30));

Это правильно? Кажется, что это не влияет на 30s connection_timeout и по-прежнему генерирует исключение.

Это параметры подключения, а не параметры клиента, поэтому read_write_timeout и connection_timeout должны быть указаны в качестве параметров в $param .

1. Если это не частная сеть на Amazon EC2 (высокая задержка и время от времени различные проблемы), то этого не должно быть.
2. Насколько мне известно, моментальный снимок не должен блокировать сервер
3. Вы можете проверить время тайм-аутов по журналам моментальных снимков. Помимо этого, это действительно зависит от архитектуры вашего приложения и вашей инфраструктуры, извините, но я не могу вам помочь в этом.

Честно говоря, Predis не делает ничего особенного с ресурсами сокета при подключении к хосту, поскольку это что-то почти полностью делегировано внутренним компонентам PHP, поэтому это может быть либо ошибка в PHP (маловероятно, но все же возможно), либо некоторая конфигурация / время выполнения. проблема на ваших серверах, или Redis выполняет некоторые тяжелые операции, которые в конечном итоге блокируют сервер на некоторое время.

nrk, еще раз спасибо за ваш ответ. Я обнаружил проблему, и это просто проблема с сервером ip_conntrack. Как только conntrack будет исправлен, истечет время ожидания соединения.

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

Получал ту же ошибку, решенную с помощью установки read_write_timeout как 0.
Я делал это в predis, можем ли мы сделать то же самое с помощью клиента predis?
как показано здесь http://code.google.com/p/dires/source/browse/trunk/predis/examples/PubSubContext.php?r=4
Я делаю предис-клиент, используя: $ redis = new Predis \ Client ("tcp: //". $ TurboConfig-> getActivitiesRedisHost ()); как передать read_write_timeout в моей реализации.

@amitchhajer клиент принимает одни и те же параметры соединения с именованными массивами или строками URI, поэтому, если вы используете строку URI, вы можете просто добавить ее, как если бы это была строка запроса: tcp://127.0.0.1:6379?read_write_timeout=0 .

@nrk спасибо за информацию, сейчас работает неплохо.

Что, если нам нужно изменить read_write_timeout во время выполнения? Существует ли какой-то установщик для параметров тайм-аута (кроме конструктора)?

Параметры соединения

$connection = $client->getConnection();
$stream = $connection->getResource();
stream_set_timeout($stream, 2);

Обратите внимание, что выполнение $connection->getResource() эффективно запускает операцию connect() для Redis, поэтому вы можете в конечном итоге потерять преимущества ленивых подключений в зависимости от того, как вы собираетесь использовать эту функцию.

Обратите внимание, что параметр connection_timeout был переименован в timeout в новой версии Predis.

Я довольно часто использую « h- ключи». Может ли это привести к блокировкам?

Если вы используете Predis в скрипте, подобном демону, вы должны установить read_write_timeout равным -1 если вы хотите полностью отключить тайм-аут (это значение работает как со старыми, так и с новыми версиями Predis). Также помните, что вы должны отключить тайм-аут Redis по умолчанию, установив timeout = 0 в redis.conf, иначе Redis

Есть ли какие-либо недостатки или предостережения, связанные с установкой тайм-аута = 0 в redis.conf?

Я подозреваю, что связи никогда не пропадут
Использование Redis останется высоким

nrk, еще раз спасибо за ваш ответ. Я обнаружил проблему, и это просто проблема с сервером ip_conntrack. Как только conntrack будет исправлен, истечет время ожидания соединения.

Как исправить этот договор .. где искать?

Есть ли какие-либо недостатки или предостережения, связанные с установкой тайм-аута = 0 в redis.conf?

@ aditya-rewari-cb на самом деле timeout = 0 в redis.conf используется по умолчанию, начиная с Redis 2.4 (выпущенного несколько лет назад), поэтому я бы сказал, что здесь нет недостатков.

Если вы используете Predis в скрипте, подобном демону, вы должны установить read_write_timeout равным -1 если вы хотите полностью отключить тайм-аут (это значение работает как со старыми, так и с новыми версиями Predis). Также помните, что вы должны отключить тайм-аут Redis по умолчанию, установив timeout = 0 в redis.conf, иначе Redis

@nrk Я использую Redis с процессами демона (работники супервизора laravel), а также с регулярным кешированием
Какие-нибудь предостережения при использовании read_write_timeout => -1?
Я хотел подтвердить любую возможность поломки или ошибки ... в моем обычном кешировании Redis из-за этого изменения!

Спасибо !