Измеряем производительность «облачных» дисков — спасаем MySQL

    В последнее время в облачных средах и хостингах все чаще стали попадаться «виртуальные» жесткие диски. Техническая служба хостера может заверять, что «виртуальный» диск — быстрый, как десяток рейдов 10 (рейд 100 ;-) ) и держит сотни, а то и тысячи IOPS – однако MySQL заметно для клиентов тормозит. А как это доказать хостеру?

    Проблема в том, что измерить «скорость» виртуального жесткого диска изнутри виртуальной машины – непросто, т.к. неясно, что мерить в первую очередь, чем и зачем. А сделать это нужно, чтобы убедить администраторов виртуальной конфигурации, что дело не в приложении и настройках MySQL. И нужно было, как говориться, просто «помыть руки» перед чтением мануала к хранилищу.

    В статье я проиллюстрирую простую методику нахождения «точки опрокидывания» производительности виртуального жесткого диска, с использованием доступных в дистрибутивах инструментов – sysbench и iostat. Также мы измерим «точку опрокидывания» известных своей тормознутостью виртуальных дисков EBS от Амазона – как обычных EBS, так и Provisioned IOPS EBS (1000 и 2000 IOPS).

    Теория


    К черту! Слишком много измерений и букв – последовательное чтение/запись, произвольное чтение/запись, перезаписи, влияние файлового кэша ядра, оптимизация очереди запросов, варианты опций и архитектуры файловой системы… Мы поступим проще – сэмулируем многопоточную нагрузку на виртуальный диск, подобную создаваемой сервером MySQL и посмотрим, как диску, или что за ним в сети скрывается, дышится.

    А чтобы не было скучно, добавим к gnu.org немного романтики :-)



    Как MySQL нагружает диск


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

    Периодически buffer pool из оперативной памяти будет сбрасываться на диск – произвольная запись. Сразу исключаем отсутствие кэша записи и «батарейки» в виртуальном хранилище – оно должно быть, иначе MySQL в режиме ACID (innodb-flush-log-at-trx-commit=1) просто умрет от сожаления.

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

    Создаем нагрузку


    Начнем с простого EBS-диска амазона. Нагружать виртуальный диск будем инструментом sysbench (в CentOS он доступен в пакетах, собрать из исходников несложно):
    yum install sysbench
    mkdir -p /mount/disk_ebs/mysql/test_folder
    cd /mount/disk_ebs/mysql/test_folder
    sysbench --test=fileio --file-total-size=16G prepare
    

    Важный момент – создаем суммарный объем тестовых файлов (16G), превышающий как минимум в 2 раза объем оперативной памяти виртуальной машины (не спрашивайте, почему в 2 раза ;-), чем больше — тем лучше). Это нужно для уменьшения влияния файлового кэша операционной системы – при повторном запуске тестовые файлы лучше, поэтому, перегенерить заново (либо создать несколько тестовых папок и переключаться между ними).

    Теперь создаем нагрузку в N потоков, эмулируя ~N клиентов сервера СУБД, выполняющих запросы (да я знаю, что внутри СУБД есть несколько служебных потоков, но не будем пока усложнять). Допустим, ожидается, что с БД будут одновременно работать 10 апачей:
    sysbench --num-threads=10 --test=fileio --file-test-mode=rndrw --max-time=180 --file-rw-ratio='2' --file-total-size=16G --max-requests=1000000 run
    


    Что измеряем?


    Теперь самое интересное. Нам не интересно, какие результаты покажет sysbench – он нам только нагрузку создает. Мы лишь смотрим, как чувствует себя виртуальный диск под нагрузкой:
    iostat –xm 10
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    
    xvdm              0.00     0.00  120.50    0.00     2.05     0.00    34.79    10.50   87.47   8.30 100.00
    

    Диск «завален» запросами большую часть процессорного времени, что видно по «%util = 100» — драйвер диска накапливает запросы в очередь и по мере готовности устройства «скармливает» их (некоторые путают этот показатель с пропускной способностью шины к диску, что, конечно, неверно). Тут ясно, если драйвер вынужден ждать почти все время, то диск – загружен под завязку.

    Среднее время обработки одного запроса «svctm» — 8.3 ms. Многовато, но нормально для дисков Амазона. Тут нет ничего криминального – обычная физика.

    Среднее время ожидания обработки одного запроса «await» — 87.47 ms и средняя длина очереди запросов в драйвере диска «avgqu-sz» – 10.5. Это много, ждать почти 100 ms для обработки одного запроса! Очевидно, как получается эта величина – грубо размер очереди (avgqu-sz) умножается на время обработки одного запроса (svctm).

    Итак, мы видим, что всего 10 конкурентных запросов на произвольное чтение/запись (ключи --file-test-mode=rndrw и --file-rw-ratio='2') приводят замедлению работы с виртуальным жестким диском.

    Да так, что приходится ждать один запрос почти 100 ms. А если веб-страница создает 200 запросов к диску – сколько времени она будет строиться? 20 секунд?

    Интересно, а при каком числе потоков диск Амазона не начинает накапливать очередь и обслуживает запросы быстрее хотя бы 50 ms (лучше вообще меньше 20 ms — субъективно)? Видим, что при 5 потоках. Конечно, это слабый показатель, без софтварного рейда не обойтись …
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    
    xvdm              0.00     0.00  127.50    0.00     2.05     0.00    32.88     5.10   39.78   7.84 100.00
    

    Видим, что размер очереди – 5.1 и время выполнения одного запроса – 39.78.

    Тестируем «быстрые» виртуальные диски Амазона


    Относительно недавно Амазон анонсировал «быстрые» диски с гарантированным числом IOPS (теория IOPS – обширна, как наша страна, погуглите, en.wikipedia.org/wiki/IOPS). Мы знаем, что простые смертные SATA-диски не держат более 100 IOPS (одновременное чтение и запись), а, к сожалению, также смертные 15k SAS-диски – не более ~200 IOPS. Также известно, что SSD-диски и SAN на других технологиях могут осилить сотни, и даже тысячи IOPS – понятно, что они значительно дороже.

    Итак, посмотрим, на каком числе одновременных потоков «быстрые» виртуальные диски Амазона начинают тупить и собирать запросы в очередь. Сломаем козе левую ногу!


    Диск EBS с 1000 IOPS

    Один поток:
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    
    xvdk              0.00     0.00 1084.50    0.00    27.33     0.00    51.61     3.72    3.43   0.91  99.20
    

    Обратите внимание на маленькое время обработки запроса самим виртуальным диском – 0.91 ms. Видимо массив на SSD ;-) Размер очереди ~4, а среднее время одного запроса – 3.43 ms.

    20 потоков:
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    
    xvdk              0.00     0.00 1059.50    0.00    26.37     0.00    50.98    55.39   51.97   0.94 100.00
    

    Видим, что при 20 потоках запрос придется ждать ~50 ms из-за образования очереди в 55 запросов.

    Диск EBS с 2000 IOPS

    20 потоков:
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    
    xvdl              0.00     0.00 1542.50    0.00    36.29     0.00    48.18    33.20   21.29   0.65 100.00
    


    50 потоков:
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    
    xvdl              0.00     0.00 1498.50    0.00    36.63     0.00    50.06    86.17   57.05   0.67 100.00
    


    Итоги измерений


    Видим, что EBS-диск с 2000 IOPS показывает примерно такую же latency (~50ms) на 50 потоках, как диск с 1000 IOPS на 20 потоках и обычный EBS диск на 6-7 потоках (видимо у обычных EBS дисков IOPS находится в пределах 200-300).

    Что еще случается


    Виртуальные жесткие диски нередко дарят сюрпризы. Иногда их просто недонастроили, т.к. не успели дочитать man…

    Недавно столкнулся с подобным кейсом, когда при создании многопоточной тестовой нагрузки на пустом MySQL сервере у «большого-дорогого-быстрого-сетевого» виртуального диска скакал показатель svctm от 0.5 до 1 ms в ночное время и от ~10 до 100 ms – в дневное (хотел померить в полнолуние, не дождался). MySQL разумеется – тормозил. Причина была в параллельно использующих сетевое хранилище и незнающих друг о друге проектах, а не настройках MySQL, который пытались сделать виноватым ;-)

    Резюме


    Используя подручные инструменты, мы довольно быстро определили предел конкурентной многопоточной нагрузки, при котором виртуальный диск начинает накапливать очередь и обслуживать довольно типичные для MySQL запросы за 50 ms и более. Теперь можно предположить, сколько дисков собрать в рейд, чтобы обеспечить latency, допустим, в 10-20 ms при заданном числе клиентов. Понятно, что это приблизительные данные, но они, безусловно, помогут двинуться дальше, особенно если измерить производительность настоящего жесткого диска/рейда и прийти с этими сравнительными данными и бутылкой шампанского к облачному хостеру;-)

    В заключение, поздравляю всех с прошедшим праздником, желаю быстрых виртуальных дисков, надежных серверов и точных измерений! Заходите к нам на Битрикс24. Удачи!
    1С-Битрикс
    57.66
    Company
    Share post

    Comments 63

      +2
      Я вот думаю, а как можно помочь хостеру лучше предоставлять нам виртуальные диски?.. Положим, предложить резервировать полосу до дисков, или что-нибудь в этом роде. Или же пока тупо архитектурно выносить disk-intensive MySQL на выделенный железный сервер?
        +2
        Или, положим, резервировать приоритетное обслуживание запросов (очередь с приоритетами), чтобы гарантировать себе предсказуемый latency.
          +8
          В условиях СХД не возможно сделать очередь с запросами. Причина — СХД одна, хостов много, и на каждом хосте много виртуалок.

          Правильно это решается с помощью SLA. Мол, гарантируем обслуживание не менее 1000 запросов с размером блока 2k при latency не более 15мс с 99 персентилем (то есть не менее 99% запросов в количестве менее 1000 шт/с будут обслужены за время менее 15мс).

          Другой вопрос — как это мониторить… Я знаю только активные тесты, то есть запуск fio или IOMeter.

          Наверное, было бы здорово разработать систему мониторинга SLA для дисковых операций. Всяко лучше, чем шаманство с sysbench'ем.
            0
            Да, примерно такой SLA я и имел в виду.
              0
              Придумаете такого рода мониторинг (не активный — дороговато будет, а, например, статистикой по устройству) — с радостью примем в продакт и пропишем в SLA.
                0
                чтобы такое реализовать нужно иметь патч к ядру конкретной ОС — тогда замеры производительность будет что называется из первых рук. Но это естественно не все так просто…
                  +1
                  главное — не замониторить систему вусмерть.
                    0
                    с чего Вы так решили?
                  +1
                  А мы же как системные администраторы все и измеряем сбоку:

                  1) stolen для CPU — видим, сколько ресурсов отобрала у нас система виртуализации и передала другим машинам
                  2) сбоку смотрим на vmstat/ps, чтобы понять, кто завис в ожидании ввода вывода на диске в статусе «D»

                  «Напрямую» включаемся на продакшене редко — через stace/gdb :-)

                  Многие приложения создают равномерную нагрузку на диск изо дня в день — тогда если снаружи им диск пережимают, это видно как всплекси латенси неплохо.
                    0
                    D может быть по практически любой причине и считать это метрикой для выполнения sla я бы не стал.
                0
                Я слабо понимаю в СХД — а у них есть внутренний мониторинг на эту тему? Если хотя бы по виртуальным дискам статистика запросов разбивается, то уже можно говорить о конкретной де-факто статистике для определенной машины.

                И еще вопрос по поводу конкретно вашей СХД. Положим, я выкачиваю с Хранилища файло 2-3 Гб на максимальной скорости (из Питера в Питер выходит даже до 25-40 Мбайт/сек) — что при этом происходит с производительностью для других клиентов?.. Ибо иной раз я по несколько минут наблюдаю скорость не выше 1 Мбайт/сек. Подозреваю тут балансировку нагрузки — буду признателен, если напишете о ней подробнее.
                  +4
                  Собственно, ситуация в индустрии следующая. Кто-то вкладывается в большие СХД и конструирует их. На таких СХД есть мониторинг, и, утрируя, он выглядит как график latency ответов в какти. Там есть ещё несколько параметров, но основной — этот. Если latency начинает задираться — надо докупать jbod'ы для дисков или начинать переводить клиентов на другое хранилище.

                  Есть другой вариант — в основном любят на мелких VDS у хостеров с парой-тройкой серверов. В этом случае используются локальные диски (обычно SATA в софтовом или хардварном рейде) и тут уж сколько кому достанется, столько достанется. Хардварный рейд даёт кеш (особенно на запись), так что при некоторых синтетических условиях производительность может зашкаливать за несколько тысяч IOPS на 4-6 дисках. Но это только в пределах кеша. Выходишь за кеш — всё грустно.

                  Кстати, оп неправ насчёт размера базы данных. У нас, например, чтобы выйти за пределы кеша придётся сделать базу этак в гигов 300 в размере.

                  В условиях «мелокого VDS» никто ничего не мониторит, и лучшее, что можно добиться — чтобы перевели на другую ноду.

                  Полноценного SLA по IO, насколько я знаю, не пишут не по причине редкостной злобности, а потому, что очень тяжело измерять. Ведь должны быть консистентные показатели с каждой из сторон — с точки зрения и хостера (чтобы клиент напраслину не говорил), и со стороны пользователя — чтобы тот мог видеть что происходит.

                  В принципе, вокруг tapdisk'а можно попытаться что-то такое написать, но я всё-таки не понимаю как оценивать latency без привлечения debugfs, в условиях только stats с блочного устройства.
                    +1
                    Коллега высказался на тему: «виртуальные диски имеют непостоянный latency, поэтому ставить на них продукционную СУБД, от отклика которой напрямую зависит latency всего приложения — не вариант».

                    Оставаясь иррациональным приверженцем облачного хостинга, размышляю — либо нужно искать варианты гарантировать latency виртуальных дисков, либо думать в сторону такой архитектуры приложений, которая бы меньше страдала от кратковременных залипаний СУБД (СХД). В частности, стремиться хранить все в RAM и очень редко и бережно (читай — пакетно) работать с дисками.

                    Алсо, опять же на уровне прикладной архитектуры, можно подключить к виртуальной машине несколько виртуальных дисков, попросив хостера «распределить» их по СХД, чтобы вероятность «залипания» всех сразу была сильно меньше. На основе этого набора дисков сконструировать что-то вроде программного RAID с требуемыми свойствами (параллельная обработка запросов и преимущественно быстрый ответ хотя бы от одной реплики + eventual consistency), на котором и держать дисковые страницы СУБД. Основной concern, видимо здесь — запросы на запись.

                    Либо же сделать это же, но на уровне хостов — кластерная СУБД. Тогда уже она будет следить, чтобы SQL-запрос коммитнулся хотя бы на одну из реплик (угу, это сразу не master-slave).

                    А вообще это все начинает попахивать NoSQL :))

                    Вобщем, я знаю, что как минимум Heroku и Dropbox работают 100% (или чуть менее) на облачном хостинге, и ведь как-то они это делают!
                      0
                      Heroku и Dropbox работают нормально за счет, как мне кажется, следующих вещей:
                      а) большого колличества нод, обрабатывающих поток и, как следствие, хорошим распределением нагрузки и распределенным кэшем. Да и, кстати, есть подозрение что они используют какую-то из распределенных ФС, а там уже совсем другие калькуляции.
                      б) учитывая то, как работает dropbox, основу там составляет не реляционная DB, во всяком случае в том вопросе, что касается хранения данных.
                      Ну и, наконец, они обеспечивают относительно небольшой iops в сравнении с объемом информации. Цель у них другая — хранение, а не оперативный доступ.
                      По поводу стремления хранить все в RAM и не расчитывать на диски — тут полностью поддерживаю. Особенно это касется реляционных БД, где есть вполне удобноваримые индексы и эффективные механизмы кэширования. Помойму сейчас это умеют все (или почти все) СУБД.
                      Если брать другие задачи, иногда даже SSD откровенно недостаточно (кэш множетва мелких файлов с активным доступом к ним, к примеру). Не даром же тот же memcached живет и здравствует.
                      А вопрос с активным чтением и медленными дисками надо все таки решать через кластеризацию+правильные кэши. И все будет ок.
                      0
                      на вмварьке есть встроенный мониторинг latency для конкретной машины. Возможно есть и для хранилища, но врать не буду, не помню.
                        +1
                        И его показатели можно проверить из самой виртуальной машины? И они совпадут? (Скепсис и недоверие).
                          0
                          Elcor detected ;)
                    +1
                    Согласен, полезно мониторить iostatом моменты торможения диска на БД. Мы так и делаем.
                      0
                      Скажите, а что именно и как вы в нём смотрите и какие показатели вы считаете за «хорошие» и «плохие»?
                        0
                        %util у амазона обычно быстро приходит к 100%, а IOwait у процессора бесполезен, можно лишь обращать внимание на процессы в статусе «D» — так что эти не мониторим.

                        Интерес представляет svctm — но он не меняется почти в амазоне, зато у других меняется еще кк; await — ожидание в очереди, но оно зависит от svctm; awgqu-sz — тут зависит от способности устройства пропускать запросы параллельно, а если нет — зависит от svctm. А что еще мониторить порекомендуете без патчинга ядра?
                          +1
                          есть blktrace (работает через debugfs), но цеплять его в продакте не рекомендуется — оверхед.

                          В этом-то и проблема — я не знаю методов контроля качества IO в линуксе «сбоку». Только по тестам утилит, увы.

                            –1
                            что-то Вы сильно на Linux ушли — а ведь есть еще BSD семейство и UNIX (SmartOS (форк Illumos)) который тоже используются в продакшене достаточно активно.
                              +2
                              В существующих реалиях можно смело полагать, что если эту проблему не решили на линуксе, то её не решили и на соляре/bsd. Точнее, если её решат в bsd, то решение тут же утянут в апстрим линукса.
                                0
                                хостинг компаниям разработка этого модуля не очень то и выгодна, а как коммерчески подобное решение не будет пользоваться спросом — думаю поэтому его и не разрабатывают.
                                  0
                                  Почему не выгодно? Я бы не отказался иметь добротное SLA по IO для клиентов, но — мерять нечем.
                                    0
                                    Потому-что тогда нужно держать соответствующий уровень SLA.
                                    По поводу чем мерить — в случае если используете Xen PVM Linux Kernel или BSD ядро — то можно написать драйвер для замеров IOPS внутри ядра самой ОС, далее экспортировать эти счетчики. Соответственно посчитая количество IOP за определенный тайминги можно получить тот самый IOPS + значение загрузки (т.е. 3 случая — (1) нету загрузки (2) максимум (3) перегрузка )
                                      0
                                      Как посчитать io'ы я в курсе, более того, мы их уже 4ый год клиентам считаем. Как посчитать latency?
                                        0
                                        вот именно поэтому и необходим модуль ядра — идет замер времени между отправкой запроса и физической записью на диск. Тут без правки драйвера диска не обойтись.
                                  0
                                  хм, а как они с лицензией решат?
                                    0
                                    рерайтингом
                                      +1
                                      bsd->linux вроде бы никаких проблем нет.
                                        0
                                        вообще далеко не все. тот-же ZFS и еще некоторые проекты не могут перейти или из-за лицензии или из-за устройства архитектуры ядра.
                              +1
                              Да, конечно можно создать такую цепочку запросов что устройство затупит — но если в среднем смотреть на данные показатели то видно, что виртуальному диску стало плохо не по нашей вине, а по вине провайдера.
                    • UFO just landed and posted this here
                        +2
                        1) Я сталкивался с разрушением временных таблиц MySQL, если они хранятся в tmpfs — просто во время работы. Такое впечатление, что чего-то в tmpfs для хранения файлов MySQL не хватает :-)

                        2) А зачем в данном случае мастер-мастер? Мастер-слейв проще в настройке же и проблем с праймари-ключами и другими чудесами не будет. Согласен, если БД умещается в ОЗУ, почему бы не попробовать. Также можно попробовать положить БД на SSD-диски — вместо tmpfs. Мы же знаем, что операционка кеширует файлы в ОЗУ к тому же.
                        • UFO just landed and posted this here
                            0
                            Начните с SSD, использовать мастер-мастер да еще и с одним инстансом полностью в ОЗу — целых две серьезных точки отказа.

                            График с забикса, 29.12 — момент перехода на зеркало из SSD с простенького зеркала синих WDшек.
                            Несколько баз суммарно ~12Гб, 1.5к запросов\сек с распределением 50\50 чтение\запись.

                            Результат этого перехода мне очень понравился.
                              0
                              И не побоялись такой переход делать прямо перед праздниками?
                                0
                                Наоборот же удобно — если что-то пойдет совсем не так как хочется я смогу полностью отдаться этому серверу без оглядки на работу и прочие раздражители.

                                Это не где-то в ДЦ\на работе\в облаке, это маленький домашний сервер для моего хобби.
                                  0
                                  Ах, вот оно что. Ну если так, то конечно в самый раз.
                            0
                            С временными таблицами в tmpfs такая же солянка. На бумаге все выглядит красиво, все хвалаят у всех работает, а на практике внезапно при выполнении очередного запроска на третий день тестирования оказывается, что таблица не существует, не понимаю как так получается. Думал это у меня одного такой баг.
                              0
                              На данный момент имеем одну небольшую но довольно нагруженную запросами MySql БД живущую в tmpfs, никаких проблем нету, аптайм с пол года.
                              0
                              Возможно не 100% решение, но в таких случаях я делаю «урезанную» копию таблицы с типом MEMORY.
                              В этом случае не приходится создавать отдельную ФС, да и репликация непростая операция.
                              Есть еще альтернатива — memcached и аналоги…
                                0
                                Если памяти достаточно — все данные и так будут в памяти. На сколько я знаю, все актуальные СУБД пользуются системным файловым кэшем, а большинство СУБД вторично кэшируют данные у себя (потому что оттуда данные тягать дешевле, чем сисколом).

                                Вот помониторить активность на предмет файловой сортировки и группировки — бывает очень полезно. Тот же mysql в ряде случаев не может делать это в памяти и идёт мучать диск. Потому временную директорию может иметь хороший смысл перебросить в tmpfs.
                                +3
                                Как представитель облачного провайдера, предоставляющего инфраструктуру, сразу говорю: если инженерам саппорта придёт такой тикет, то первым вопросом будет «какого ресурса вам не хватает?» Диска? Скажите, какую вам делают latency при каком числе iops? Процессора? Памяти?

                                Другими словами, использовать sysbench для OLAP-нагрузки как тест — пожалуйста. Как объективную метрику для того, чтобы реагировать на вопросы по производительности — нет.

                                Или вы хотите как в истории с 3Dmark, когда под тест оптимизировались драйвера? Типа, у нас 100500 попугаев в sysbench'е, а что там latency на IO за секунду переваливает — не волнует?
                                  +1
                                  А в сисбенче не попугаи, там точное число запросов определенного ключиками типа определенного размера блока и с опциями к системному вызову open :-) Я вот создам 20 потоков на жестком диске, затем у вас и сравню латенси и размер очереди и спрошу в тиките — почему? :-)
                                    0
                                    нет, вы плохо товарища читали. Он предлагает использовать olap нагрузку, то есть sysbench для mysql. И ориентироваться на него. (То есть мерять производительность mysql).

                                    Если вы сделаете 20 потоков на виртуальном блочном устройстве у нас и посмотрите на latency, то вы увидите вот это (с живой виртуалки делаю):

                                    Параметры теста: 10 на чтение и 10 на запись, random, direct IO, 4k блоки.
                                    read: (groupid=0, jobs=1): err= 0: pid=31944
                                      read : io=151216KB, bw=3507KB/s, iops=876, runt= 43114msec
                                          clat (usec): min=881, max=325929, avg=11385.50, stdev=12349.81
                                      write: (groupid=0, jobs=1): err= 0: pid=31945
                                      write: io=543520KB, bw=12610KB/s, iops=3152, runt= 43104msec
                                        clat (usec): min=638, max=270922, avg=3149.29, stdev=6473.94
                                    


                                    11 ms на чтение — типичный признак холодного чтения, которое пробивает нафиг все кеши и заставляет старые натруженные шпиндели мучительно гонять головки из одного угла в другой в 10 потоков.

                                    А вот как вы эти попугаи увидите «сбоку» от теста (а не по его результатам) — мне как раз и интересно.

                                    (для всех, кто хочет тестировать — учтите, у нас iops'ы платные 43 секунды теста — 85 копеек. Часовой тест обойдётся примерно 100р).
                                      0
                                      Упс, это я плохо читал. Я думал, он будет тестировать sql. В принципе, sysbench плох только тем, что работает поверх файловой системы. Лучше тестировать raw io, потому что IO файловой системы может быть как выше, так и ниже скорости диска (кеш или оверхед на метаданные).
                                        0
                                        Там вроде есть rawio ключик, чтобы мимо кэша ОС работал — O_DIRECT. Конечно, к черту OLAP — тестим чисто работу с устройством.
                                          +2
                                          Если мы говорим про чистое io, то либо IOMeter, либо fio, других альтернатив я не знаю. sysbench очень плохо ответ показывает. latency нет, лога latency не собрать., профиль нагрузки не выставить.

                                          Метод тестирования и саму утилиту я недавно описывал: habrahabr.ru/post/154235/
                                            0
                                            Лог можно собрать если в соседней консоли запустить iostat -xm 5 >> /latency.log. Идея в том, что создаем например 1000 запросов с заданным профилем нагрузки (произвольная запись/чтение с рейтом 2:1 или любым другим) и замеряем время их выполнения на разных дисках. Логично же.
                                    +1
                                    На грани теории заговора, но «Мы знаем, что простые смертные SATA-диски» имеют обыкновение умирать, и возможно большая часть RAID-массивов находится в перманентном состоянии ремапинга, из-за замены дисков? Сильно не пинайте, если глупость сказал, просто знаю что такое может быть проблемой, а как она решается в высоконагруженых системах не в курсе.
                                      +1
                                      Рейды быстрее, а ребилдятся — довольно редко и это сразу заметно, во всяком случае внутри ДЦ/хостером/админом. Конечно высокопроизводительные системы делают на рейдах, т.к. некуда деваться — IOPSов физически не хватает.
                                        +1
                                        Идиотов, которые делают один БОООЛЬШОЙ массив на все диски всё меньше и меньше. Вылет одного диска из десятка — достаточно редкая ситуация, а ребилд нормально нагруженного (то есть не перегруженного) рейда занимает порядка 3-5 дней без деградации производительности (если мы про raid10, опять же, идиотов с raid5/6 под инфраструктуру всё меньше).
                                          +1
                                          я всё-таки повторюсь, что RAID6 весьма осмысленен, когда упираемся в требование максимизации объёма на бакс.
                                          и согласен, что raid10 эффективней… хотя что делать если сдыхает второй диск во время ребилда? диски-то не маленькие, износ равный.
                                            +2
                                            raid6 для хранения имеет смысл. Для IO — нет. 20 дисков в raid6 будут работать на запись с производительностью худшего из этих 20 дисков.

                                            А у raid10 есть большой плюс — у него чем больше шпинделей, тем выше производительность. Причём на запись она растёт как N/2 от числа дисков.
                                              +1
                                              Камрад Amarao, я примерно понял суть, но реквестирую чтобы вы написали хабра-статью про это.
                                                0
                                                Это точно, по IO записи практически ускорения нет. На чтение — есть.
                                          0
                                          А IO scheduler в ядре виртуальной машины не пробовали сменить: с cfq на deadline?
                                            0
                                            в ядре хоста или гостя? наверное, гостя :)
                                              0
                                              Любой IO скедулер (особенно, линукс) увеличивает latency. Хотите максимальной производительности — используйте noop. Скедулеры IO в линуксе хороши в случае 1-2 шпиндельной конструкции, где лучше поиметь пару милисекунд задержки, но выжать +10 IOPS'ов.
                                                0
                                                Пробовали, незаметно улучшений.
                                                0
                                                Видимо массив на SSD

                                                Скорее СХД умеет использовать разные (SATA/SAS/SSD) накопители для создания «слоёв» c отличающимися свойствами: дорогой диск виртуальный диск с большим числом IOPS лежит на SAS-дисках и кэшируется в SSD, а медленный диск перемещают в SATA-«слой».

                                                Only users with full accounts can post comments. Log in, please.