Есть неслабо загруженный сервер БД он же сервер приложений.
Ессно - винты самое слабое место. Ну, БД ессно на пятом рэйде, все дела...
Будет ли реальный прирост производительности, если переложить виндовые и пользовательские темпы (ну, там считай один пользователь - сервер приложений) на SSD? И если да, то какой лучше выбрать?
Вроде есть уже вменяемые серверные решения...

Можно еще прикинуть tempdb туда прописать...
Короче, делитесь опытом :)

Может, надо было в админскую ветку закинуть? Х.з...

(0) Бери на sls
там где одна ячейка

(0) Мы сейчас думаем о рейде с SSD кешем.

не правильны выбор. SSD больше для чтения, при интенсивной перезаписи, т.е. кэш и логи безопаснее на рейде.

+ (5) в смысле  БД один рейд а кэш и логи на винте простом + система на SSD так будет правильнее

(3) Тема скорее не по выбору конкретного SSD (тут однозначно будет выбираться правильный девайс компетентными людьми), а по эффективности его применения.
Стоит овчинка выделки или нет.
Просто я не в курсе, насколько сильно тормозят общую производительность при затыке по винтам именно системные темпы и темпы сервера приложений. Стоит ожидать существенного прироста или нет.
Какие-то отзывы по переносу tempdb вроде были, но уже не помню...

еще SSD диски не так долговечны как обычные винты

Перенос tembdb пока отпадает. На SSD-массив такого размера пока денег не выбью.
Так что вопрос только по файловым темпам.
ЗЫ. Ликбез по SSD мне не требуется. Я в теме.

Ессно - винты самое слабое место. Ну, БД ессно на пятом рэйде, все дела...
Ээ простите а в чем естественность размещения БД на массиве 5-го уровня?

(10) В том, что это типовое решение цена/скорость/надежность.

(7) без счётчиков производительности топик без предметный

(12) А по каким конкретно счетчикам и как именно можно понять, какую именно долю привносят в общую загрузку диска темпы? Скажи, объясни - я замерю.

(10) +многа

Системные интеграторы набежали? Ну, да - пятый не десятый. Работаем пока с тем что есть.

Понедельничный ап.

/

(4) изучите тему. SSD в рейде может не поддерживать TRIM. как работают SSD без TRIM стоит почитать в инете.

(0) самый простой способ в твоем случае разделить сервер приложений от SQL. сервер приложений можно положить на SSD SATA2. если есть возможность поставить SATA3, то можно туда ложить выложить базы SQL.

(18) Изучаем :)

(19) А кешу разве TRIM нужен?

(21) TRIM позволяет очистить SSD от старых данных в момент его простоя. винда не умеет через RAID отправлять эти самые команды TRIM. это если кратко. без TRIM диски через некоторое время начинают работать в два раза медленнее.

(22) То есть рейд должен сам уметь очищать свой кеш в момент простоя?
Или просто иметь нормальные алгоритмы кеширования, которые устойчивы к фрагментации?

Поиск по "Фрагментация кеша" - ничего не дает.

(13) по всем физическим дискам процент использования для начала, посмотри график.
Но, имхо, врядли там будет что либо ужасное при обчной работе пользователей с БД.

(23) SSD так сделано, что перед тем как записать в ячейку, он должен её очистить. чтоб не тратить лишние такты контроллера на очистку перед записью, он может сделать это заранее. то есть когда контроллеру делать нефиг, он делает очистку TRIM. но без команды процессора он это делать не будет.

(26) вот тут более понятно будет
wiki:TRIM_(команда_SSD)

Ограничения

TRIM не работает с «виртуальными» дисками, хранящимися в виде образов, что не ограничивает использование команды в виртуальной среде.
TRIM не всегда поддерживается в RAID-массивах.[13]
[править]Поддержка команды операционными системами и дисками

Для старых твердотельных дисков, произведённых до добавления команды TRIM в стандарт ATA, необходимо обновление прошивки — в противном случае, команда будет ими игнорироваться. Команда TRIM поддерживается также не всеми операционными системами.

Я это читал. Получается - вопрос в том, умеют ли рейды в момент простоя очищать старые данные в SSD кеше. Винда это делать совершенно необязана, у рейда есть свой проц.

