Кэширование MemCached

[TM123]

Нормально использовал CMemCached, все нормально сохраняется, живет и умирает как положено. Сегодня столкнулся со следующей ситуацией.

После рестарта memcached, примерно в 80% случаев не хочет запоминать значение типа int во вновь созданном функционале, при этом можно провести нескольких до несколько десятков попыток пока одумается, по времени может пару нажатий F5, а может и десятки секунд, количество попыток и время одумывания всегда разное и отличается в разы, закономерности не заметил, при этом если сначала воспользоваться функционалом в котором memcached использовался до этого - работает нормально, и примерно в 90% случаев все начинает работать так же нормально, если не заработало, то без перезапуска уже не заработает, при этом ранее разработанный функционал по прежнему нормально. Алгоритмы работы с кэшированием и в 100% работающих и в неработающем варианте полностью одинаковые -> set -> get. Проект по использованию кэша не сильно нагруженный.

Проверял варианты:
- статус демона - всегда рабочий
- увеличил количество коннектов до 1024, всего принципиально могут воспользоваться сайтом менее 1000 пользователей
- увеличил количество памяти до 1GB, в реальность используется хранение схем примерно 10 баз данных и оперативные данные примерно 400-500 пользователей, но все равно сразу после рестарта памяти по любому должно хватать.
- пытался пихать большие массивы, типа что-то в буфере зависает - при смене размер не влияет

В общем вопросы:
- что можно еще посмотреть и попробовать чтобы все начала работать устойчиво
- как выяснить ошибку которую вернул memcached, ответа типа false если в кэш не записалось явно маловато
- почему при использовании флага useMemcached все перестает работать, при этом обращение идет именно в memCached,т.к. при подаче rcmemcached restart весь кэш забывается.
- как посмотреть в memcached сколько памяти сейчас он уже использует и сколько осталось

Версия Yii 1.1.9

[Faster]

статистику мемкеша можно глянуть в консоли или поставить браузерную статсу типа Memcache stats v0.1 - там увидишь сколько памяти и процент misses.
ошибки глянуть можно как то $_CACHE->getResultCode()
вообще для тестов лучше ручками собери страницу с простым классическим php api memcached, с его методами и смотри без yii кеша.

зы: какой смысл заморачиваться с таким траффиком непонятно. Опять таки непонятно делишь ли ты демона с соседями по хосту, дедик или вдс у тебя, может просто тупо рвать коннект или не хватать таймаута

[TM123]

Ну во-первых сервер собственный железный
Ну а во-вторых надо хранить некую инфу, складывать их в SESSION или cookies нет возможности по требованиям безопасности.

[TM123]

Ну так что, никто не знает почему MemCached может не всегда запоминать значения и тупить.

[Faster]

замеряй время: коннекта, записи, чтения.
скинь типичный пример использования в yii.
процент misses на 1000 операций какой

[TM123]

Не понял причем тут время коннекта, записи и чтения, у меня нет проблемы со временем соединения, memCached живет на том же сервере, визуально оно равно нулю, просто в одних случаях соединение проходит, в других нет. Функции Yii возвращают либо true, либо false и никакой диагностики а собственно что произошло то, что пошло не так.

Пример использования - Yii::app()->cache->set($name, $value, $time), ничего сверх ординарного.

[TM123]

Что же, не был тут год, ничего не изменилось, есть масса людей готовых обсуждать и обсасывать всякую фигню, серьезные вещи как и ранее тишина. Вот у меня возникает законный вопрос, тут нет вообще серьезных людей? вообще наблюдая за происходящим в IT сфере, появилось много людей совершенно не понимающих основ, пользуются чужими библиотеками и примерами чужого кода, компонуют кубики, а сути совсем не понимают, копни поглубже и полная пустота в голове. Грустно все это.

[anton44eg]

1 - обновите Yii
2 - попробуйте поработать с Memcache не через обёртку Yii. Такая же ситуация с частичным запомнианием

П.С. Да, это грустно...

[flashimage]

если в соединении localhost - попробуйте поменять на 127.0.0.1 - может с резолвом что-то

[Faster]

>Что же, не был тут год, ничего не изменилось, есть масса людей готовых обсуждать и обсасывать всякую фигню, серьезные вещи как и ранее тишина.
на мои вопросы вообще никто ответить не может
>2 - попробуйте поработать с Memcache не через обёртку Yii. Такая же ситуация с частичным запомнианием
я уже писал во втором посте
>вообще для тестов лучше ручками собери страницу с простым классическим php api memcached, с его методами и смотри без yii кеша.
потому что уже наступил на грабли Yii один раз:
viewtopic.php?f=3&t=14084

[Faster]

