|
Серверный SSD. Субботняя ветка :) | ☑ | ||
---|---|---|---|---|
0
fisher
03.03.12
✎
13:21
|
Есть неслабо загруженный сервер БД он же сервер приложений.
Ессно - винты самое слабое место. Ну, БД ессно на пятом рэйде, все дела... Будет ли реальный прирост производительности, если переложить виндовые и пользовательские темпы (ну, там считай один пользователь - сервер приложений) на SSD? И если да, то какой лучше выбрать? Вроде есть уже вменяемые серверные решения... |
|||
1
fisher
03.03.12
✎
13:23
|
Можно еще прикинуть tempdb туда прописать...
Короче, делитесь опытом :) |
|||
2
fisher
03.03.12
✎
13:25
|
Может, надо было в админскую ветку закинуть? Х.з...
|
|||
3
Beduin
03.03.12
✎
13:49
|
(0) Бери на sls
там где одна ячейка |
|||
4
NS
03.03.12
✎
13:52
|
(0) Мы сейчас думаем о рейде с SSD кешем.
|
|||
5
valeriy vm
03.03.12
✎
13:53
|
не правильны выбор. SSD больше для чтения, при интенсивной перезаписи, т.е. кэш и логи безопаснее на рейде.
|
|||
6
valeriy vm
03.03.12
✎
13:55
|
+ (5) в смысле БД один рейд а кэш и логи на винте простом + система на SSD так будет правильнее
|
|||
7
fisher
03.03.12
✎
13:55
|
(3) Тема скорее не по выбору конкретного SSD (тут однозначно будет выбираться правильный девайс компетентными людьми), а по эффективности его применения.
Стоит овчинка выделки или нет. Просто я не в курсе, насколько сильно тормозят общую производительность при затыке по винтам именно системные темпы и темпы сервера приложений. Стоит ожидать существенного прироста или нет. Какие-то отзывы по переносу tempdb вроде были, но уже не помню... |
|||
8
valeriy vm
03.03.12
✎
13:56
|
еще SSD диски не так долговечны как обычные винты
|
|||
9
fisher
03.03.12
✎
14:00
|
Перенос tembdb пока отпадает. На SSD-массив такого размера пока денег не выбью.
Так что вопрос только по файловым темпам. ЗЫ. Ликбез по SSD мне не требуется. Я в теме. |
|||
10
leshikkam
03.03.12
✎
14:01
|
Ессно - винты самое слабое место. Ну, БД ессно на пятом рэйде, все дела...
Ээ простите а в чем естественность размещения БД на массиве 5-го уровня? |
|||
11
fisher
03.03.12
✎
14:02
|
(10) В том, что это типовое решение цена/скорость/надежность.
|
|||
12
КМ155
03.03.12
✎
14:04
|
(7) без счётчиков производительности топик без предметный
|
|||
13
fisher
03.03.12
✎
14:07
|
(12) А по каким конкретно счетчикам и как именно можно понять, какую именно долю привносят в общую загрузку диска темпы? Скажи, объясни - я замерю.
|
|||
14
Kraft
03.03.12
✎
14:22
|
(10) +многа
|
|||
15
fisher
03.03.12
✎
14:27
|
Системные интеграторы набежали? Ну, да - пятый не десятый. Работаем пока с тем что есть.
|
|||
16
fisher
05.03.12
✎
11:09
|
Понедельничный ап.
|
|||
17
fisher
05.03.12
✎
15:39
|
/
|
|||
18
Midaw
05.03.12
✎
15:43
|
(4) изучите тему. SSD в рейде может не поддерживать TRIM. как работают SSD без TRIM стоит почитать в инете.
|
|||
19
Midaw
05.03.12
✎
15:47
|
(0) самый простой способ в твоем случае разделить сервер приложений от SQL. сервер приложений можно положить на SSD SATA2. если есть возможность поставить SATA3, то можно туда ложить выложить базы SQL.
|
|||
20
NS
05.03.12
✎
15:48
|
(18) Изучаем :)
|
|||
21
NS
05.03.12
✎
15:50
|
(19) А кешу разве TRIM нужен?
|
|||
22
Midaw
05.03.12
✎
15:54
|
(21) TRIM позволяет очистить SSD от старых данных в момент его простоя. винда не умеет через RAID отправлять эти самые команды TRIM. это если кратко. без TRIM диски через некоторое время начинают работать в два раза медленнее.
|
|||
23
NS
05.03.12
✎
16:01
|
(22) То есть рейд должен сам уметь очищать свой кеш в момент простоя?
Или просто иметь нормальные алгоритмы кеширования, которые устойчивы к фрагментации? |
|||
24
NS
05.03.12
✎
16:02
|
Поиск по "Фрагментация кеша" - ничего не дает.
|
|||
25
ОчкарикСлава
05.03.12
✎
16:03
|
(13) по всем физическим дискам процент использования для начала, посмотри график.
Но, имхо, врядли там будет что либо ужасное при обчной работе пользователей с БД. |
|||
26
Midaw
05.03.12
✎
16:08
|
(23) SSD так сделано, что перед тем как записать в ячейку, он должен её очистить. чтоб не тратить лишние такты контроллера на очистку перед записью, он может сделать это заранее. то есть когда контроллеру делать нефиг, он делает очистку TRIM. но без команды процессора он это делать не будет.
|
|||
27
Midaw
05.03.12
✎
16:16
|
(26) вот тут более понятно будет
wiki:TRIM_(команда_SSD) Ограничения TRIM не работает с «виртуальными» дисками, хранящимися в виде образов, что не ограничивает использование команды в виртуальной среде. TRIM не всегда поддерживается в RAID-массивах.[13] [править]Поддержка команды операционными системами и дисками Для старых твердотельных дисков, произведённых до добавления команды TRIM в стандарт ATA, необходимо обновление прошивки — в противном случае, команда будет ими игнорироваться. Команда TRIM поддерживается также не всеми операционными системами. |
|||
28
NS
05.03.12
✎
16:27
|
Я это читал. Получается - вопрос в том, умеют ли рейды в момент простоя очищать старые данные в SSD кеше. Винда это делать совершенно необязана, у рейда есть свой проц.
|
|||
29
Fragster
гуру
05.03.12
✎
16:33
|
(28) новые рейды поддерживают
|
|||
30
NS
05.03.12
✎
16:39
|
(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/ Эти умеют? |
|||
31
Midaw
05.03.12
✎
16:58
|
(30) последнюю железку посмотрел. думаю не только TRIM, но и более блатные вещи умеет :) но можно и ошибиться. например в описании сказано, что потоковая запись у HDD выше. но судя по характеристикам последних SSD. это далеко не так. может железки не знают о таких вещах как SATA3, SAS3. бывает ли последний, я вообще не в курсях.
|
|||
32
Midaw
05.03.12
✎
16:59
|
(31) я бы посмотрел последние тесты IOMeter'а для этой железки и для SSD разных.
|
|||
33
NS
05.03.12
✎
17:03
|
(31) (32) Мы пока ждем пока другие поэксплуатируют.
Не бывает ли безвозвратных смертей рейда на SSD. |
|||
34
Midaw
05.03.12
✎
17:05
|
8+0 портовый SAS 6G RAID контроллер. 40 штук стоит!
(33) рейд он не для того, чтоб всегда можно было восстановить инфу. он только для того, чтоб быстро восстановить инфу во многих случаях. есть случаи когда рейд не поможет, то есть бэкапы нужны в любом случае. |
|||
35
NS
05.03.12
✎
17:08
|
(34) У нас ежечасные бекапы. Но если по статистике окажется что SSD рейд в среднем дохнет раз в полгода - нам такое счастье не нужно.
|
|||
36
Midaw
05.03.12
✎
17:09
|
(35) а у вас есть статистика как часто дохнет SAS RAID не SSD? я думаю если и сдохнет, то это будет не удачный выбор поставщика.
|
|||
37
Midaw
05.03.12
✎
17:15
|
||||
38
Midaw
05.03.12
✎
17:15
|
(37) интел. гарантия на SSD 5 лет.
но есть ограничения есесно http://www.intel.com/support/ru/ssdc/hpssd/sb/CS-032510.htm |
|||
39
NS
05.03.12
✎
17:17
|
(38) Гарантия не означает что в течении гарантийного срока SSD не умрет, либо не сбойнет. И тем более не гарантирует что не будет сбоить рейд. А означает всего-лишь факт гарантийных обязательств в этом случае.
|
|||
40
NS
05.03.12
✎
17:17
|
(36) Из всех рейдов у нас за всё время умер только один. И то без потери информации.
|
|||
41
Midaw
05.03.12
✎
17:19
|
(39) и в чем проблема? сбойный рейд и дальше будет пахать без одного диска, если это как минимум рейд 0+1. даже если все нафиг накрыло, SSD обещает остаться только чтение.
вот тут доступно и понятно, всё тоже самое сказано. http://habrahabr.ru/blogs/hardware/124498/ |
|||
42
NS
05.03.12
✎
17:21
|
(41) Если сбойнет SSD, то в рейд будут записаны неправильные данные, и правильные ты уже никогда оттуда не выцепишь. Иь на данные момент я не вижу гарантий что такого не может произойти.
А когда дохнет рейд (часть дисков в рейде) - информацию восстановить можно. |
|||
43
NS
05.03.12
✎
17:22
|
(41) Статья про SSD рейды, а не про рейды с SSD кешем.
|
|||
44
fisher
05.03.12
✎
17:31
|
И всё-таки, имеет смысл кешировать именно темпы (не своп) на быстрых носителях? Дает это сколько-нибудь заметный прирост? Или нет смысла размениваться по мелочам?
|
|||
45
Midaw
05.03.12
✎
17:32
|
(43) горлышко бутылки. согласен. через пару лет этой проблемы не будет. да и сейчас думаю SSD намного надежнее RAID 10 обычных винтов. но доказывать ничего не буду :)
|
|||
46
fisher
05.03.12
✎
17:32
|
(44) + Тьфу, не кэшировать, а просто выносить на быстрые носители.
|
|||
47
Midaw
05.03.12
✎
17:32
|
(46) не стоит такого делать. производительности не получишь, а надежность будет меньше. это моё мнмение.
|
|||
48
fisher
05.03.12
✎
17:35
|
(47) Хм... Просто пару раз попадались на глаза посты, что дескать вынес темпы на рам-драйв и все залетало чуть ли не в разы быстрее. Чёс?
В принципе, можно попробовать поднять рам-драйв на регистровой памяти... По надежности должно быть приемлемо. |
|||
49
fisher
05.03.12
✎
17:36
|
(48) + Но большого ж объема не поднимешь, только темпы туда засунуть и получится...
|
|||
50
fisher
05.03.12
✎
17:39
|
SSD дело другое. На него можно засунуть и своп...
Про серверные рэйды SSD речь пока не идет... Не тот бюджет пока. |
|||
51
NS
05.03.12
✎
17:42
|
(50) А вариант SSD кеша на рейде как мы не рассматриваешь?
|
|||
52
Midaw
05.03.12
✎
17:50
|
(48) посты были о компе для разработчика. на счет темпа сервер приложений. даже не знаю. там пишутся логи в большом количестве. впринципе может и будет добавка скорости в виде отзывчивости. но в целом производительность не должна добавится. ибо узкое горлышко не должно быть во временных файлах.
|
|||
53
fisher
05.03.12
✎
18:14
|
(51) Сейчас стоит SAS рейд пятый. Его замена пока не планируется. Серьезный апгрейд не раньше чем через пол-года...
(52) Черт... Логи вряд ли через временные файлы пишутся. Это тогда профиль надо переносить, что ли... Я тоже сильно сомневаюсь, что будет толк... |
|||
54
NS
05.03.12
✎
19:06
|
(53) и у нас sas рейды стоят, и самое дешевое ускорение - заменить контроллер. И так чтоб базы полностью лезли в ssd.
|
|||
55
thezos
05.03.12
✎
19:09
|
||||
56
fisher
05.03.12
✎
20:26
|
(52) Интересно... Ладно сервер приложений. А если темпы толстого клиента перенести в рам, будет реальный прирост? Есть у меня один терминальный сервер где можно пару гиг отвести под это дело. Надо будет попробовать...
|
|||
57
Alsh
05.03.12
✎
20:30
|
Скорость нормальных ССД покрывает любые гипотетические простои в следствии их выхода из строя. Но установка ССД под систему, особого прироста не даст, а вот БД, Лог и ТемпДБ на разные ССД - прирост будет такой, что будете согласны ССД менять ежегодно! (если потребуется)
Вообще на инфостарте есть ветка на форуме, там все детально расписано. |
|||
58
fisher
05.03.12
✎
20:40
|
(57) Ясен пень. Только стоимость массивов такого размера кусается. Даже только темпДБ выносить на ССД весьма накладно. Сколько, к примеру, стоит гиговый массив ССД серверных стандартов надежности? Просто интересно. Может, уже и недорого...
|
|||
59
NS
05.03.12
✎
21:04
|
(57) У нас час простоя стоит 50 тыров. За час простоя на 50 тыров уменьшается чистая прибыль. В среднем. Если простой в пиковое время - то обходится дороже. Более того - восстановление межбэкапного часа, и проблемы из-за выпадения забитого часа если вдруг умрет база - обойдется в жуткую сумму. Поэтому хочется гарантий надежности.
|
|||
60
DitriX
05.03.12
✎
23:47
|
Стоит рейд ssd, до этого был аналогичный сервер с hdd, реально, даже не так - РЕАЛЬНОГО, прироста замечено не было, тестировал одну и ту же базу, на одинаковых серверах с разными типами хардов - на отчетах ни какой существенной разницы (10 - 15%), на перепроведении прирост ощутимей - до 25%.
Но такого, что бы сказать "ВАУ, да это ж ССД" - не было. Все очень просто, если стоит нормальный рейд хдд, то 1с и/или sql все равно не израсходует все его возможности (я про чтение), а вот был сервер с нулевым рейдом на ххд (не сас а просто хдд рейд эдишион на сата 2), так когда мы перевели сервер на софт рейд Revo Drive 2 (это те что на pci, да да, это не серверные харды, но все же) то там был реальный прирост, отчет который строился 40 минут на ххд, на ссд строился около 15 минут (10 минут - вывод отчета). |
|||
61
NS
06.03.12
✎
01:23
|
(60) При хорошем обновлении базы, добавлении реквизитов, граф отбора, изменении регистров - на семерке происходит несколько последовательных полных чтений базы с диска. И основное время сохранения тратится на это.
На нашей самой большой, 75-гиговой базе сохранение в итоге происходит несколько часов (при 32 гигах оперативки, и 16 отведенных под SQL) - и тут SSD очень бы помогло. Когда база влезала в оперативку - сохранение было на порядки быстрее. |
|||
62
BigHarry
06.03.12
✎
01:23
|
Имхо - прирост производительности от SSD стоит ожидать на больших очередях чтения--записи (типа охрененной кучи мелких файлов), а поскольку SQL активно использует кэш основной памяти - то там выйгрыша можно и не увидеть.
|
|||
63
NS
06.03.12
✎
01:25
|
+ (61) И как я говорил - наши потери от простоя 50 тыров в час чистой прибыли.
|
|||
66
Midaw
06.03.12
✎
09:18
|
(63) тогда вообще никаких проблем быть не должно. покупаете девайс и тестите на чем то менее важном и более загруженном с полгода (почта, файловый сервер). потом покупаете второй девайс и ставите в основной сервак.
|
|||
67
NS
06.03.12
✎
10:03
|
(63) почтовый сервак нагрузить бевайс не сможет.
|
|||
68
NS
06.03.12
✎
10:11
|
Да и статистику на одном серваке (да и на десяти) по отказам мы набрать не сможем.
|
|||
69
Midaw
06.03.12
✎
10:20
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |