Comments 47
У многих хостеров уже есть варианты аренды серверов с SSD. Как минимум Amazon и Hetzner. Netflix недавно перешли на ssd: techblog.netflix.com/2012/07/benchmarking-high-performance-io-with.html и очень этому рады. Фейсбук так вообще самый крупный клиент у Fusion-IO (производителя ssd-дисков).
А с другой стороны, интуиция подсказывает, что этому должен соответствовать какой-то программный прогресс: новые БД, другие алгоритмы и структуры данных. Ведь изменились соотношение между стоимостью операции случайного доступа и стоимостью операции порследовательного доступа. Производительность IO сильно повысилась, а это значит, что CPU стал относительно более ценным
И вот прогресса в этой области не очень заметно. Есть старый redis со своим write-logом, который делался с hdd в уме, есть in-memory базы, которые вообще диск не используют. Есть технологии вроде LevelDB, TokuDB и других, которые вместо обычных B-Tree используют несколько неизменяемых деревьев и write-log, делая вместо множества случайных записей несколько больших последовательных. Ну, percona делает бенчмарки на SSD, и всё. И прогресс в SSD никак не находит отражения в алгоритмах. Как так? Я не туда смотрю? Или, может быть, всё и так хорошо работает и все уже давно перешли на SSD, а я и не в курсе?
А с другой стороны, интуиция подсказывает, что этому должен соответствовать какой-то программный прогресс: новые БД, другие алгоритмы и структуры данных. Ведь изменились соотношение между стоимостью операции случайного доступа и стоимостью операции порследовательного доступа. Производительность IO сильно повысилась, а это значит, что CPU стал относительно более ценным
И вот прогресса в этой области не очень заметно. Есть старый redis со своим write-logом, который делался с hdd в уме, есть in-memory базы, которые вообще диск не используют. Есть технологии вроде LevelDB, TokuDB и других, которые вместо обычных B-Tree используют несколько неизменяемых деревьев и write-log, делая вместо множества случайных записей несколько больших последовательных. Ну, percona делает бенчмарки на SSD, и всё. И прогресс в SSD никак не находит отражения в алгоритмах. Как так? Я не туда смотрю? Или, может быть, всё и так хорошо работает и все уже давно перешли на SSD, а я и не в курсе?
Ведь изменились соотношение между стоимостью операции случайного доступа и стоимостью операции последовательного доступа. Производительность IO сильно повысилась, а это значит, что CPU стал относительно более ценным.
PostgreSQL 9.1 documentation
Chapter 18. Server Configuration
18.7. Query Planning
18.7.2. Planner Cost Constants:
- seq_page_cost (floating point) — Sets the planner's estimate of the cost of a disk page fetch that is part of a series of sequential fetches. The default is 1.0. …
- random_page_cost (floating point) — Sets the planner's estimate of the cost of a non-sequentially-fetched disk page. The default is 4.0. …
- cpu_tuple_cost (floating point) — Sets the planner's estimate of the cost of processing each row during a query. The default is 0.01. …
- cpu_index_tuple_cost (floating point) — Sets the planner's estimate of the cost of processing each index entry during an index scan. The default is 0.005. …
Ура, наконец-то голосование с нормальными вариантами ответов!
нажал воздержаться, мой ответ «не используем, только думаем об этом»
Убили на Database-серверах уже три SSD, благодаря багам в прошивках от OCZ, дохнущих под постоянной нагрузкой.
Продолжаем, потому что аналогов по скорости произвольного доступа нет.
Продолжаем, потому что аналогов по скорости произвольного доступа нет.
какая БД, за какое время вы их убили и сколько у вас дисков используется вообще?
Intel и Samsung only
Насчет SSD-дисков в высоконагруженном продакшене. Суровая реальность такова, что использовать конечно, можно, но очень ограничено, например для некоторой разгрузки ввода-вывода основного рейда. Максимальное, что позволяет моя параноя это для ускорения это продублировать на SSD часть данных которые и так есть на нормальном железном рейде.
Как системники в двух серверах использую intel 320 по 40 GB в зеркалах.
Под небольшую mysql базу (около пяти гиг) стоят в зеркале два intel 311 по 20GB на SLC (взял сразу как только вышли в германии)
Уже больше года не нарадуюсь, сравнивая с другими серверами и жду когда представится возможность и там всё заменить, что не требует терабайтов. Неделю назад взял еще один из 313 серии, тоже на SLC под базу.
Под небольшую mysql базу (около пяти гиг) стоят в зеркале два intel 311 по 20GB на SLC (взял сразу как только вышли в германии)
Уже больше года не нарадуюсь, сравнивая с другими серверами и жду когда представится возможность и там всё заменить, что не требует терабайтов. Неделю назад взял еще один из 313 серии, тоже на SLC под базу.
Кстати насчет рейдов и трима — как бы не пугали, под XFS (без трима) в софтверном рейде-зеркале (mdadm тоже не поддерживает пока трим) база прожила уже больше года, успев перезаписать диск на 13TB, что примерно 650 раз весь диск, что для SLC вообще копейки.
Сейчас правда поставил ext4, потому как хочу попробовать заюзать ручной тримминг.
Сейчас правда поставил ext4, потому как хочу попробовать заюзать ручной тримминг.
С такими объемами проще базу в оперативку загнать.
Использование уже более года intel 320 серии, показывает, что жить можно. Постепенно переходим на 520ю, по производительности эта серия уже не хромает на операциях записи. С OCZ огребли проблем в ПК (Windows) и пока опасаемся тех же камней с Sand Force на серверных моделях.
Не используем, поскольку нет возможности купить SAS c dual path. А без этого СХД теряет отказоустойчивость и верещат на отсутствие второго пути
Мы нищеброды и не можем отдавать по $15к за 400 гигов полезной ёмкости, да и базы к скорости не очень критичны.
480Gb стоят по $600-700, какие 15к?
400 ГБ стоит $7500, плюс второй в зеркало.
если хотите, то я могу продавать 400Гб за $9900. дороже уже не найдёте, соглашайтесь скорее.
Речь ведь про серверы?
естественно.
и в данном случае не совсем понятно, есть ли смысл переплачивать в 11 раз за бренд и за SAS-интерфейс.
если обязательно хотите диск с надписью «для сервера», выше finnist советовал: Deneva 2 C
и в данном случае не совсем понятно, есть ли смысл переплачивать в 11 раз за бренд и за SAS-интерфейс.
если обязательно хотите диск с надписью «для сервера», выше finnist советовал: Deneva 2 C
Использую OCZ Vertex 3 128 гигов в гибридном зеркале на Adaptec 6805E контроллере, уже больше полгода, нареканий нет, забит наполовину, здоровье — 100%.
SSD в базах %) только если они RO.
В настоящий момент память дешевле и надёжнее…
В настоящий момент память дешевле и надёжнее…
А как же отказоустойчивость?
а где отказоустойчивость с ssd?
они сыпятся как песочные скульптуры…
а в обычной схеме с hdd-raid и *много* RAM и хорошем бесперебойным питанием дела обстоят лучше.
они сыпятся как песочные скульптуры…
а в обычной схеме с hdd-raid и *много* RAM и хорошем бесперебойным питанием дела обстоят лучше.
ssd сыпятся не намного чаще чем raid контроллеры.
www.tomshardware.com/reviews/ssd-reliability-failure-rate,2923-6.html
www.tomshardware.com/reviews/ssd-reliability-failure-rate,2923-6.html
Ну я выше написал, у меня на достаточно нагруженном сайте уже полгода работает в гибридном раиде (SSD + SAS). Достаточно отказоустойчивая схема для варианта где чтения больше чем записи в БД.
Почему память тут была хуже, я расскажу:
1. Сервер достаточно старый (да, такое часто бывает), память для него искать тяжело
2. Память в серверах регистровая, соответственно стоит недёшево, а вкупе с устаревшим железом стоит совсем бессовестно
3. Сайтом этим занимались >3 программистов и не одновременно, т.е. есть куча плохого кода + крайне неоптимальных SQL запросов, которые не кешируются и платить за переработку этого кода выйдет в сотни раз дороже чем гибридный RAID с SSD.
Если вы хотите предложить хранить БД в RAM диске — это грозит большими потерями данных с достаточно серьёзной вероятностью.
Так что вариант в SSD может быть бюджетным и отказоустойчивым.
Либо я может быть не понимаю какой вариант с использованием RAM вы можете предложить чтобы было более отказоустойчиво и производительно? Поясните, пожалуйста.
Почему память тут была хуже, я расскажу:
1. Сервер достаточно старый (да, такое часто бывает), память для него искать тяжело
2. Память в серверах регистровая, соответственно стоит недёшево, а вкупе с устаревшим железом стоит совсем бессовестно
3. Сайтом этим занимались >3 программистов и не одновременно, т.е. есть куча плохого кода + крайне неоптимальных SQL запросов, которые не кешируются и платить за переработку этого кода выйдет в сотни раз дороже чем гибридный RAID с SSD.
Если вы хотите предложить хранить БД в RAM диске — это грозит большими потерями данных с достаточно серьёзной вероятностью.
Так что вариант в SSD может быть бюджетным и отказоустойчивым.
Либо я может быть не понимаю какой вариант с использованием RAM вы можете предложить чтобы было более отказоустойчиво и производительно? Поясните, пожалуйста.
в RAM читается все...? c дисков при старте, а синхронизируется это все в фоне(память на диски), не мешая запросам и изменению, да при пропадании питания или нештатного завершения некоторые данные можно потерять.
Ну а при высоко нагруженных на выборки базах (или когда содержимое крайне редко меняется) — имхо самое то.
Ну а при высоко нагруженных на выборки базах (или когда содержимое крайне редко меняется) — имхо самое то.
1) у hdd raid несравнимо меньшая производительность. даже у 15к, которые кстати стоят как маленькие самолёты
2) память, если её в один сервер ставить много, то нужно ёмкие планки, а они тоже довольно дорогие. два ssd по 250 гигов — легко, а 512 гигов RAM это уже hi-end.
2) память, если её в один сервер ставить много, то нужно ёмкие планки, а они тоже довольно дорогие. два ssd по 250 гигов — легко, а 512 гигов RAM это уже hi-end.
Обычные SSD на MLC использовать боимся под базы, но под системой и статикой живут нормально.
Под базы есть мысли купить FusionIO ioDrive2, тоже на MLC, но к нему пока доверие есть, за счет объема в 1 терабайт в теории он выдержит около 3000Тб записи, чего нам должно хватить надолго.
Под базы есть мысли купить FusionIO ioDrive2, тоже на MLC, но к нему пока доверие есть, за счет объема в 1 терабайт в теории он выдержит около 3000Тб записи, чего нам должно хватить надолго.
Одно крупное предприятие в нашем городе (автосалон) перевело сервера ДБ на SSD, 2 месяца всё летало, пока SSD не нагнулись, вернулись на HDD и RAID.
Не используем, но думаем об этом. Думаем очень плотно, в ближайшее время хотим попробовать перейти. Кто может ткнуть носом на нестандартные «подводные камни» с которыми можно будет столкнуться в процессе миграции?
С SSD я разбирался и работал ТОЛЬКО с adaptec контроллерами, потому речь будет о них, кто знает о других, пусть отдельно пишет.
1. Подключение: SSD отличаются большой скоростью записи/чтения, потому для производительных дисков пропускной способности интерфейса SATA2 катастрофически нехватает, потому выбирать RAID контроллер надо с учётом наличия портов SATA3
1.2 Мало кто задумывается, но интерфейс подключения самого контроллера к материнке тоже важен например у 6405E — PCIe 2.0 x1, а у 6805E — PCIe 2.0 x4. При хорошей нагрузке 1 SSD диска у 6405E будет загрузка пропускной способности больше чем наполовину, то есть при большом количестве дисков можно получить «узкое место» в производительности в этом вопросе
2. Работа с кешем RAID контроллера: с небольшим кешем (у меня на 6805E 128 мегабайт) и при чтении и при записи с SSD производительность ПОНИЖАЕТСЯ! Т.е. есть резон кеширование для раидов с SSD отключать, как минимум надо протестировать. Обязательно замерьте производительность с кешированием и без отдельно для записи и чтения.
3. Ну конечно же надо планировать чтобы на SSD почти всегда было свободно >50% ибо по всем тестам они так дольше всего живут и с некоторыми прошивками с этим условием выше производительность.
4. Считаю что собирать 2 SSD диска в зеркало глупо, потому что в интернете многие пишут что они выходят из строя почти одинаково, так что тут надо либо гибридный раид (SSD + SAS) собирать, либо покупать дорогой раид контроллер (у адаптеков Q и ZQ серии, они умеют кешировать данные без записи на SSD и кеши у них большие) с батарейкой
5. Мониторинг, мониторинг и ещё раз мониторинг состояния через S.M.A.R.T.
6. Если их использовать без RAID контроллера надо задумываться о тюнинге ОС для TRIM
Собственно вот что я извлёк из своего опыта работы с SSD.
1. Подключение: SSD отличаются большой скоростью записи/чтения, потому для производительных дисков пропускной способности интерфейса SATA2 катастрофически нехватает, потому выбирать RAID контроллер надо с учётом наличия портов SATA3
1.2 Мало кто задумывается, но интерфейс подключения самого контроллера к материнке тоже важен например у 6405E — PCIe 2.0 x1, а у 6805E — PCIe 2.0 x4. При хорошей нагрузке 1 SSD диска у 6405E будет загрузка пропускной способности больше чем наполовину, то есть при большом количестве дисков можно получить «узкое место» в производительности в этом вопросе
2. Работа с кешем RAID контроллера: с небольшим кешем (у меня на 6805E 128 мегабайт) и при чтении и при записи с SSD производительность ПОНИЖАЕТСЯ! Т.е. есть резон кеширование для раидов с SSD отключать, как минимум надо протестировать. Обязательно замерьте производительность с кешированием и без отдельно для записи и чтения.
3. Ну конечно же надо планировать чтобы на SSD почти всегда было свободно >50% ибо по всем тестам они так дольше всего живут и с некоторыми прошивками с этим условием выше производительность.
4. Считаю что собирать 2 SSD диска в зеркало глупо, потому что в интернете многие пишут что они выходят из строя почти одинаково, так что тут надо либо гибридный раид (SSD + SAS) собирать, либо покупать дорогой раид контроллер (у адаптеков Q и ZQ серии, они умеют кешировать данные без записи на SSD и кеши у них большие) с батарейкой
5. Мониторинг, мониторинг и ещё раз мониторинг состояния через S.M.A.R.T.
6. Если их использовать без RAID контроллера надо задумываться о тюнинге ОС для TRIM
Собственно вот что я извлёк из своего опыта работы с SSD.
Если кто может поделиться опытом — прошу отписаться в ЛС по возможности.
Используем ssh intel X-25E 64Гб в raid1 под основную рабочую БД. База около 50Гб весит, работает уже года 2 без нареканий. После перехода на ssd скорость работы реально повысилась. Сбоев за всё время не было. Нагруженность БД достаточно высокая — несколько сотен IO операций/сек, очень много записи.
Так что ssd под БД однозначно быть. Единственно, что нужно постоянно мониторить массив на целостность. Но это и на обычных дисках нужно делать.
Так что ssd под БД однозначно быть. Единственно, что нужно постоянно мониторить массив на целостность. Но это и на обычных дисках нужно делать.
Sign up to leave a comment.
SSD-диски на database-серверах?