Pull to refresh

Comments 11

Насчёт "внезапно, они делают sync'и" — это частое открытие людей, которые делают "облака". Все бенчмарки инфраструктуры всегда надо делать в worst case scenario (randwrite 100%, fsync, на несколько часов (суток) прогрева).


А смотреть надо не только и не столько на iops'ы, сколько на tail latency. Я для себя всё ещё не могу решить, worst или какой-то персентиль, но однозначно не mean и не median. У ceph'а вообще с tail latency тяжело, а если к этому докинуть душераздирающие графики распределения latency для разных устройств (даже быстрых по average), то становится вообще тяжело.


Примеры разных устройств. Вендоров не назову, ибо ссориться не хочу.

На графике плотность вероятности получить какую-то latency при iodepth=1, и это я ещё длиннючий хвост обрезал. 1.5 — баг визуализации (raw данные давно выкинул).

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

У меня давно чешутся руки написать к blktrace сэмплированный логгер а-ля sflow. Который будет записывать каждую N операцию (то, что в blktrace видно) во внешний логгер по сети. Просто для того, чтобы иметь возможность реагировать на изменение профиля нагрузки без участия тикетницы.


… Интересная идея для нового маленького стартапчика. bflow?

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

Сэмплер поможет отлично, так же, как он помогает сетевикам. Никого не интересует конкретный запрос, всех интересует примерная картина. Так же как sflow с sample-rate в 16000 удивительно точно описывает что происходит в сети, ровно так же сэмплинг io позволит видеть картину нагрузки от клиентов без стресса на всех участников замеров.

Чем вас порадует сравнение двух конкретных моделей (которые я сейчас даже не назову)? У всех вендоров есть SSD разного класса и делать вывод о вендоре по результатам одного бенчмарка одной модели в прошлом году не очень разумно.

В большинстве случаев (не всегда) есть преемственность внутри линейки и архитектурных решений...


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

Собираю fio в sampled режиме, анализирую — с помощью какой-то матери, R и помощи коллег.

А как вы используете разные типы кластеров — глобальный и локальные? То есть в глобальном у вас хранятся диски ВМ которые не критичны к летенси и вы можете подключать их к ВМ в любом DC? А в локальных кластерах хранятся диски ВМ доступные только в этом DC?
Или у вас диски могут перемещаться из глобального кластера в локальный и наоборот?
Просто вы пишите, что глобальный кластер был плох и вы сделали локальные но не поясняете пользовательский сценарий работы при таком разделении кластеров.
Все диски ВМ доступны из всех ДЦ. Просто у тех которые лежат на локальных кластера лучше с временем обслуживания.
Only those users with full accounts are able to leave comments. Log in, please.