New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalidation problem #75
Comments
Делать flushdb во время работы не надо просто. Либо одновременно с Дело в том, что схемы кешируются в памяти процесса, поэтому при втором |
Ну я не жалуюсь. Так мы делали на тестовом сервере. Поле slug никак не хочет добавляться в ключ:
Вот и пытаемся разобраться. |
Что значит кэш не обновляется по полю slug? Идеальный ответ был бы в виде |
У нас запросы вида Brand.objects.get(slug=***) не инвалидируются. Вчера вечером в ключ "schemes:catalog.brand" я в ручную добавил поле slug. Я создал его в ручную. Добавил в него поля id и slug. Через несколько часов, slug удалился, но добавился is_active. Каким образом могло поле slug удалиться из ключа "schemes:catalog.brand" ? |
Сейчас, просмотрел код. Теоретически возможна ситуация когда происходит рассинхронизация схем в памяти процесса и в редисе при частом обновлении какого-то m2m. Стоит попробовать использовать master кешопса отсюда, в нём проблема устранена. |
Поставил из мастера, понаблюдаю как будет работать. |
Не знаю, нормально или нет, создались вот такие ключики:
В коде есть такие запросы:
|
Также, в случае рестарта Redis, пока не рестартану приложение, получаю такую ошибку:
|
Ключики - ненормально, даже 2 ненормальности:
|
Ах, да. главный вопрос. Инвалидация-то работает? |
Проблема с
|
Инвалидация да, работает. Пока проблем не было.
Результат:
|
Попробовал воспроизвести, у меня не получается. Можно попробовать следующее:
1 можно сделать быстро. 2 - в идеале. И обновить cacheops до последнего мастера перед тем как начинать ) |
Код питона:
Лог redis:
|
Вариант 1:
Вариант 2
|
Это явно очень старая версия cacheops, в последнем мастере не используются транзакции. |
Хм, я обновил до последнего мастера.
Сейчас его полностью удалю и заново поставлю. |
Под очень старой я имею в виду "по сравнению с мастером". И вообще происходит что-то странное, т.к. ошибка со скриптами (NOSCRIPT) может происходить только если используется новая версия, а |
|
redis-cli:
monitor log:
|
Вот еще интересное:
redis-cli:
monitor log:
|
Обновился до мастера, появилось две ошибки:
Второй:
|
Скорее всего либо что-то не так с редисом, либо с redis-py. Какие версии используются? Используется ли hiredis? Какой версии? |
Хм. В принципе, первая ошибка может возникать если Вторая может быть каким-то ограничением lua, с которым я не сталкивался. |
Мне удалось воспроизвести первую ошибку, возникает при кешировании гарантированно пустого запроса, например |
Вторая ошибка проявилась всего один раз. Причём это админка.
|
Я исследовал вторую ошибку. Она возникает когда инвалидируется за раз большое количество ключей (граница где-то между 6000 и 8000). Ограничение вшито в Lua. Я добавил workaround. Но, вообще, нехилая у вас там инвалидация в админке. |
Хм. Это добавлялся новый объект. В БД 32000 записей.
Что делать в большими БД ? |
Количество записей особого значения не имеет, я использовал cacheops с большими БД. Дело было в количестве выборок инвалидируемых за раз, но сейчас и это будет работать. Хотя если при обновлении одного объекта стирается кеш для нескольких тысяч запросов, то, возможно, такие запросы кешировать смысла не имеет. Такая ситуация может возникать когда вы делаете неспецифические выборки - без простых условий на равенство или только с очень распространённым условием, вроде |
Ещё один вариант наделать кучу запросов это так: # выбрать новости за сутки
News.objects.filter(time_creared__gt=datetime.now() - timedelta(1))
|
Повторяющиеся geo_id остались, это норма?
Вызов dnf(queryset)
|
Это добавляет некоторую неэффективность, но проблем от этого не будет. |
Conflicts: CHANGELOG
Заметил такое странное поведение при инвалидации кэша.
b = Brand.objects.get(slug='slug_key')
redis 127.0.0.1:6379[2]> smembers "schemes:catalog.brand"
redis 127.0.0.1:6379[2]> smembers "schemes:catalog.brand"
(empty list or set)
Хотя в кэше они есть:
redis 127.0.0.1:6379[2]> keys brand
Что можно сделать, чтобы запросы по slug=*** проходили инвалидацию?
The text was updated successfully, but these errors were encountered: