Вышел RabbitMQ 3.0.0

В свое время трахался с Zero.. - такое же глюкалово было. хз как сейчас

for big projects MQSeries only !

Внезапно обнаружил, что сабж фиг как по-человечески забекапишь...

Кролик юзает мнезию :(

Мнезия? Звучит как «амнезия», это когда провалы в памяти. Что за мнезия, с чем её едят, чем это плохо, почему её нельзя использовать?

Мнезия?

http://en.wikipedia.org/wiki/Mnesia

Звучит как «амнезия», это когда провалы в памяти.

где-то слышал байку что изначально эту субд хотели назвать амнезия, но маркетологи решили что «амнезия» — плохое, негодное название для базы данных и выкинули первую букву из названия)

А зачем его бэкапить? оО

Насчет копии данных на каждый чих не совсем верно.

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

Не подскажешь, насколько «сильно жрут» память и диск? Прямо сейчас перевожу свой проект на RabbitMQ с хранимыми очередями и «ручным» подтверждением

Раббит жрёт пропорционально длине автогенерируемых ключей. Ключи там имеют длину порядка 15-20 байт (наверно! я точно не знаю). И плюс всякий RAM оверхед на индексы для мгновенного поиска. Ручное подтверждение особо не влияет на прожорливость, ибо память в эрланге вычищается не резко. Влияет именно длина очереди и характер её разгрузки. Для замера можешь загрузить 10000 элементов в очередь и прикинуть расходы RAM на более длинные очереди.

Я использовал раббит на задаче «очередь ссылок для одного кравлера», т.е. когда очередь растет резко и скачками, а потом мееедленно спадает. Уже не помню точных величин очередей, но там были десятки очередей с сотнями тысяч элементов. И раббит успешно лёг на отдельном сервере с 64 Гб RAM. Когда он лёг на такой RAM, его уже не поднять (см. далее).

Ещё одна проблема с длинными очередями - у раббита многое храниться в мнезии. А мнезия на диске - это dets (file-based kv-хранилище). А жирные файлы dets означают, что после перезапуска кролика будешь долго ждать, пока эрланг прочитает все файлы dets и выстроит ключи мнезии в RAM (а это реально медленный процесс на базе от 1-2Гб). Т.е. если упадет от жирности, то уже не поднимешь - банально не дождёшься или он грохнется снова на пол-пути.

Ещё проблема с длинными очередями в rabbit - нет возможности прозрачно проводить операции над очередью. Т.е. например хочу вызвать какую-то фильтрацию всей очереди с помощью эрланговской функции. Или ещё что-нибудь совершить. Нужно извлечь из очереди каждый элемент и потом закачивать назад. Но это не страшно, просто хотелось бы чуть большей гибкости.

В раббите вообще нет возможности добавлять в начало очереди. Бывает, что есть элемент, который нужно обработать ASAP и нет времени ждать ещё 10к элементов. Для такой приоритезации надо поднимать две очереди (например: «my_queue.1», «my_queue.2»), и AMQP-клиенты будут поочередно опрашивать две очереди: сначала почти всегда пустую my_queue.1 и почти всегда полную «my_queue.2». Это неудобно, напряжно, лишние такты cpu, лишний траффик, лишний код и т.д.

НЕ советую использовать раббит именно как менеджер очередей. Это брокер сообщений, который может поддерживать гарантию и очередность доставки. Если ожидается длинная очередь, которая будет расти в будущем, то могу посоветовать группировать по 200-300 элементов в сегмент, сегмент сжимать в gzip и сохранять в нумерованный файл на диске :D

ymn *** (22.11.2012 15:12:19)

Действительно, очень забавная байка. :-)

Ты наверняка умный (судя по нику), поэтому расскажи, пожалуйста, тем кто в танке, почему предыдущий оратор в треде поставил грустный смайлик после мнезии, что в ней не так? Стоит ли на неё переходить, например, с MySQL? Сильно ли придётся переделывать SQL-запросы? Есть ли поддержка PHP? Заранее спасибо. С уважением.

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

поставил грустный смайлик после мнезии, что в ней не так?

Если положить весь кластер, то для активации таблиц нужно включить все ноды, чтоб они договорились между собой.
Полнотекстового поиска в ней нет и не будет никогда. Поисковые функции, свойственные sql-базам, сильно ограничены.
Большие таблицы (> 500 Mb) ощутимо долго включаются после остановки ноды.

Сильно ли придётся переделывать SQL-запросы?

Придется их не использовать. Есть чтение по ключу, чтение из вторичного индекса, произвольный матчинг всех рядов таблицы. Всё это - эрланговские функции.

Есть ли поддержка PHP?

Можно написать, но не нужно. Проект работает - не трогай.

Ну я хотел много тасков планировать на будущее (интервал в месяц) через celery, получается, что если rabbit утратит данные, все эти таски потеряются. Т.е. получается, что celery для этого не годен, и придётся их хранить в базе и чекать таки по крону.

Это было написано в книге Армстронга про erlang, так что, похоже, что это так и есть.

