Комментарии 84
Спасибо, интересно. На, мягко говоря, «не очень быстрых» дисках EBS амазона — создание софтварного рейда для ускорения производительности, пожалуй, единственное решение. Для RDS базы данных они тоже, согласно документации, поднимают софтварные рейды.
> Требуется поддержка SSD в серверах (контроллер, драйверы).
Эмм… Поддержка SATA III? Или вы о PCI-устройствах?
> SSD — это дорого.
Имхо, сильно дешевле чем RAID 10 с кучей дисков.
А на операциях random read/write топовые SSD вообще вне конкуренции.
Ну как вариант еще — держать всю базу в ОЗУ.
Эмм… Поддержка SATA III? Или вы о PCI-устройствах?
> SSD — это дорого.
Имхо, сильно дешевле чем RAID 10 с кучей дисков.
А на операциях random read/write топовые SSD вообще вне конкуренции.
Ну как вариант еще — держать всю базу в ОЗУ.
RAID 10 — ровно в два раза дороже. А SSD?
И, главное — «железная» инфраструктура плохо масштабируется.
Поэтому описанное решение в большей степени ориентировано на «облако».
И, главное — «железная» инфраструктура плохо масштабируется.
Поэтому описанное решение в большей степени ориентировано на «облако».
>> RAID 10 — ровно в два раза дороже. А SSD?
Почему в два? Отказоустойчивость на SSD дисках тоже надо обеспечивать.
Вы не учитываете стоимость контроллеров (и полок), стоечного места, электричества, охлаждения.
Конечно, все это начинает сказываться только на действительно быстрых дисковых подсистемах — со скоростями больше 5000-6000 iops.
Например, чтобы получить 5000 iops вам потребуется примерно 24 (5000/200 с округлением до четного вверх, но мы округлим вниз — до 24; зачем — будет видно дальше) дисков. При цене диска (SAS 300 Gb 15000 rpm — диски меньшего размера сейчас у вендоров не популярны) примерно $300-$350 получаем $7800 — $9100.
Для сравнения, пара промышленных SSD (например от Делла; насколько я знаю, они используют диски от Pliant) стоит $9198 ($4599 за штуку), которая даст вам производительность на уровне 100000 iops!!!
При этом традиционными дисками вы полностью забьете всю полку (если опять же ориентироваться на железо Делла, а именно на MD3220 емкостью 24 диска — вот почему я округлял вниз), а в случае с SSD у вас еще останется куча места для дисков.
SSD диски в некоторых сценариях оказываются намного предпочтительнее традиционных HDD — SSD дают существенную разницу в скорости при сопоставимой стоимости.
Почему в два? Отказоустойчивость на SSD дисках тоже надо обеспечивать.
Вы не учитываете стоимость контроллеров (и полок), стоечного места, электричества, охлаждения.
Конечно, все это начинает сказываться только на действительно быстрых дисковых подсистемах — со скоростями больше 5000-6000 iops.
Например, чтобы получить 5000 iops вам потребуется примерно 24 (5000/200 с округлением до четного вверх, но мы округлим вниз — до 24; зачем — будет видно дальше) дисков. При цене диска (SAS 300 Gb 15000 rpm — диски меньшего размера сейчас у вендоров не популярны) примерно $300-$350 получаем $7800 — $9100.
Для сравнения, пара промышленных SSD (например от Делла; насколько я знаю, они используют диски от Pliant) стоит $9198 ($4599 за штуку), которая даст вам производительность на уровне 100000 iops!!!
При этом традиционными дисками вы полностью забьете всю полку (если опять же ориентироваться на железо Делла, а именно на MD3220 емкостью 24 диска — вот почему я округлял вниз), а в случае с SSD у вас еще останется куча места для дисков.
SSD диски в некоторых сценариях оказываются намного предпочтительнее традиционных HDD — SSD дают существенную разницу в скорости при сопоставимой стоимости.
Если речь идёт о SSD в RAID, то бессмысленно закладывать «промышленные SSD» в его конфигурацию: массив недорогих SSD будет дешевле, надёжнее и, пожалуй, быстрее, нежели вышеупомянутые.
Ну и потом, увеличение размера оперативной памяти будет скорее всего эффективнее для MySQL по отдаче с цены гигабайта/производительности, чем дисковая подсистема.
Ну и потом, увеличение размера оперативной памяти будет скорее всего эффективнее для MySQL по отдаче с цены гигабайта/производительности, чем дисковая подсистема.
К сожалению, не все дисковые полки умеют работать с SATA дисками. Например, упомянутая мной выше Dell PowerVault MD3220 понимает только SAS. А SAS диски — только промышленные (их вообще всего с десяток моделей наберется).
Использование подобных полок в нашем случае — необходимость, т.к. они нам нужны для создания failover-кластеров.
Опыта работы с MySQL, к сожалению, не имел; только MS SQL Server. Поэтому прокомментирую из собственного опыта: На наших серверах дальнейшее увеличение объема памяти не всегда оправдано (на текущий момент процент попадания запросов в кеш — 99,5% при 128 ГБ памяти на сервере и БД более 1 ТБ). Например, нагрузочное тестирование показывает, что узким местом в нашем случае становится tempdb (ее-то мы и будем переносить на SSD).
Использование подобных полок в нашем случае — необходимость, т.к. они нам нужны для создания failover-кластеров.
Опыта работы с MySQL, к сожалению, не имел; только MS SQL Server. Поэтому прокомментирую из собственного опыта: На наших серверах дальнейшее увеличение объема памяти не всегда оправдано (на текущий момент процент попадания запросов в кеш — 99,5% при 128 ГБ памяти на сервере и БД более 1 ТБ). Например, нагрузочное тестирование показывает, что узким местом в нашем случае становится tempdb (ее-то мы и будем переносить на SSD).
Давайте уж уточним, что на самом деле понимает, только как обычно, особенные ;)
Конечно, полки на лету не меняют, но я бы всё же посмотрел в сторону «обычных» полок от, скажем, Infotrend'a с поддержкой «обычных» SSD.
Я не знаю MS SQL Server, но создание tempdb это разве не создание БД, которая не влезает как раз-таки в память?
У Dell кстати, лежит любопытное исследование: SSD vs HDD Price and Performance Study.
Конечно, полки на лету не меняют, но я бы всё же посмотрел в сторону «обычных» полок от, скажем, Infotrend'a с поддержкой «обычных» SSD.
Я не знаю MS SQL Server, но создание tempdb это разве не создание БД, которая не влезает как раз-таки в память?
У Dell кстати, лежит любопытное исследование: SSD vs HDD Price and Performance Study.
Уточните, плз, в каком именно месте написано, что понимает? Мы пробовали — у нас результат совпадает с мануалом — т.е. полка с САТА дисками работать отказывается.
Про Инфортренд мы в курсе. Но как-то стремно — нам нужен очень высокий уровень поддержки и есть сомнения, что партнеры инфортренда смогут его обеспечить.
У MS SQL Server есть активности (не считая логирования), которые сервер пытается «провести» через диск даже при достаточном количестве оперативной памяти — в этом случае используется tempdb.
Про Инфортренд мы в курсе. Но как-то стремно — нам нужен очень высокий уровень поддержки и есть сомнения, что партнеры инфортренда смогут его обеспечить.
У MS SQL Server есть активности (не считая логирования), которые сервер пытается «провести» через диск даже при достаточном количестве оперативной памяти — в этом случае используется tempdb.
http://www.dell.com/us/enterprise/p/powervault-md3200/pd#TechSpec:
…
2.5" Drive Performance and Capacities
…
Solid State Drive (SSD) available in 149GB (available in 3.5" HDD carriers)
Да, но где сказано, что это SATA диски?
Используемый Dell'ом Plink — это SAS. MD32x0 не поддерживает SATA. А подавляющее большинство SSD дисков — SATA, а имеющиеся на рынке SAS SSD не сильно отличаются по цене от Plink.
Используемый Dell'ом Plink — это SAS. MD32x0 не поддерживает SATA. А подавляющее большинство SSD дисков — SATA, а имеющиеся на рынке SAS SSD не сильно отличаются по цене от Plink.
Ну так я специально и подчеркнул, что особенные.
Почитал по tempdb, несколько в недоумении, в MySQL всё гораздо проще:
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html. Самое важное:
Первая десятка результатов гугления же по tempdb показывает только советы заранее allocate'ить место большим файлом tempdb да размещать его на больших дисках, из чего я делаю вывод, что MS SQLнастолько тупой, что не умеет настраивать размер временных таблиц в памяти.
Почитал по tempdb, несколько в недоумении, в MySQL всё гораздо проще:
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html. Самое важное:
If an internal temporary table is created initially as an in-memory table but becomes too large, MySQL automatically converts it to an on-disk table. The maximum size for in-memory temporary tables is the minimum of the tmp_table_size and max_heap_table_size values
Первая десятка результатов гугления же по tempdb показывает только советы заранее allocate'ить место большим файлом tempdb да размещать его на больших дисках, из чего я делаю вывод, что MS SQL
SSD дохнут, их для базы лучше не исопльзовать
Тут недавно ребята с рутрекера писали (см. habrahabr.ru/blogs/linux/129551/#comment_4290722 и комменты в треде) о своем опыте использования SSD. В 2-х словах — слухи о высокой смертности SSD сильно преувеличены. И в частности:
— На рто используются несколько PCI-X плат OCZ с SSD маленького обьема, на них лежат особо критичные к скорости БД. Работают около года, отказов пока не было. Оказались в разы быстрей ( и в разы же дешевле) SAS кеш-контроллеров с 15к винтами. Как раз их и дубасят запросами на запись и чтение круглосуточно.
— Ну в крайнем случае можно и RAID1 из 2-х дисков сделать.
— На рто используются несколько PCI-X плат OCZ с SSD маленького обьема, на них лежат особо критичные к скорости БД. Работают около года, отказов пока не было. Оказались в разы быстрей ( и в разы же дешевле) SAS кеш-контроллеров с 15к винтами. Как раз их и дубасят запросами на запись и чтение круглосуточно.
— Ну в крайнем случае можно и RAID1 из 2-х дисков сделать.
Мы использовали для статического контента, отдают быстрее (http://habrahabr.ru/blogs/nginx/108958/).
А на счет базы, то с полной репликой, да, можно исопльзовать.
А на счет базы, то с полной репликой, да, можно исопльзовать.
Не чаще обычных.
При очень большом кол-ве обращений — чаще. При низком — хз.
От чтения им вообще ничего не будет. От записи надо смотреть и считать. У меня даже спец прога написана для этого дела SsdReady, для хабралюдей — бесплатно по этой ссылке.
Да вот ставили знакомые, за +-год все ссд-шки подохли,
действительно, неправильно написал, важна перезапись,
там был гарячий кеширующий (гарячий-холодный кеш) сервер всяких картинок.
действительно, неправильно написал, важна перезапись,
там был гарячий кеширующий (гарячий-холодный кеш) сервер всяких картинок.
Проблема записи важнее чем чтения.
так что лучше её решите.
так что лучше её решите.
Какое соотношение SELECT / UPDATE / INSERT на большинстве проектов?
Для многих крупных высоконагруженных веб-проектов зачастую «узким» местом в производительности становится...
1С-Битрикс
>Если бы мы могли везде использовать SSD, нам бы вообще ничего не нужно было изобретать с точки зрения производительности, вся наша работа не имела бы особого смысла.
Пройдет еще год-два и так и будет.
Пройдет еще год-два и так и будет.
Хорошая статья.
Только, можно попросить в графиках:
1. Подписать ось Y — не для всех очевидно что это за числа, и указать, что лучше (меньшее число или большее)
2. Сделать более отличающиеся цвета у single disk и у RAID 10
Только, можно попросить в графиках:
1. Подписать ось Y — не для всех очевидно что это за числа, и указать, что лучше (меньшее число или большее)
2. Сделать более отличающиеся цвета у single disk и у RAID 10
Особенно по последнему поддерживаю — как натуральный дальтоник каждый такой график для меня мучителен (насколько именно, отлично рассказано и показано здесь).
> На всех тестовых стендах использовалась файловая система ext4.
А что-то типа ZFS не пробовали?
А что-то типа ZFS не пробовали?
SSD можно использовать как кэш для классических HDD без дорогих аппаратных контроллеров. Программные решения:
— модуль ядра Flashcache от Facebook
— ZFS L2Arc, но тут уже без линукса
— модуль ядра Flashcache от Facebook
— ZFS L2Arc, но тут уже без линукса
Под линукс есть еще Btrfs.
У btrfs есть возможность использовать отдельное блочное устройство для кэширования запросов? Сходу ненагуглил. Не подскажите где можно почитать?
В защиту Flashcache могу сказать что эта штука работает на уровне блочных устройств и использует Device Mapper. В работе выглядит как создание нового блочного устройства из основного и кэширующего, при этом данные на основном блочном устройстве при переходе на flashcache не теряются. В общем собирай блочные устройства как душе угодно.
P.S. Flashcache изначально писался для увеличения производительности InnoDB.
В защиту Flashcache могу сказать что эта штука работает на уровне блочных устройств и использует Device Mapper. В работе выглядит как создание нового блочного устройства из основного и кэширующего, при этом данные на основном блочном устройстве при переходе на flashcache не теряются. В общем собирай блочные устройства как душе угодно.
P.S. Flashcache изначально писался для увеличения производительности InnoDB.
Вот есть немного глупый вопрос. База огромной не будет.
Выгодно ли взять 2 SSD в RAID1?
Насколько такая система будет эффективна?
Выгодно ли взять 2 SSD в RAID1?
Насколько такая система будет эффективна?
Выгодно. Хотя, RAID 1 для SSD это глупо, особенно одинаковых.
Умрут одновременно.
Проще на второй ssd раз в день делать полную реплику ( если потеря данных на несколько часов не критичны )
Умрут одновременно.
Проще на второй ssd раз в день делать полную реплику ( если потеря данных на несколько часов не критичны )
>RAID 1 для SSD это глупо, особенно одинаковых. Умрут одновременно.
Я бы сказал, что крайне, крайне спорное утверждение.
Кстати, хорошая новость заключается в том, что умершие SSD как правило, позволяют с себя читать, переставая при этом записывать.
Я бы сказал, что крайне, крайне спорное утверждение.
Кстати, хорошая новость заключается в том, что умершие SSD как правило, позволяют с себя читать, переставая при этом записывать.
Можно поднять второй инстанс MySQL и на второй SSD делать реплику в real-time. Потеря — не несколько часов, а — в худшем случае — несколько транзакций. ;)
Думаю это не только битрикса проблема, а вообще любую оптимизацию проще начинать с оптимизации запросов и конфигурации таблиц, бд, etc. Это, обычно, дешевле и проще чем масштабировать железо, хотя в железо когда-нибудь всё-таки растущая система упрётся, тут-то эта статья и будет полезной.
Как правило в таких проектах причиной медленной работы является не Битрикс, а качество интеграции проекта.
Если разработчик работает с API, понимает архитектуру (и тогда в общем случае и не думает лезть напрямую в БД), то у такого разработчика огромный функционал кэширования компонентов. С которым количество запросов можно свести к нулю.
Узким местом БД становится только при не правильном использование API и ошибок проектирования. С правильным подходом на Битрикс получаются производительные проекты.
Если вы используете Битрикс, это не значит, что вы не должны включать голову. Впрочем как и на других платформах.
Если вы используете Битрикс, это не значит, что вы не должны включать голову. Впрочем как и на других платформах.
Какой-то у Вас неудачный опыт.
На среднем сервере вполне себе получается под 100 запросов в секунду.
Подробно — здесь: www.1c-bitrix.ru/products/cms/performance/
На среднем сервере вполне себе получается под 100 запросов в секунду.
Подробно — здесь: www.1c-bitrix.ru/products/cms/performance/
> На запись — примерно та же картина, что и с одним диском.
Зачем так пишете? На графике же ясно видно, что любой RAID существенно уступает одному диску. Это в тесте не 16 Гб.
Еще непонятно, зачем в статье тест на 256 Мб и рассуждения о его неадекватности. Разве все это не очевидно?
Зачем так пишете? На графике же ясно видно, что любой RAID существенно уступает одному диску. Это в тесте не 16 Гб.
Еще непонятно, зачем в статье тест на 256 Мб и рассуждения о его неадекватности. Разве все это не очевидно?
Когда я выбирал RAID для себя (bitrix, innoodb), то получилось, что RAID6 не уступал, а в некоторых тестах даже обгонял RAID10.
Я естественно ожидал обратной картины. Успокоился на том, что либо у меня руки кривые, либо кривой наш китайский дисковый массив.
Иногда лучше самому провести тест, чем полностью полагаться на аналитику.
Я естественно ожидал обратной картины. Успокоился на том, что либо у меня руки кривые, либо кривой наш китайский дисковый массив.
Иногда лучше самому провести тест, чем полностью полагаться на аналитику.
А собственно, что удивительного? RAID5/6 на чтении действительно будет обгонять по iops´ам RAID10. С записью бедовее. Я ещё в начале прочтения удивился, почему взят raid10
В том то и дело, что запись на RAID6 почему-то была быстрее.
Видимо RAID10 криво реализовали. Дисковый массив ведь полуnoname.
Видимо RAID10 криво реализовали. Дисковый массив ведь полуnoname.
А сколько дисков в страйп было на 10-ке, сколько дисков было на 6-ке? Вот смотреть что надо.
4 там и там
4 всего в 10-ке, или 2x4? В этом есть суть разница. 6-ка размазывает iopsы по всем дискам, а 10-ка только по N/2.
2x2 было в RAID10. Т.е. из-за этого маленькая производительность была?
Капитан очевидность подсказывает, что да. Проблема в рандомайзном конкурентном доступе к диску и ненулевому времени позиционирования головок. Соответственно, несколько дисков на которые размазаны данные дают очевидный прирост этих самых iops (операций ввода/вывода в секунду). Обсчёт там контрольных сумм и избыточность данных занимают времени намного меньше, чем множество позиционирований. Понятно, что по 4-ём дискам в raid6 или по двум в raid10 разница не ровно в два раза, но что-то около того.
Я правильно из графиков понял, что один диск всегда выигрывает? (что в принципе логично)
Некстати, заявление про innodb странно, данные-то по нему всё равно разбросаны дай боже. Да и не все хранят их в одном файле — я разбрасываю, например.
Я бы сконцентрировал внимание на настройки кэша тредов, размера временных таблиц в памяти, скорости дисков на /tmp (где создаются временные таблицы — собственно, бич всяких выборок). Как вариант — держать вот этот /tmp на SSD или вообще на RAM-диске.
P.S. Хотя я бы вздохнул и при ваших мощностях просто аккуратно переписал всё с 0.
Некстати, заявление про innodb странно, данные-то по нему всё равно разбросаны дай боже. Да и не все хранят их в одном файле — я разбрасываю, например.
Я бы сконцентрировал внимание на настройки кэша тредов, размера временных таблиц в памяти, скорости дисков на /tmp (где создаются временные таблицы — собственно, бич всяких выборок). Как вариант — держать вот этот /tmp на SSD или вообще на RAM-диске.
P.S. Хотя я бы вздохнул и при ваших мощностях просто аккуратно переписал всё с 0.
сами только пару дней назад переехали на SSD. Пока размер базы позволяет.
У вас садисткие наклонности, раз заставляете ломать глаза и разбираться в оттенка синего цвета.
Так сложно было использовать на графиках просто РАЗНЫЕ цвета?
Так сложно было использовать на графиках просто РАЗНЫЕ цвета?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выбираем дисковую систему для базы MySQL