riak

[Кирилл]

Надеюсь, здесь найдутся специалисты по риаку.

Используем риак в продакшне. Движок хранения - bitcask. Версия 1.3.1. В хранилище лежит несколько миллионов объектов. По сценарию работы в один момент времени меняется лишь маленькое их число (в течение пяти минут может измениться около 50 тысяч объектов, причем по несколько раз).

В один момент времени наткнулись на то, что риак стал периодически подвисать ненадолго и в этот момент все запросы, которые к нему шли, так же подвисали. Соответственно у некоторых клиентов наблюдалось выполнение запросов до 15 секунд, хотя до этого в среднем было 5-10 мс. Что самое характерное, ни процессор, ни диск, ни память не были загружены, а пул подключений к риаку был практически пустым. Наблюдались только небольшие скачки в потреблении памяти риаком.

Почитали документацию и снизили frag_merge_trigger и frag_threshold вдвое. Подождали минут 5 пока смерджится и запустили приложение. Все стало работать как часы, но через некоторое время ситуация повторилась (хотя нагрузка не менялась кардинально). В итоге сейчас frag_merge_trigger и frag_threshold снижены до 5%, однако изредка наблюдаются эти самые "подвисания" риака, из-за чего у некоторых клиентов наблюдаются задержки. 

Прошу подсказать, что с этим можно сделать и как это правильно оттюнить.

[Valentin Nechayev]

2013/9/23 Кирилл <evilblu...@gmail.com>

Надеюсь, здесь найдутся специалисты по риаку.

Используем риак в продакшне. Движок хранения - bitcask. Версия 1.3.1. В

Bitcask слишком непредсказуемый, у нас с ним намучились и так и не смогли организовать стабильность в работе.

Лучше уж LevelDB попробовать.

Или вообще свой backend, это достаточно дёшево (там плагинная система)...

 

[Alexander Alexeev]

Я бы попробовал подрубиться Observer'ом и попытался понять, что
происходит во время подвисаний. Также можно заготовить несколько
скриптов, проверяющий число процессов, длины очередей и так далее и
вбить их в remsh, когда riak начнет тупить.

> --
> Вы получили это сообщение, поскольку подписаны на группу Erlang
> по-русски.
>
> Чтобы отказаться от подписки на эту группу и перестать получать из
> нее сообщения, отправьте электронное письмо на адрес
> erlang-russia...@googlegroups.com. Чтобы добавлять
> сообщения в эту группу, отправьте письмо по адресу
> erlang-...@googlegroups.com. Настройки подписки и доставки писем:
> https://groups.google.com/groups/opt_out.


--
Best regards,
Alexander Alexeev
http://eax.me/

[Кирилл]

Переводить кластер на LevelDB слишком геморно и не лишено риска. Как я понимаю, надо вырубать ноды по одной, менять бекенд, подрубать и ждать, пока рассосется. Но как вариант - можно рассмотреть.

Свой бекенд - это какой-то NIH.

понедельник, 23 сентября 2013 г., 12:57:38 UTC+4 пользователь Valentin Nechayev написал:

[Кирилл]

Первичное гугление как пользоваться observer'ом ничего не нашло. Не могли бы вы кинуть ссылку на документацию или что-то подобное.

На какие вещи следует обратить внимание при работе через remsh, я внутрях риака никогда не ковырялся.

понедельник, 23 сентября 2013 г., 12:58:12 UTC+4 пользователь Alexander Alexeev написал:

[Кирилл]

  По поводу observer'а запрос снят. Мне почему-то показалось, что это какая-то чисто риаковская тулза.

понедельник, 23 сентября 2013 г., 15:20:02 UTC+4 пользователь Кирилл написал:

[Alexey Kishkin]

понедельник, 23 сентября 2013 г., 12:37:09 UTC+4 пользователь Кирилл написал:

Почитали документацию и снизили frag_merge_trigger и frag_threshold вдвое. Подождали минут 5 пока смерджится и запустили приложение. Все стало работать как часы, но через некоторое время ситуация повторилась (хотя нагрузка не менялась кардинально). В итоге сейчас frag_merge_trigger и frag_threshold снижены до 5%, однако изредка наблюдаются эти самые "подвисания" риака, из-за чего у некоторых клиентов наблюдаются задержки. 

Прошу подсказать, что с этим можно сделать и как это правильно оттюнить.

