?

Log in

No account? Create an account
Предупреждение
404
amarao_san

99+. Данное произведение предназначено для читателей старше 99 лет. Если вам нет 99 лет, вы не имеете права читать это произведение согласно Федеральному закону № 139-ФЗ от 28 июля 2012 года "О защите детей от информации, причиняющей вред их здоровью и развитию"


Данный журнал является литературным произведением и освещает вымышленные события в вымышленной стране. Все совпадения имён, фамилий, дат, цифр и прочей информации с реально существующими объектами и людьми являются случайными.

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

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

Предупреждение о возможном оскорблении чувств верующих, чувств сторонников прав животных, чувств животных и прочих. Вас предупредили.

Данное сообщение размещено 15 октября 2008 года. Сообщению присвоена дата 31 декабря 2037 года для технических нужд. Предупреждение действует как для записей, датированных сроком после 15 октября 2008 так и для размещённых ранее. Сообщение обновляется по мере того, как гсударственная дура придумывает новые правила.

Посещаемость данного ресурса составляет 0.042 человека в сутки*

*Согласно методологии измерения института Автономного Ядерного Технологического им. Ролля среди читателей, которые имеют право читать этот ресурс согласно возрастных ограничений

Guestbook
404
amarao_san
Комментарии и вопросы оставлять тут.

iops'ов не существует
404
amarao_san
Есть только latency и параметры бенчмарка (iodepth/blocksize). IOPS - это производная величина IOPS=(1/latency)*iodepth. bandwidth=(1/latency)*iodepth*blocksize.

Таким образом, iops'ы - это параметр мониторинга (устройство в настоящий момент обслуживает N операций в секунду), но не показатель производительности. Для результатов конкретного замера достаточно знать latency.

При этом latency не имеет нормального распределения (я недавно постил картинки), так что её нельзя описывать одним-двумя параметрами. При этом кривая распределения вероятности latency (или, по-бытовому - "сортированная выборка из журнала latency всех операций") очевидно зависит от параметров бенчмарка (как минимум, blocksize, iodepth, паттерн рандомизации IO, span (отношение области тестирования к ёмкости устройства), и время теста.

Последнее крайне любопытно (влияение времени теста на результат) и говорит нам о переменной системной погрешности измерений, хотя на самом деле это просто исчерпание запасов у leveling'а SSD'ей.

Вот одна и та же плохая SSD под 90 секундной и 900 секундной нагрузкой:

90 seconds VS 900 seconds of benchmark

Она настолько различается, что KS-тест отвергает null-hypothesis (что это одно и то же), т.к. D>crit:

D = 0.0754, p-value < 2.2e-16
crit 0.02145362 (α=0.01)

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

Выводы? Всё сложно.
Tags:

Продолжение истории с WB/WT для LSI
404
amarao_san
Если кто-то упустил драму про writeback/writetrhough у LSI, то пересказываю в кратце:

Есть утверждение от документации LSI, которое говорит, что разница в WB/WT состоит в том, когда отправляется подтверждение о записи: когда данные попали в кеш или когда данные были приняты нижележащими устройствами, из чего можно сделать вывод, что WT никак не может быть быстрее. (WB=writeback, WT=writethrough). См этот комментарий для подробностей: https://amarao-san.livejournal.com/3436627.html?thread=21645139#t21645139

И есть экспериментальные данные, которые показывают, что на быстрых SSD отключение WB и режима Cached (перевод в Direct) увеличивает производительность. В моём бенчмарке более чем в два раза.

Вот на этом графике можно понять, что на самом деле происходит при переключении между WB и WT. Sample1=WB (розовый), Sample2=WT (зелёный). Это график latency запросов, точнее, плотность вероятности, даунсэмплинг до 2000 запросов. Шкала X - log2.

WB/WT chart
Видно, что первый пик у "розового" там же, где основной пик у зелёного. А дальше тупняк от WB, у которого забился кеш. Я утверждаю, что WT обеспечивает лучшую производительность именно из-за отсутствия этих "тупняков".
Tags:

Это победа
404
amarao_san

Средние различаются в 4(!) раза, а тест говорит "одно и то же".

D = 0.13, p-value = 0.3667, crit=0.2145362

Мне осталось выяснить, можно ли считать утверждение "нельзя исключать нулевую гипотезу" эквивалентным "они равны". И это так, потому что это одинаковые диски в одинаковых серверах. (Одинаковые модели, но разные экземпляры).

Алсо, сэмплинг рулит. Если что,
shell: "shuf -n 100 lat_clat.1.log|awk '{print $2}'|awk -F, '{print $1}'"

А ты купи слона
404
amarao_san
Используйте нормальное распределение чтобы сказать что-то умное:



PS https://medium.com/opsops/struggling-with-statistics-part-2-aa6ee6c8687b

пишу из серверной
404
amarao_san
У меня забрали паспорт и принуждают к R.

метрология
404
amarao_san
Только я погрузился в нежные объятия p-value и других благородных вещей, как прилетело сбоку грубое и материальное: LSI'ки в режиме RAID1 и WT/Direct игнорируют fsync'и. Просто берут и игнорируют. Иначе я не могу объяснить 20к fsync'ed IOPS у железки, которая с отключенным дисковым кешем (не путать с кешем контроллера) выдаёт 49 IOPS.

Статистика
404
amarao_san
Если мне нужно прям бегом изучить статистику до уровня, когда я могу для real-life измерений сказать какова вероятность ошибки в ответе "совпадают или нет" величины, с чего мне начать и куда читать? Условный уровень знаний: понахватано по верхам, уверенного нет ни в теорвере, ни в статистике.

анти-баш
404
amarao_san
А знаете, за что баш ещё так сильно не любим?
Баш часто используется в качестве затычки последней надежды в месте, где не удалось предусмотреть нормального скриптования. С упором на оба слова - "нормальное" и "скриптование". Иногда скриптование есть, но такое, что проще баш. Иногда его нет, и можно подвоткнуть чуть-чуть баша (например, в ssh_config).

Это приводит к ситуации, когда input/output интерфейсы определены очень плохо, часто не готовятся должным образом, а даже если готовятся, то получить вменяемую документацию очень сложно (переменные эспортируются модулями и т.д., где у какого модуля что экспортируется - чёрт его знает). То же и с output - кто там что куда читает мы не знаем.

Ещё хуже в таких ситуациях обстоит процесс отладки, часто сводящийся к "запускать с echo пока не получишь нужное", причём, если bash нетривиальный, то отлаживать его в таком режиме становится почти невозможно. Никаких механизмов тестирования получившегося "glue" нет, и это возвращает нас в мир "devops с привкусом начала 90ых".

То есть 3/4 всех претензий к башу - не к башу, а к тому, как его готовят. Плохо готовят. Прям из рук вон плохо.
Tags: