Комментарии 63
Я вот думаю, а как можно помочь хостеру лучше предоставлять нам виртуальные диски?.. Положим, предложить резервировать полосу до дисков, или что-нибудь в этом роде. Или же пока тупо архитектурно выносить disk-intensive MySQL на выделенный железный сервер?
Или, положим, резервировать приоритетное обслуживание запросов (очередь с приоритетами), чтобы гарантировать себе предсказуемый latency.
В условиях СХД не возможно сделать очередь с запросами. Причина — СХД одна, хостов много, и на каждом хосте много виртуалок.
Правильно это решается с помощью SLA. Мол, гарантируем обслуживание не менее 1000 запросов с размером блока 2k при latency не более 15мс с 99 персентилем (то есть не менее 99% запросов в количестве менее 1000 шт/с будут обслужены за время менее 15мс).
Другой вопрос — как это мониторить… Я знаю только активные тесты, то есть запуск fio или IOMeter.
Наверное, было бы здорово разработать систему мониторинга SLA для дисковых операций. Всяко лучше, чем шаманство с sysbench'ем.
Правильно это решается с помощью SLA. Мол, гарантируем обслуживание не менее 1000 запросов с размером блока 2k при latency не более 15мс с 99 персентилем (то есть не менее 99% запросов в количестве менее 1000 шт/с будут обслужены за время менее 15мс).
Другой вопрос — как это мониторить… Я знаю только активные тесты, то есть запуск fio или IOMeter.
Наверное, было бы здорово разработать систему мониторинга SLA для дисковых операций. Всяко лучше, чем шаманство с sysbench'ем.
Да, примерно такой SLA я и имел в виду.
Придумаете такого рода мониторинг (не активный — дороговато будет, а, например, статистикой по устройству) — с радостью примем в продакт и пропишем в SLA.
чтобы такое реализовать нужно иметь патч к ядру конкретной ОС — тогда замеры производительность будет что называется из первых рук. Но это естественно не все так просто…
А мы же как системные администраторы все и измеряем сбоку:
1) stolen для CPU — видим, сколько ресурсов отобрала у нас система виртуализации и передала другим машинам
2) сбоку смотрим на vmstat/ps, чтобы понять, кто завис в ожидании ввода вывода на диске в статусе «D»
«Напрямую» включаемся на продакшене редко — через stace/gdb :-)
Многие приложения создают равномерную нагрузку на диск изо дня в день — тогда если снаружи им диск пережимают, это видно как всплекси латенси неплохо.
1) stolen для CPU — видим, сколько ресурсов отобрала у нас система виртуализации и передала другим машинам
2) сбоку смотрим на vmstat/ps, чтобы понять, кто завис в ожидании ввода вывода на диске в статусе «D»
«Напрямую» включаемся на продакшене редко — через stace/gdb :-)
Многие приложения создают равномерную нагрузку на диск изо дня в день — тогда если снаружи им диск пережимают, это видно как всплекси латенси неплохо.
Я слабо понимаю в СХД — а у них есть внутренний мониторинг на эту тему? Если хотя бы по виртуальным дискам статистика запросов разбивается, то уже можно говорить о конкретной де-факто статистике для определенной машины.
И еще вопрос по поводу конкретно вашей СХД. Положим, я выкачиваю с Хранилища файло 2-3 Гб на максимальной скорости (из Питера в Питер выходит даже до 25-40 Мбайт/сек) — что при этом происходит с производительностью для других клиентов?.. Ибо иной раз я по несколько минут наблюдаю скорость не выше 1 Мбайт/сек. Подозреваю тут балансировку нагрузки — буду признателен, если напишете о ней подробнее.
И еще вопрос по поводу конкретно вашей СХД. Положим, я выкачиваю с Хранилища файло 2-3 Гб на максимальной скорости (из Питера в Питер выходит даже до 25-40 Мбайт/сек) — что при этом происходит с производительностью для других клиентов?.. Ибо иной раз я по несколько минут наблюдаю скорость не выше 1 Мбайт/сек. Подозреваю тут балансировку нагрузки — буду признателен, если напишете о ней подробнее.
Собственно, ситуация в индустрии следующая. Кто-то вкладывается в большие СХД и конструирует их. На таких СХД есть мониторинг, и, утрируя, он выглядит как график latency ответов в какти. Там есть ещё несколько параметров, но основной — этот. Если latency начинает задираться — надо докупать jbod'ы для дисков или начинать переводить клиентов на другое хранилище.
Есть другой вариант — в основном любят на мелких VDS у хостеров с парой-тройкой серверов. В этом случае используются локальные диски (обычно SATA в софтовом или хардварном рейде) и тут уж сколько кому достанется, столько достанется. Хардварный рейд даёт кеш (особенно на запись), так что при некоторых синтетических условиях производительность может зашкаливать за несколько тысяч IOPS на 4-6 дисках. Но это только в пределах кеша. Выходишь за кеш — всё грустно.
Кстати, оп неправ насчёт размера базы данных. У нас, например, чтобы выйти за пределы кеша придётся сделать базу этак в гигов 300 в размере.
В условиях «мелокого VDS» никто ничего не мониторит, и лучшее, что можно добиться — чтобы перевели на другую ноду.
Полноценного SLA по IO, насколько я знаю, не пишут не по причине редкостной злобности, а потому, что очень тяжело измерять. Ведь должны быть консистентные показатели с каждой из сторон — с точки зрения и хостера (чтобы клиент напраслину не говорил), и со стороны пользователя — чтобы тот мог видеть что происходит.
В принципе, вокруг tapdisk'а можно попытаться что-то такое написать, но я всё-таки не понимаю как оценивать latency без привлечения debugfs, в условиях только stats с блочного устройства.
Есть другой вариант — в основном любят на мелких VDS у хостеров с парой-тройкой серверов. В этом случае используются локальные диски (обычно SATA в софтовом или хардварном рейде) и тут уж сколько кому достанется, столько достанется. Хардварный рейд даёт кеш (особенно на запись), так что при некоторых синтетических условиях производительность может зашкаливать за несколько тысяч IOPS на 4-6 дисках. Но это только в пределах кеша. Выходишь за кеш — всё грустно.
Кстати, оп неправ насчёт размера базы данных. У нас, например, чтобы выйти за пределы кеша придётся сделать базу этак в гигов 300 в размере.
В условиях «мелокого VDS» никто ничего не мониторит, и лучшее, что можно добиться — чтобы перевели на другую ноду.
Полноценного SLA по IO, насколько я знаю, не пишут не по причине редкостной злобности, а потому, что очень тяжело измерять. Ведь должны быть консистентные показатели с каждой из сторон — с точки зрения и хостера (чтобы клиент напраслину не говорил), и со стороны пользователя — чтобы тот мог видеть что происходит.
В принципе, вокруг tapdisk'а можно попытаться что-то такое написать, но я всё-таки не понимаю как оценивать latency без привлечения debugfs, в условиях только stats с блочного устройства.
Коллега высказался на тему: «виртуальные диски имеют непостоянный latency, поэтому ставить на них продукционную СУБД, от отклика которой напрямую зависит latency всего приложения — не вариант».
Оставаясь иррациональным приверженцем облачного хостинга, размышляю — либо нужно искать варианты гарантировать latency виртуальных дисков, либо думать в сторону такой архитектуры приложений, которая бы меньше страдала от кратковременных залипаний СУБД (СХД). В частности, стремиться хранить все в RAM и очень редко и бережно (читай — пакетно) работать с дисками.
Алсо, опять же на уровне прикладной архитектуры, можно подключить к виртуальной машине несколько виртуальных дисков, попросив хостера «распределить» их по СХД, чтобы вероятность «залипания» всех сразу была сильно меньше. На основе этого набора дисков сконструировать что-то вроде программного RAID с требуемыми свойствами (параллельная обработка запросов и преимущественно быстрый ответ хотя бы от одной реплики + eventual consistency), на котором и держать дисковые страницы СУБД. Основной concern, видимо здесь — запросы на запись.
Либо же сделать это же, но на уровне хостов — кластерная СУБД. Тогда уже она будет следить, чтобы SQL-запрос коммитнулся хотя бы на одну из реплик (угу, это сразу не master-slave).
А вообще это все начинает попахивать NoSQL :))
Вобщем, я знаю, что как минимум Heroku и Dropbox работают 100% (или чуть менее) на облачном хостинге, и ведь как-то они это делают!
Оставаясь иррациональным приверженцем облачного хостинга, размышляю — либо нужно искать варианты гарантировать latency виртуальных дисков, либо думать в сторону такой архитектуры приложений, которая бы меньше страдала от кратковременных залипаний СУБД (СХД). В частности, стремиться хранить все в RAM и очень редко и бережно (читай — пакетно) работать с дисками.
Алсо, опять же на уровне прикладной архитектуры, можно подключить к виртуальной машине несколько виртуальных дисков, попросив хостера «распределить» их по СХД, чтобы вероятность «залипания» всех сразу была сильно меньше. На основе этого набора дисков сконструировать что-то вроде программного RAID с требуемыми свойствами (параллельная обработка запросов и преимущественно быстрый ответ хотя бы от одной реплики + eventual consistency), на котором и держать дисковые страницы СУБД. Основной concern, видимо здесь — запросы на запись.
Либо же сделать это же, но на уровне хостов — кластерная СУБД. Тогда уже она будет следить, чтобы SQL-запрос коммитнулся хотя бы на одну из реплик (угу, это сразу не master-slave).
А вообще это все начинает попахивать NoSQL :))
Вобщем, я знаю, что как минимум Heroku и Dropbox работают 100% (или чуть менее) на облачном хостинге, и ведь как-то они это делают!
Heroku и Dropbox работают нормально за счет, как мне кажется, следующих вещей:
а) большого колличества нод, обрабатывающих поток и, как следствие, хорошим распределением нагрузки и распределенным кэшем. Да и, кстати, есть подозрение что они используют какую-то из распределенных ФС, а там уже совсем другие калькуляции.
б) учитывая то, как работает dropbox, основу там составляет не реляционная DB, во всяком случае в том вопросе, что касается хранения данных.
Ну и, наконец, они обеспечивают относительно небольшой iops в сравнении с объемом информации. Цель у них другая — хранение, а не оперативный доступ.
По поводу стремления хранить все в RAM и не расчитывать на диски — тут полностью поддерживаю. Особенно это касется реляционных БД, где есть вполне удобноваримые индексы и эффективные механизмы кэширования. Помойму сейчас это умеют все (или почти все) СУБД.
Если брать другие задачи, иногда даже SSD откровенно недостаточно (кэш множетва мелких файлов с активным доступом к ним, к примеру). Не даром же тот же memcached живет и здравствует.
А вопрос с активным чтением и медленными дисками надо все таки решать через кластеризацию+правильные кэши. И все будет ок.
а) большого колличества нод, обрабатывающих поток и, как следствие, хорошим распределением нагрузки и распределенным кэшем. Да и, кстати, есть подозрение что они используют какую-то из распределенных ФС, а там уже совсем другие калькуляции.
б) учитывая то, как работает dropbox, основу там составляет не реляционная DB, во всяком случае в том вопросе, что касается хранения данных.
Ну и, наконец, они обеспечивают относительно небольшой iops в сравнении с объемом информации. Цель у них другая — хранение, а не оперативный доступ.
По поводу стремления хранить все в RAM и не расчитывать на диски — тут полностью поддерживаю. Особенно это касется реляционных БД, где есть вполне удобноваримые индексы и эффективные механизмы кэширования. Помойму сейчас это умеют все (или почти все) СУБД.
Если брать другие задачи, иногда даже SSD откровенно недостаточно (кэш множетва мелких файлов с активным доступом к ним, к примеру). Не даром же тот же memcached живет и здравствует.
А вопрос с активным чтением и медленными дисками надо все таки решать через кластеризацию+правильные кэши. И все будет ок.
на вмварьке есть встроенный мониторинг latency для конкретной машины. Возможно есть и для хранилища, но врать не буду, не помню.
Согласен, полезно мониторить iostatом моменты торможения диска на БД. Мы так и делаем.
Скажите, а что именно и как вы в нём смотрите и какие показатели вы считаете за «хорошие» и «плохие»?
%util у амазона обычно быстро приходит к 100%, а IOwait у процессора бесполезен, можно лишь обращать внимание на процессы в статусе «D» — так что эти не мониторим.
Интерес представляет svctm — но он не меняется почти в амазоне, зато у других меняется еще кк; await — ожидание в очереди, но оно зависит от svctm; awgqu-sz — тут зависит от способности устройства пропускать запросы параллельно, а если нет — зависит от svctm. А что еще мониторить порекомендуете без патчинга ядра?
Интерес представляет svctm — но он не меняется почти в амазоне, зато у других меняется еще кк; await — ожидание в очереди, но оно зависит от svctm; awgqu-sz — тут зависит от способности устройства пропускать запросы параллельно, а если нет — зависит от svctm. А что еще мониторить порекомендуете без патчинга ядра?
есть blktrace (работает через debugfs), но цеплять его в продакте не рекомендуется — оверхед.
В этом-то и проблема — я не знаю методов контроля качества IO в линуксе «сбоку». Только по тестам утилит, увы.
В этом-то и проблема — я не знаю методов контроля качества IO в линуксе «сбоку». Только по тестам утилит, увы.
что-то Вы сильно на Linux ушли — а ведь есть еще BSD семейство и UNIX (SmartOS (форк Illumos)) который тоже используются в продакшене достаточно активно.
В существующих реалиях можно смело полагать, что если эту проблему не решили на линуксе, то её не решили и на соляре/bsd. Точнее, если её решат в bsd, то решение тут же утянут в апстрим линукса.
хостинг компаниям разработка этого модуля не очень то и выгодна, а как коммерчески подобное решение не будет пользоваться спросом — думаю поэтому его и не разрабатывают.
Почему не выгодно? Я бы не отказался иметь добротное SLA по IO для клиентов, но — мерять нечем.
Потому-что тогда нужно держать соответствующий уровень SLA.
По поводу чем мерить — в случае если используете Xen PVM Linux Kernel или BSD ядро — то можно написать драйвер для замеров IOPS внутри ядра самой ОС, далее экспортировать эти счетчики. Соответственно посчитая количество IOP за определенный тайминги можно получить тот самый IOPS + значение загрузки (т.е. 3 случая — (1) нету загрузки (2) максимум (3) перегрузка )
По поводу чем мерить — в случае если используете Xen PVM Linux Kernel или BSD ядро — то можно написать драйвер для замеров IOPS внутри ядра самой ОС, далее экспортировать эти счетчики. Соответственно посчитая количество IOP за определенный тайминги можно получить тот самый IOPS + значение загрузки (т.е. 3 случая — (1) нету загрузки (2) максимум (3) перегрузка )
хм, а как они с лицензией решат?
Да, конечно можно создать такую цепочку запросов что устройство затупит — но если в среднем смотреть на данные показатели то видно, что виртуальному диску стало плохо не по нашей вине, а по вине провайдера.
НЛО прилетело и опубликовало эту надпись здесь
1) Я сталкивался с разрушением временных таблиц MySQL, если они хранятся в tmpfs — просто во время работы. Такое впечатление, что чего-то в tmpfs для хранения файлов MySQL не хватает :-)
2) А зачем в данном случае мастер-мастер? Мастер-слейв проще в настройке же и проблем с праймари-ключами и другими чудесами не будет. Согласен, если БД умещается в ОЗУ, почему бы не попробовать. Также можно попробовать положить БД на SSD-диски — вместо tmpfs. Мы же знаем, что операционка кеширует файлы в ОЗУ к тому же.
2) А зачем в данном случае мастер-мастер? Мастер-слейв проще в настройке же и проблем с праймари-ключами и другими чудесами не будет. Согласен, если БД умещается в ОЗУ, почему бы не попробовать. Также можно попробовать положить БД на SSD-диски — вместо tmpfs. Мы же знаем, что операционка кеширует файлы в ОЗУ к тому же.
НЛО прилетело и опубликовало эту надпись здесь
Начните с SSD, использовать мастер-мастер да еще и с одним инстансом полностью в ОЗу — целых две серьезных точки отказа.
График с забикса, 29.12 — момент перехода на зеркало из SSD с простенького зеркала синих WDшек.
Несколько баз суммарно ~12Гб, 1.5к запросов\сек с распределением 50\50 чтение\запись.
Результат этого перехода мне очень понравился.
График с забикса, 29.12 — момент перехода на зеркало из SSD с простенького зеркала синих WDшек.
Несколько баз суммарно ~12Гб, 1.5к запросов\сек с распределением 50\50 чтение\запись.
Результат этого перехода мне очень понравился.
С временными таблицами в tmpfs такая же солянка. На бумаге все выглядит красиво, все хвалаят у всех работает, а на практике внезапно при выполнении очередного запроска на третий день тестирования оказывается, что таблица не существует, не понимаю как так получается. Думал это у меня одного такой баг.
На данный момент имеем одну небольшую но довольно нагруженную запросами MySql БД живущую в tmpfs, никаких проблем нету, аптайм с пол года.
Возможно не 100% решение, но в таких случаях я делаю «урезанную» копию таблицы с типом MEMORY.
В этом случае не приходится создавать отдельную ФС, да и репликация непростая операция.
Есть еще альтернатива — memcached и аналоги…
В этом случае не приходится создавать отдельную ФС, да и репликация непростая операция.
Есть еще альтернатива — memcached и аналоги…
Если памяти достаточно — все данные и так будут в памяти. На сколько я знаю, все актуальные СУБД пользуются системным файловым кэшем, а большинство СУБД вторично кэшируют данные у себя (потому что оттуда данные тягать дешевле, чем сисколом).
Вот помониторить активность на предмет файловой сортировки и группировки — бывает очень полезно. Тот же mysql в ряде случаев не может делать это в памяти и идёт мучать диск. Потому временную директорию может иметь хороший смысл перебросить в tmpfs.
Вот помониторить активность на предмет файловой сортировки и группировки — бывает очень полезно. Тот же mysql в ряде случаев не может делать это в памяти и идёт мучать диск. Потому временную директорию может иметь хороший смысл перебросить в tmpfs.
Как представитель облачного провайдера, предоставляющего инфраструктуру, сразу говорю: если инженерам саппорта придёт такой тикет, то первым вопросом будет «какого ресурса вам не хватает?» Диска? Скажите, какую вам делают latency при каком числе iops? Процессора? Памяти?
Другими словами, использовать sysbench для OLAP-нагрузки как тест — пожалуйста. Как объективную метрику для того, чтобы реагировать на вопросы по производительности — нет.
Или вы хотите как в истории с 3Dmark, когда под тест оптимизировались драйвера? Типа, у нас 100500 попугаев в sysbench'е, а что там latency на IO за секунду переваливает — не волнует?
Другими словами, использовать sysbench для OLAP-нагрузки как тест — пожалуйста. Как объективную метрику для того, чтобы реагировать на вопросы по производительности — нет.
Или вы хотите как в истории с 3Dmark, когда под тест оптимизировались драйвера? Типа, у нас 100500 попугаев в sysbench'е, а что там latency на IO за секунду переваливает — не волнует?
А в сисбенче не попугаи, там точное число запросов определенного ключиками типа определенного размера блока и с опциями к системному вызову open :-) Я вот создам 20 потоков на жестком диске, затем у вас и сравню латенси и размер очереди и спрошу в тиките — почему? :-)
нет, вы плохо товарища читали. Он предлагает использовать olap нагрузку, то есть sysbench для mysql. И ориентироваться на него. (То есть мерять производительность mysql).
Если вы сделаете 20 потоков на виртуальном блочном устройстве у нас и посмотрите на latency, то вы увидите вот это (с живой виртуалки делаю):
Параметры теста: 10 на чтение и 10 на запись, random, direct IO, 4k блоки.
11 ms на чтение — типичный признак холодного чтения, которое пробивает нафиг все кеши и заставляет старые натруженные шпиндели мучительно гонять головки из одного угла в другой в 10 потоков.
А вот как вы эти попугаи увидите «сбоку» от теста (а не по его результатам) — мне как раз и интересно.
(для всех, кто хочет тестировать — учтите, у нас iops'ы платные 43 секунды теста — 85 копеек. Часовой тест обойдётся примерно 100р).
Если вы сделаете 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р).
Упс, это я плохо читал. Я думал, он будет тестировать sql. В принципе, sysbench плох только тем, что работает поверх файловой системы. Лучше тестировать raw io, потому что IO файловой системы может быть как выше, так и ниже скорости диска (кеш или оверхед на метаданные).
Там вроде есть rawio ключик, чтобы мимо кэша ОС работал — O_DIRECT. Конечно, к черту OLAP — тестим чисто работу с устройством.
Если мы говорим про чистое io, то либо IOMeter, либо fio, других альтернатив я не знаю. sysbench очень плохо ответ показывает. latency нет, лога latency не собрать., профиль нагрузки не выставить.
Метод тестирования и саму утилиту я недавно описывал: habrahabr.ru/post/154235/
Метод тестирования и саму утилиту я недавно описывал: habrahabr.ru/post/154235/
На грани теории заговора, но «Мы знаем, что простые смертные SATA-диски» имеют обыкновение умирать, и возможно большая часть RAID-массивов находится в перманентном состоянии ремапинга, из-за замены дисков? Сильно не пинайте, если глупость сказал, просто знаю что такое может быть проблемой, а как она решается в высоконагруженых системах не в курсе.
Рейды быстрее, а ребилдятся — довольно редко и это сразу заметно, во всяком случае внутри ДЦ/хостером/админом. Конечно высокопроизводительные системы делают на рейдах, т.к. некуда деваться — IOPSов физически не хватает.
Идиотов, которые делают один БОООЛЬШОЙ массив на все диски всё меньше и меньше. Вылет одного диска из десятка — достаточно редкая ситуация, а ребилд нормально нагруженного (то есть не перегруженного) рейда занимает порядка 3-5 дней без деградации производительности (если мы про raid10, опять же, идиотов с raid5/6 под инфраструктуру всё меньше).
я всё-таки повторюсь, что RAID6 весьма осмысленен, когда упираемся в требование максимизации объёма на бакс.
и согласен, что raid10 эффективней… хотя что делать если сдыхает второй диск во время ребилда? диски-то не маленькие, износ равный.
и согласен, что raid10 эффективней… хотя что делать если сдыхает второй диск во время ребилда? диски-то не маленькие, износ равный.
А IO scheduler в ядре виртуальной машины не пробовали сменить: с cfq на deadline?
в ядре хоста или гостя? наверное, гостя :)
Любой IO скедулер (особенно, линукс) увеличивает latency. Хотите максимальной производительности — используйте noop. Скедулеры IO в линуксе хороши в случае 1-2 шпиндельной конструкции, где лучше поиметь пару милисекунд задержки, но выжать +10 IOPS'ов.
Пробовали, незаметно улучшений.
Видимо массив на SSD
Скорее СХД умеет использовать разные (SATA/SAS/SSD) накопители для создания «слоёв» c отличающимися свойствами: дорогой диск виртуальный диск с большим числом IOPS лежит на SAS-дисках и кэшируется в SSD, а медленный диск перемещают в SATA-«слой».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Измеряем производительность «облачных» дисков — спасаем MySQL