и уже 43, а не 200.

Ага

особенно учитывая что народ в основном rados пользуется

а если посчитать только RADOS + rbd + ceph - то внезапно всего 20.

выглядит не страшно

вы-бы стали использовать ceph?

вы-бы стали использовать ceph?

Звучит как "хотите поговорить о библии?"

и уже 43, а не 200.

Инженеры redhat работают. Вон даже glusterfs в божеский вид привели.

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

то что у нас сейчас весьма похоже на ceph, толькосильно проще

то что у нас сейчас весьма похоже на ceph, толькосильно проще

пейперов нет?

https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pocket/ вот максимум что нашёл в паблике

Инженеры redhat работают. Вон даже glusterfs в божеский вид привели.

Ну не знаю. Гластер очень своеобразный

https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pocket/ вот максимум что нашёл в паблике

спасибо.

У дропбокса там такоооое

С раст демонами чекающими файлики )

У нас примерно тоже самое тока раз в 20 меньше и медленнее ))

Ну у нас уже и сами OSD на расте

И на питоне )))

Да не, я шучу, там инженерная мысль работала

(Там народ посчитал что все баги которые нашлись за эксплуатацию старого Го демона могли бы быть найдены тупо компилятором)

(Да и память на много дисковых машинах начала кончаться)

А есть кто из фейсбука кстати?)

Они нам платежи не хотят платить, а саппорта у них нет

Молчат

(Да и память на много дисковых машинах начала кончаться)

кстати в Го 1.9 в очередной раз потюнили поведение рантайма и стало чуточку проще жить

вот это на canary box'ике 1.9б1

да, память по-лучше выглядит

господа а netns иерархичен ?

Инженеры redhat работают. Вон даже glusterfs в божеский вид привели.

а со скоростью там сделали лучше? А то я со времен 3.2 его перестал трогать и было тогда там печально

А монитор чего это?

А монитор чего это?

Наш графит

ребята, возник вопрос на который я пока не могу ответить у меня есть требования к криптопро, версия ОС такая то, версия ядра такая то Теперь вопрос, как мне зафиксировать допустим все пакеты на уровне debian 8.0 чтобы ни один пакет не обновился, только добавлялись при необходимости новые

apt-mark hold ?

холдинг

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

Так покрасивше, наверное: Another way to block updates of a specific package is to add its entry in /etc/apt/preferences or /etc/apt/preferences.d/official-package-repositories.pref file. This file holds responsibility of updating or blocking certain package updates according to priority specified by the user. To block the package, you just need to enter its name, additional feature, and to what priority you want to take it to. Here, priority < 1 would block the package.

мерси

Добрый вечер. В продолжении нашей эпопеи выбора message bus мы решили померить pdezwart/php-amqp (PHP расширение написанное на C) и php-amqplib/php-amqplib (PHP библиотека написанная на PHP)

Это паблишинг сообщения длинной в 1024 byte

RabbitMq кластер с 3 нодами + HA mode ON

время в миллисекундах

после каждого прогона тестов я очишал очередь

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

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

так берешь и профилируешь расширение и смотришь что у тебя в нем тормозит больше всего

и сними промежуточные размеры - для 100 сообщений например

и посмотри как там время растет

Да вот решил спросить у кого нибудь еще, чтоб понять профилировать или нет

такое ощущение что время паблишинга растет просто быстрее

В таблице время публикации?

да

и прошу прощения за опечатки, там не 1000 а 10000

в обеих колонках

Вы говорите - ваш юзкейс - 1 сообщение. Данные через пхп в кролик кидаете?

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

недели три уже :(

ничего не устраивает

Тут есть подводный камень с таким подходом

критерии отбора, в студию

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

и на нагрузке еще крешится

один сбой за полтора года, ровно в момент пиковой нагрузки

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

Такое себе замечание, тормозной - это какие цифры?

ERROR: S client not available

10-15kmsg/s

Поверьте, это очень мало для геораспределенных систем.

Верю, а что в замен?

я предлагал но до тестов не дошло

Схожее по функционалу

так что ничего пока

был бы пилот альтернатив - рассказал чо да как

ну 1. персистентные сообщения в очереди 2. кластеризация 3. возможность спокойно набрасывать в очередь не думая подписан на нее кто-то или нет (у nats.io этого нет) 4. поддержка клинтов другими языками (php, java, nodejs, python) 5. быстрый паблишинг (важнее чем подписка)

кажется это самое основное

у кроля через эксченджи отличная скорость паблишинга, а если учесть, что паблишеры обычно размыты, то все вполне разумно

он на пиковой нагрузке паблишингу отдает приоритет

Stanislav кстати, сегодня тестировал (правда, на дефолтной установке из homebrew) - по сравнению с sidekiq скорость ниже =/

сайдкик сколько показал? Я слышал он быстр

ну у меня rabbit выдавал что-то в районе 15k rps на паблиш, а sidekiq - в районе 50k rps

но что у сайдкика с надежностью и масштабируемостью? А то отличных решений для локалхоста я знаю немало

цифры примерные, но порядок такой

ну, sidekiq в этом проигрывает, поэтому и смотрим на rabbit )

на бинстолке можно и 1М взять, толку правда никакого при задаче фейловера и масштабирования

вон, натс пишут 1М может

а толку

да, согласен, масштабируемость - всегда влияет на скорость

редис тоже 1М позволяет взять, но опять же, кейс локалхоста как у бинстолка (вру, оба могут в сингл-мастер и мультислейв - но нам это не поможет)

у нас еще юзкейс такой, нам важен не объем в секунду, а то, как быстро мы сможем опубликовать одно сообщение в стеке вызова. ну два.

вообще, интересно еще протестировать разницу в скорости отправки многих маленьких сообщений и нескольких больших через rabbit

мы тестировали

если интересно могу порыться

и что выгоднее? )

но если серьезно, мы гребем с редисов и рэббитов в сторону кафки и аэроспайка

большие

аероспайк хорош но там тоже не все гладко