Благодарю за ликбез. Теперь мне всё более или менее ясно и понятно. Буду книжку читать по клёвому языку эрланге, может быть, получится использовать его вместе с апачем вместо PHP, а вместо MySQL будет мнезия. А вместо аськи будем общаться через RabbitMQ.

Имхо, сейчас лучше scala изучать. Это ведь джава. Библиотеки и программистов легче найти.

Наверное, всё-таки буду изучать эрланг, джаву как-то не очень хочется, тем более очень похожа на PHP, к которому я привык за 10 лет с ней работы. Вот, эрланг и хаскиль — совсем другое дело! Дуновение свежего ветерка (и новой парадигмы), так сказать. :-) Кстати, что лучше посоветуете для новичка? Чем лучше хаскиль, чем эрланг? А по быстроте они как между собой? Лёгкие процессы в хаскиле есть? А мнезия? Пока ничего не понятно, но заранее всем спасибо.

Не знаю ничего про хаскель, но мнезию очень затруднительно юзать откуда то вне ерланга. Она сама на ерланге и интерфейс предоставляет в виде ерланговских функций (довольно удобно, кстати).

Знатоки утверждают, что мнезия не выдерживает высокой нагрузке, лочится. Говорят, что из-за этого какой-то ёжик падает (это вроде сервер, который жаббер обслуживает, это что-то типа аськи и скальпа). Хотел узнать, насколько это вообще правда или нет. Может быть, и оставить всё как есть: апащ + пухапе + муську? Вроде всё работает и каши не просит.

боже, я разбил лицо.

боже, я разбил лицо.

Дико извеняюсь, если что-то вдруг не так. :-(

Кортежи более компактные, потому что кортеж внутри состоят из 2-х элементов: кол-во элементов и массив ссылок на элементы. Лист же на каждый элемент хранит 2 поля: ссылку на значение и ссылку на следующий элемент списка. Так что да, по памяти эффективнее.

Под связными списками я имею в виду листы.

Замерил потребление сейчас, к сожалению, пока только на 32битной системе:

Скриншот админки http://imgur.com/4vOyx ETS таблицы http://imgur.com/1JC5i Mnesia базы http://imgur.com/1RdoH

Судя по админке, на одну очередь с ~2.5Млн сообщений отъело 369MB. После того как из очереди ушло одно жирное сообщение и поработал GC, память утрамбовалась до 248Мб http://imgur.com/cg62j.

Payload одного сообщения около 370 bytes, значит сами данные занимают примерно echo $((367 * 2547966 / 1024 / 1024)) = 890Мб

Судя по lsof, он действительно хранит что-то в Mnesia:

beam.smp 2173 rabbitmq   13w   REG    8,2  5468732 542243 /var/lib/rabbitmq/mnesia/rabbit@seriy/msg_store_persistent/209.rdq
beam.smp 2173 rabbitmq   14u   REG    8,2        0 656031 /var/lib/rabbitmq/mnesia/rabbit@seriy/msg_store_transient/0.rdq
beam.smp 2173 rabbitmq   16u   REG    8,2        0 918526 /var/lib/rabbitmq/mnesia/rabbit@seriy/queues/6P86X5UKO59AMIL6Y5RW6TDB/journal.jif
.......
beam.smp 2173 rabbitmq   23u   REG    8,2        0 918135 /var/lib/rabbitmq/mnesia/rabbit@seriy/queues/1MEDA9CW01N84K5DY84QK47GU/journal.jif

При этом в /var/lib/rabbitmq/mnesia/rabbit@seriy/msg_store_persistent/ лежит 1.6Гб бинарных файлов. Видимо персистентное хранилище мнезии. Если отключить персистентное хранилище, то, очевидно, все эти 1.6Гб засядут в памяти.

Вот память эрланга

(rabbit@seriy)4> [{Type, Val / 1024 / 1024} || {Type, Val} <- erlang:memory()].
[{total,248.6694107055664},
 {processes,14.537589073181152},
 {processes_used,14.537569999694824},
 {system,234.13182163238525},
 {atom,0.546360969543457},
 {atom_used,0.5195302963256836},
 {binary,6.474479675292969},
 {code,9.65422248840332},
 {ets,215.02038192749023}]

Видно, что большую часть памяти занимает ETS. Заметьте: хранилище (по сути, индексы к дисковому хранилищу) занимает 215Мб, в то время как всё остальное (оверхед от использования эрланга по сути) 248 - 215 = 33Мб! Вот вам и «Эрланг отжирает память, кругом сплошное копирование, парниковый эффект»...

Интересное исследование. Спасибо.

ETS, DETS это его родные системные хранилища, а собственно мнезия это удобная обертка над ними с дополнительными плюшками.

33Мб оверхеда более чем терпимо))

Спасибо за развернутый ответ. То что оно не умеет страторвать быстро с большой очередью - это безусловно серьезный минус (которого не было с моим велосипедом). Поиграюсь предварительно еще на живых данных чтобы оценить прожорливость.

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

Ты говорил ты свой велосипед делал - ты его не на 0mq делал?