*Уменьшили* frag_merge_trigger?   По вашему описанию (если frag_ параметры влияют на ситуацию) - проблема связана с merge. То есть по идее надо сделать чтобы merge работал пореже. А вы сделали чтобы работал почаще.

У нас например frag_ параметры оба задраны до 80%. То есть пока в файле не образовалось 80 процентов пустого места, то merge и не начинается. Это позволяет делать merge реже и писать меньше данных (потому что надо будет переписать всего лишь 20% в новый файл)..

[Alexey Kishkin]

            {max_file_size, 16#80000000}, %% 2GB default

             {dead_bytes_merge_trigger, 1717985540},

             {dead_bytes_threshold, 1717985540},

             {frag_merge_trigger, 80},

             {frag_threshold, 80}

Вот так у нас

понедельник, 23 сентября 2013 г., 15:29:24 UTC+4 пользователь Alexey Kishkin написал:

[Кирилл]

Мы уменьшили значение триггеров, потому что так было сказано в документации:

Small number of frequently changed keys

When keys are changed frequently, fragmentation rapidly increases. To counteract this, one should lower the fragmentation trigger and threshold.

Тем более это нас на некоторое время (неделя-две) избавляло от проблем. А по вашему описанию должно было только прибавить.

понедельник, 23 сентября 2013 г., 15:29:24 UTC+4 пользователь Alexey Kishkin написал:

[Alexey Kishkin]

понедельник, 23 сентября 2013 г., 15:39:28 UTC+4 пользователь Кирилл написал:

Мы уменьшили значение триггеров, потому что так было сказано в документации:

Small number of frequently changed keys

When keys are changed frequently, fragmentation rapidly increases. To counteract this, one should lower the fragmentation trigger and threshold.

Правильно. Какой ценой? Ценой более частого merge

 

Тем более это нас на некоторое время (неделя-две) избавляло от проблем. А по вашему описанию должно было только прибавить.

дайте догадаюсь, вы перезапустили riak когда поменяли эти параметры?

 

[Кирилл]

Естественно перезапустили. Думаете дело именно в перезапуске? 

Зачем тогда давать этот совет в официальной документации, если он неверен?

понедельник, 23 сентября 2013 г., 15:45:52 UTC+4 пользователь Alexey Kishkin написал:

[Alexey Kishkin]

понедельник, 23 сентября 2013 г., 16:03:03 UTC+4 пользователь Кирилл написал:

Естественно перезапустили. Думаете дело именно в перезапуске? 

Зачем тогда давать этот совет в официальной документации, если он неверен?

Совет верен. Вы его неправильно интерпретировали.

Давайте я попытаюсь  упрощенно объяснить ход событий.  У вас рабочая система с дефолтными настройками. Там (не помню точно) около 30% эти все frag_ параметры. Вы обновляете/удаляете постоянно что-то, и в файлах биткаска фрагментация, ну.. в среднем около 25 процентов. Равномерно. По всем файлам (на самом деле зависит от того как равномерно вы обновляете записи).  Периодически какой-нибудь файл залезает за 30% что приводит к его мержу и к вашим задержкам.

Затем вы понижаете frag_ параметры до 5%. Что происходит? Практически все файлы срабатывают на merge сразу после запуска -- в них же во  всех больше 5% фрагментация. (Это вот те 5 минут. Кстати -- завидую вам. У нас мерж может часами длиться). В результате вы получаете систему с почти монолитными данными -- большинство файлов биткаска без фрагментации.

Поэтому, пока фрагментация в них не достигла этих 5%  - вы живете без проблем. Это вот та неделя.  Потом фрагментация наросла до около 5%- и вы начинаете получать те же проблемы - периодически то один то другой файл заезжает за 5% и происходит мерж. И снова все возвращается в старое русло. Даже более жестко. Потому что при дефолтных настройках переписывается 70% данных из старого файла, то при новых - 95%.

[Кирилл]

Я вот не пойму еще такого факта, если поставить высокий порог, то merge будет реже и более суровый. Не вызовет ли это еще большего подвисания? Вы сами написали, что у вас merge может длиться часами. Или тут роль играет факт, что merge проводится именно над теми объектами, с которыми мы в данный момент работаем?

Мы пытались ставить merge window, однако на наших SSD места хватало часов на 8-10 работы, потом место заканчивалось.

понедельник, 23 сентября 2013 г., 16:39:15 UTC+4 пользователь Alexey Kishkin написал:

[Alexey Kishkin]

Если поставить высокий порог, merge будет мягкий. Потому что при нем копируется малый обьем данных. Но ценой рыхлого хранения данных.

То есть вот такая дилемма -- мягкий merge c большим расходом дискового пространства, или компактные данные с жестким merge..

По частоте -- частота merge зависит не от порога frag_, а от того как быстро растет фрагментация.  А фрагментация зависит от размера файлов и интенсивности обновлений.

То есть при одинаковом workload вы будете иметь ту же частоту merge (в устоявшемся режиме работы) при любых frag_ параметрах. Другое дело что если вы задерете frag_ параметры, то до первого merge у вас будет не неделя а месяца 4.  Такая вот передышка.

Ну а в вашем случае (то есть места хватит часов на 10, в ssd) я честно говоря не вижу вообще пространства для маневра.. Это патовая ситуация.Может правда попробовать leveldb

Кстати -- эти задержки могут быть не только от merge, но и какая то ssd специфика. Но тут я не имею опыта..

понедельник, 23 сентября 2013 г., 17:16:11 UTC+4 пользователь Кирилл написал:

[Daniil Churikov]

Я бы так не сказал, bitcask гораздо более зрелый бэкэнд чем leveldb.
Причин по которым может происходить такие подвисания могут быть разные (начиная от компакшен, гц и заканчивая антиэнтропией), и тыкать пальцем в небо меняя какие-то настройки авось
станет лучше это не выход. Советую начать с изучения косвенных признаков. Вопервых понять все ли ноды начинают тупить или только конкретная.
 Во вторых посмотреть на показания системы во время тупления, особенно интересует сетевая активность и дисковое io. Ну и логи конечно, наверняка там что-то интересное.

понедельник, 23 сентября 2013 г., 12:57:38 UTC+4 пользователь Valentin Nechayev написал:

2013/9/23 Кирилл <evilblu...@gmail.com>

[Dmitry Demeshchuk]

Главная проблема bitcask – все ключи должны умещаться в память. Плюс, основное его "хорошее" отличие от leveldb – expiration time – до сих пор в некоторых случаях не работает, и парни что-то не торопятся его починить.

Переезд на leveldb у нас занял порядка дня или около того – просто путем обычного rolling upgrade, с удалением и добавлением ноды. Уже больше года сидим на нем, и довольны, за все время была только одна проблема, и то по моей глупости.

И вообще, это реально очень похоже на долгий compaction. Можно, кстати, довольно просто проверить. В начале подвисания сделать snapshot файловой системы (точнее – просто папки data/) на каждой машине, а потом сравнить с тем, что стало после окончания подвисания.

[Кирилл]

Памяти у нас куча, там не только ключи, но и полбазы влезет. Expiration не используем, поскольку данные все permanent. 

Сколько у вас нод было, которые вы перевели на leveldb?

четверг, 26 сентября 2013 г., 2:19:57 UTC+4 пользователь Dmitry Demeshchuk написал:

[Кирилл]

Ни сеть ни диск не нагружены вовсе, процессор также риаком не нагружен. Периодически риак просто начинает потреблять чуть больше памяти, график мунина становится похож на забор. Когда совсем тупит - потребление памяти вырастает раза в 2 ненадолго. Когда все нормально - график памяти - практически прямая. По логам очень много сообщений merge, где-то раз в 5 секунд, но они по полсекунды. Больше в логах ничего нет.

Если 

среда, 25 сентября 2013 г., 9:07:05 UTC+4 пользователь Daniil Churikov написал:

[Daniil Churikov]

Похоже действительно на compaction.

Какое значение max_file_size у вас в app.config`е? Большие значения здесь означают что мердж данных будет происходить редко но метко.
Так же есть merge_window опция, можно выставить что бы мердж происходил в часы наименьшей нагрузки.

В общем убедитесь что эти подвисания вызваны именно мерджем. И проийдитесь по всему руководству о тюнинге биткаска. http://docs.basho.com/riak/latest/ops/advanced/backends/bitcask/


пятница, 27 сентября 2013 г., 2:26:23 UTC+4 пользователь Кирилл написал:

[Dmitry Demeshchuk]

Немного – 8 штук.

[Кирилл]

max_file_size дефолтовый, 2 гига.

merge_window есть смысл выставлять только на ночь, когда нагрузка невелика, но я уже писал, что наши ssd (160gb) забиваются часов за 10. грубо говоря, до merge дело даже не дойдет)

пятница, 27 сентября 2013 г., 12:05:08 UTC+4 пользователь Daniil Churikov написал: