Comments
Несколько сумбурно показалось, но все равно здорово читать статьи, основанные на практике.
Спасибо.
Даже если детка не пишет в память, то copy on write происходит, если папа пишет — а папа обычно пишет будь здоров! Что на самом деле меняет overcommit_memory — лишь «умную» проверку, что детка может аллоцировать столько же памяти, сколько есть у папы. И всё. А так в своп загнать нагруженный редис как два пальца. См. соответсвущую секцию в faq redis.io/topics/faq («Background saving is failing with a fork() error under Linux even if I've a lot of free RAM!»)
Спасибо за информацию, я добавил в пост ссылку на FAQ.

Даже если папа очень интенсивно пишет, то всё упирается в скорость записи данных на диск. Теория такова, что пока детка пишет на диск, папа может изменить все ключи, но на практике детка всё-таки успевает всё быстренько записать и рост используемой памяти за это время минимальный. Зависит от объёмов данных и количества частоизменяемых ключей, конечно. У нас в настоящий момент Redis использует 3Gb и пишет это всё на диск (попутно сжимая) секунд за 30 (EC2 moderate IO performance).
Спасибо информацию. мы уже год или больше используем Redis в продакшин системе на debian/Ec2 в количестве около 10 серверов (с репликациями и т.п.) Очень довольные
Жаль, думал увидеть практический опыт использования редиса в продакшене (удобства, подводные камни), а не выдержку из мана :(
А всё-таки, расскажите пожалуйста какие такие недостатки режима AOF вынудили вас склонится в пользу RDB? Спасибо!
из aof слишком долго поднимается. особенно, если у вас в редисе пара zset, поднятый инстанс 1-2гб и aof файл на 5гб. из rdb при этом поднимется со скоростью чтения с диска файла в 600мб
Таких недостатков для себя не нашёл, просто нет в этом необходимости, достаточно RDB.
В моем случае данные не так критичны, если пропадут на несколько последних часов и поэтому использую RDB, что бы не гонять диск постоянно — на ВДС за это ругаются когда на него большая нагрузка.
Есть ли сейчас какая-то возможность сделать простой master-master? Хотя бы его эмуляцию с автоматическим перебрасыванием ролей. Потеря части последних данных не критична, а вот сихронизация автоматом после того как первый из серверов упал очень нужна.
А как вы храните фиды в redis? Допустим, если необходимо показывать объединенный фид нескольких или всех пользователей сразу?
Фиды у нас хранятся в виде Sorted Sets для каждого пользователя, в которых зачениями выступают названия других ключей, которые являются Set. Это делается для группировки однотипных событий. Необходимости показывать объединённые фиды пока не возникало, но я думаю, что можно попробовать использовать ZUNIONSTORE.
Понятно, что ZUNIONSTORE, но если фидов десятки тысяч, то получающийся Set будет огромным. По меньшей мере, если показывать фиды всех пользователей. На этом я немного застрял, думаю сейчас попробовать какой-нибудь другой инструмент, возможно даже отдельную базу SQL.
Если нужен именно глобальный фид, то я бы предложил использовать отдельный Sorted Set, в который автоматически будут добавляться активити всех юзеров при создании. Дело в том, что значениями в Sorted Set выступают названия Set-ов, которые уникальны для каждой активити и не дублируются. То есть, если один юзер создаёт активити, то в фиды всех подписчиков добавляется ссылка на один и тот же Set.
Понятно, что ZUNIONSTORE, но если фидов десятки тысяч, то получающийся Set будет огромным. По меньшей мере, если показывать фиды всех пользователей. На этом я немного застрял, думаю сейчас попробовать какой-нибудь другой инструмент, возможно даже отдельную базу SQL.
Может уже позновато — какая у вас нагрузка на Редис и время ответа?
Only those users with full accounts are able to leave comments. Log in, please.