Comments 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. Потеря — не несколько часов, а — в худшем случае — несколько транзакций. ;)
UFO just landed and posted this here
Думаю это не только битрикса проблема, а вообще любую оптимизацию проще начинать с оптимизации запросов и конфигурации таблиц, бд, etc. Это, обычно, дешевле и проще чем масштабировать железо, хотя в железо когда-нибудь всё-таки растущая система упрётся, тут-то эта статья и будет полезной.
Как правило в таких проектах причиной медленной работы является не Битрикс, а качество интеграции проекта.
UFO just landed and posted this here
Если разработчик работает с 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. Пока размер базы позволяет.
У вас садисткие наклонности, раз заставляете ломать глаза и разбираться в оттенка синего цвета.
Так сложно было использовать на графиках просто РАЗНЫЕ цвета?
Так сложно было использовать на графиках просто РАЗНЫЕ цвета?
Sign up to leave a comment.
Выбираем дисковую систему для базы MySQL