кстати вот конкретно сегодня не нашел в Yii CMemcache методов increment-decrement пришлось допиливать

[TM123]

1. С обновлением Yii трабл, в исходниках много чего подправлено, просто так не накатить. Да конечно, где можно было безболедненно перекрыть класс так оно и сделано, но во многих местах подверглось переработке само ядро фреймворка, потому что там были не эффективные тормознутые алгоритмы, по сути то что сейчас у меня - это Yii на 95%. По хорошему надо было и там перекрывать классы, но тогда не было времени на разбирательства как и где надо подстроить фреймворк чтобы вместо исправления исходников перекрыть класс, который находится на таком низком уровне.
2. У меня нет частичного запоминания, он либо все запоминает, либо ничего в пределах работы страницы, т.е. либо все пакеты, либо ни одного. Я наблюдал за ситуацией еще, если первое запоминание прошло, не важно в каком участке проекта, то все будет работать везде до рестарта демона. Однако есть участки проекта где запоминание проходит всегда или я не знаю о том что там оно не всегда проходит, а есть где если оно оказалось первым, то не запоминает, но стоит в другом куске запоминанию пройти и тут тоже будет работать железно до следующего перезапуска демона. Сначала я думал что возможно не происходит инициализация библиотеки кэша, потом искал разницу в кусках кода - там где работает и где нет, все одно и тоже, лазил в исходники фреймворка - ничего не нашел. Есть подозрение, что возможно все таки дело в CActiveRecord и тем что она хранит схему в кэше (у меня включено), те места где всегда работает - они перед запоминанием очень много дергают модели и возможно модель корректно инициализирует компонент кэша - первичный коннект (все живет на php-fpm, возможно он не рвет соединение после первого успешного коннекта), а те места, где у меня работает неустойчиво, там с моделями работа не ведется и возможно не всегда проходит корректно первая инициализация. Завтра буду копать в эту сторону, буду смотреть как идет кэширование схем БД и попробую работать по такой же схеме. Хорошо бы найти как сам PHP работает с memCached, если он в режиме fastCGI устанавливает соединение только раз и потом держит активный пул, тогда траблы как раз в генерации этого пула, надо еще посмотреть будет нет ли своего настроечного файла для memCached библиотеки в самом PHP, может есть какой потайной ключик.
3. Прописан 127.0.0.1

[kukuruku]