(28) новые рейды поддерживают

(29) А как узнать какие конкретно поддерживают? Мне сейчас предложили несколько моделей.
http://www.adaptec.com/ru-ru/products/controllers/hardware/ssd-caching/performance/sas-5805zq/

http://www.adaptec.com/ru-ru/products/controllers/hardware/ssd-caching/performance/sas-5805q/

http://www.adaptec.com/ru-ru/products/controllers/hardware/ssd-caching/performance/sas-6805q/

http://www.adaptec.com/ru-ru/products/controllers/hardware/ssd-caching/performance/sas-6805tq/

Эти умеют?

(30) последнюю железку посмотрел. думаю не только TRIM, но и более блатные вещи умеет :) но можно и ошибиться. например в описании сказано, что потоковая запись у HDD выше. но судя по характеристикам последних SSD. это далеко не так. может железки не знают о таких вещах как SATA3, SAS3. бывает ли последний, я вообще не в курсях.

(31) я бы посмотрел последние тесты IOMeter'а для этой железки и для SSD разных.

(31) (32) Мы пока ждем пока другие поэксплуатируют.
Не бывает ли безвозвратных смертей рейда на SSD.

8+0 портовый SAS 6G RAID контроллер. 40 штук стоит!

(33) рейд он не для того, чтоб всегда можно было восстановить инфу. он только для того, чтоб быстро восстановить инфу во многих случаях. есть случаи когда рейд не поможет, то есть бэкапы нужны в любом случае.

(34) У нас ежечасные бекапы. Но если по статистике окажется что SSD рейд в среднем дохнет раз в полгода - нам такое счастье не нужно.

(35) а у вас есть статистика как часто дохнет SAS RAID не SSD? я думаю если и сдохнет, то это будет не удачный выбор поставщика.

http://www.gelezki.info/joomla-overviews/572-intel-ssd-320-five-years.html

(37) интел. гарантия на SSD 5 лет.
но есть ограничения есесно
http://www.intel.com/support/ru/ssdc/hpssd/sb/CS-032510.htm

(38) Гарантия не означает что в течении гарантийного срока SSD не умрет, либо не сбойнет. И тем более не гарантирует что не будет сбоить рейд. А означает всего-лишь факт гарантийных обязательств в этом случае.

(36) Из всех рейдов у нас за всё время умер только один. И то без потери информации.

(39) и в чем проблема? сбойный рейд и дальше будет пахать без одного диска, если это как минимум рейд 0+1. даже если все нафиг накрыло, SSD обещает остаться только чтение.

вот тут доступно и понятно, всё тоже самое сказано.
http://habrahabr.ru/blogs/hardware/124498/

(41) Если сбойнет SSD, то в рейд будут записаны неправильные данные,  и правильные ты уже никогда оттуда не выцепишь. Иь на данные момент я не вижу гарантий что такого не может произойти.
А когда дохнет рейд (часть дисков в рейде) - информацию восстановить можно.

(41) Статья про SSD рейды, а не про рейды с SSD кешем.

И всё-таки, имеет смысл кешировать именно темпы (не своп) на быстрых носителях? Дает это сколько-нибудь заметный прирост? Или нет смысла размениваться по мелочам?

(43) горлышко бутылки. согласен. через пару лет этой проблемы не будет. да и сейчас думаю SSD намного надежнее RAID 10 обычных винтов. но доказывать ничего не буду :)

(44) + Тьфу, не кэшировать, а просто выносить на быстрые носители.

(46) не стоит такого делать. производительности не получишь, а надежность будет меньше. это моё мнмение.

(47) Хм... Просто пару раз попадались на глаза посты, что дескать вынес темпы на рам-драйв и все залетало чуть ли не в разы быстрее. Чёс?
В принципе, можно попробовать поднять рам-драйв на регистровой памяти... По надежности должно быть приемлемо.

(48) + Но большого ж объема не поднимешь, только темпы туда засунуть и получится...

SSD дело другое. На него можно засунуть и своп...
Про серверные рэйды SSD речь пока не идет...
Не тот бюджет пока.

(50) А вариант SSD кеша на рейде как мы не рассматриваешь?

(48) посты были о компе для разработчика. на счет темпа сервер приложений. даже не знаю. там пишутся логи в большом количестве. впринципе может и будет добавка скорости в виде отзывчивости. но в целом производительность не должна добавится. ибо узкое горлышко не должно быть во временных файлах.

(51) Сейчас стоит SAS рейд пятый. Его замена пока не планируется. Серьезный апгрейд не раньше чем через пол-года...
(52) Черт... Логи вряд ли через временные файлы пишутся. Это тогда профиль надо переносить, что ли... Я тоже сильно сомневаюсь, что будет толк...

(53) и у нас sas рейды стоят, и самое дешевое ускорение - заменить контроллер. И так чтоб базы полностью лезли в ssd.

http://www.luxflash.ru/index.php?productID=15779

(52) Интересно... Ладно сервер приложений. А если темпы толстого клиента перенести в рам, будет реальный прирост? Есть у меня один терминальный сервер где можно пару гиг отвести под это дело. Надо будет попробовать...

Скорость нормальных ССД покрывает любые гипотетические простои в следствии их выхода из строя. Но установка ССД под систему, особого прироста не даст, а вот БД, Лог и ТемпДБ на разные ССД - прирост будет такой, что будете согласны ССД менять ежегодно! (если потребуется)
Вообще на инфостарте есть ветка на форуме, там все детально расписано.

(57) Ясен пень. Только стоимость массивов такого размера кусается. Даже только темпДБ выносить на ССД весьма накладно. Сколько, к примеру, стоит гиговый массив ССД серверных стандартов надежности? Просто интересно. Может, уже и недорого...

(57) У нас час простоя стоит 50 тыров. За час простоя на 50 тыров уменьшается чистая прибыль. В среднем. Если простой в пиковое время - то обходится дороже. Более того - восстановление межбэкапного часа, и проблемы из-за выпадения забитого часа если вдруг умрет база - обойдется в жуткую сумму. Поэтому хочется гарантий надежности.

Стоит рейд ssd, до этого был аналогичный сервер с hdd, реально, даже не так - РЕАЛЬНОГО, прироста замечено не было, тестировал одну и ту же базу, на одинаковых серверах с разными типами хардов - на отчетах ни какой существенной разницы (10 - 15%), на перепроведении прирост ощутимей - до 25%.

Но такого, что бы сказать "ВАУ, да это ж ССД" - не было.

Все очень просто, если стоит нормальный рейд хдд, то 1с и/или sql все равно не израсходует все его возможности (я про чтение), а вот был сервер с нулевым рейдом на ххд (не сас а просто хдд рейд эдишион на сата 2), так когда мы перевели сервер на софт рейд Revo Drive 2 (это те что на pci, да да, это не серверные харды, но все же) то там был реальный прирост, отчет который строился 40 минут на ххд, на ссд строился около 15 минут (10 минут - вывод отчета).

(60) При хорошем обновлении базы, добавлении реквизитов, граф отбора, изменении регистров - на семерке происходит несколько последовательных полных чтений базы с диска. И основное время сохранения тратится на это.
На нашей самой большой, 75-гиговой базе сохранение в итоге происходит несколько часов (при 32 гигах оперативки, и 16 отведенных под SQL) - и тут SSD очень бы помогло. Когда база влезала в оперативку - сохранение было на порядки быстрее.

Имхо - прирост производительности от SSD стоит ожидать на больших очередях чтения--записи (типа охрененной кучи мелких файлов), а поскольку SQL активно использует кэш основной памяти - то там выйгрыша можно и не увидеть.

+ (61) И как я говорил - наши потери от простоя 50 тыров в час чистой прибыли.

(63) тогда вообще никаких проблем быть не должно. покупаете девайс и тестите на чем то менее важном и более загруженном с полгода (почта, файловый сервер). потом покупаете второй девайс и ставите в основной сервак.

(63) почтовый сервак нагрузить бевайс не сможет.

Да и статистику на одном серваке (да и на десяти) по отказам мы набрать не сможем.

http://habrahabr.ru/blogs/gtd/139242/