вроде бы серьезный человек, работает в крупной секретной конторе (судя по посту viewtopic.php?p=89413#p89413), при этом вопросы явно джуниорского уровня
во первых какие могут быть вопросы если версия yii устаревшая? причем я сам в этой версии поймал одну неприятную ошибку, пока не обновился
дальше- если кеш не слишком нагруженный то поставить xcache или apc, или любой другой и использовать их
ну и самый сложный вариант- взять чистый сервак, поставить чистый софт, последний yii и проверить работу

[TM123]

вроде бы серьезный человек, работает в крупной секретной конторе, при этом вопросы явно джуниорского уровня
во первых какие могут быть вопросы если версия yii устаревшая? причем я сам в этой версии поймал одну неприятную ошибку, пока не обновился
дальше- если кеш не слишком нагруженный то поставить xcache или apc, или любой другой и использовать их
ну и самый сложный вариант- взять чистый сервак, поставить чистый софт, последний yii и проверить работу

А можно у мегаспеца спросить, вот у меня 14 метров кода PHP + SQL + JS + HTML + CSS - это лично мой код и еще порядка 2 метров кода изменено в самом Yii, вы можете ответить сколько времени я будут перетестировать этот код на то что после смены версии ничего не поменялось, не знаю как у вас, а у меня косяк может стоить несколько миллионов ушедших на левый счет или товар отпущенный без оплаты или просто вся компания не сможет авторизоваться на своих компах, потому что я тупо не снял блокировку в LDAP их логинов после того как они махнулись карточкой о приходе на работу. А еще есть куча внешних систем с которыми имеется тесная интеграция и 1С одна из самых маленьких проблем из них, все эти интеграции надо будет тоже перетестировать, да есть договоренные форматы, но то что данные соответствуют форматам это еще не говорит о том что они соответствуют логике. Если вы не в состоянии ответить на этот простой вопрос, я вам скажу что пересесть на новую версию со всеми переносами изменений сделанными в Yii, тестированиями и исправлениями ошибок займет 3-6 месяцев, а все это время тот функционал, ради которого затеяно обновление работать не будет, потому что все это будет проводится на тестовом сервере.

[R3D3]

Ну если 14 метров кода, и правленное ядро фреймворка (по-моему, править код фреймворка это очень очень очень плохо), то все попытки указать, в чем может быть проблема в использовании memcache - это пальцем в небо. Попробуйте развернуть копию проекта на тестовом сервере, если там будет воспроизводиться баг - заменяйте по очереди компоненты на стандартные и проверяйте снова.

[R3D3]

После рестарта memcached, примерно в 80% случаев не хочет запоминать значение типа int во вновь созданном функционале, при этом можно провести нескольких до несколько десятков попыток пока одумается

И вот эта формулировка проблемы какая-то недетерминированная.

• По каким показателям вы определяете, запомнил или не запомнил?
• Где примеры кода на котором наблюдается неправильное поведение?
• Что возвращает Memcached::getResultCode() ?
• Пробовали ли вынести мемкеш на отдельный сервер?
• Нет желания перейти на redis ?

[TM123]

Судя по всему я нашел проблему, по крайней мере я не смог добиться чтобы у меня обломилось в течение 8 минут последовательных restart memcached demon и попыткой писать.

Что выяснено:
1. Те места, которые я считал работающими всегда, оказалось что они скорее работают, но в них местами возникает та же проблема. Разница между местами скорее работающими и скорее не работающими в размере сохраняемых данных, те что чаще работают сохраняют килобайты данных, те что чаще не работают сохраняют по несколько байтов данных. Мои мысли про CActiveRecord тут не причем, я не смог ничего найти на эту тему в исходниках
2. Есть в настройках php такой параметр как - memcache.chunk_size="8192", в рекомендациях сказано что при росте нагрузки на сеть надо увеличивать до 32kB, я сделал наоборот, уменьшил до 1024, кэш сервер стоит на той же машине что и web сервер и используется в основном не для увеличения производительности. Количество проблем снизилось раз в 10, по крайней мере в проблемных местах стал вылетать облом очень редко, каждый 10-15 перезапуск, при этом раньше облом вылетал в 7-8 случаях из 10 перезапусков.
3. Далее обнаружил проблему, что Yii возвращает облом, однако не всегда это соответствует истине, имеется много случаев, когда в реальности, попытка прочитать из кэша, не установленные с точки зрения Yii данные, в реальности читаются и не имеют повреждений.
4. Накопал что это очень распространенная проблема, PECL выдает warnng - MemcachePool::get() [<a href='memcachepool.get'>memcachepool.get</a>]: Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout (0) . Копание в эту сторону ни к чему толковому не привело. Рекомендации по версиям софта, типа баги и т.д. ничем не закончились, весь софт у меня соответствует рекомендациям или лучше. Возможно где-то не правильно понял по английски, но есть предложения использовать вместо memcache.protocol="ascii" настройку "binary", однако не смотря на все заявления, на openSuSE у меня с такой настройкой PECL memCached вообще перестает работать. Все нормально стартует, но PHP на моменте исполнения уходит в небытие.
5. И финал после чего проблема победилась окончательно (надеюсь) - установил в настройках cache в config Yii параметр 'persistent' => false, по умолчанию стоит true, собственно выяснил из исходников.

Итого, как мне видится проблема:
При рестарте демона, иногда он запаздывает со стартом на какие-то доли секунды, а Yii, имея по умолчанию многосерврерную настройку, не получив тут же ответа от сервера, начинает пытаться искать другие кэширующие сервера в сети, а их не в настройках PHP (по умолчанию односерверная настройка на локальном сервере), ни в настройках Yii и как следствие в настройках PECL нет и возвращается ошибка сетевого таймаута, типа ну не получили из сети ни одного ответа в течение таймаута - бред конечно, ведь никаких запросов вообще не было, но логику разработчиков PECL memCached или Yii тут не будем обсуждать. Установка данного параметра, по всей видимости заставляет прекратить умничать и либо ждать ответа дольше, либо делать все выделенные попытки установить соединение на единственный имеющийся сервер, а за это время демон оживает.

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

Лично мое мнение, по умолчанию в настройках Yii следует ставить данный параметр в false, потому что думаю в 95% случаев использования Yii с memCached - это вариант с одним сервером в пуле и скорее всего стоящем на том же сервере что и веб сервер, но при этом, по крайней мере на openSuSE, такая настройка по умолчанию вводит в ступор PECL или Yii - кому интересно, разбирайтесь.

[TM123]

=> R3D3

1. Править ядро не стоит, но так звезды сложились, найден был косяк в Yii, а ждать исправления было некогда, потом еще, потом не было времени разбираться как перенастроить фреймворка на перекрытые классы на таком низком уровне. Сейчас по мере сил и возможностей все это выправляется, ну а пока приходится жить с этим обременением
2. Проверка проводится очень просто, записал, прочитал, а в ответ тишина, ну это на случай если не очень верится в возвращенный false пишущим методом