Прошу совета в выборе сервера для базы. Прошерстив форум и похожие источники под себя ответа так и не нашел.

MS SQL Server. Приложение MS Dynamics NAV. База порядка 150 Гб. Прирост порядка 10-15 Гб в год.
Сейчас функционирует на HP DL380 на 8 дисках (под базу) в RAID10 15k 72Гб SAS.

По различным причинам косвенно связанным и не связанным с производительностью необходимо подобрать новый сервер. Бюджет 700 тыс рублей.
Хотелось бы значительно увеличить производительность системы. Чтобы даже обычный пользователь сказал - "Во, и правда стало в три раза быстрее!".
Узкое место - дисковая система.

Присматриваюсь системе, которая будет аналогична DL380, но с SSD дисками от HP
http://h30094.www3.hp.com/product.asp?sku=10350616&mfg_part=632502-B21&pagemode=ca
Гарантия 3 года.
Купить таких дисков два в RAID1, один винт в резерв, и несколько дисков SAS 15k 72 Гб под систему и в RAID10 в случае выхода базы за 200 Гб (некритичные по скорости таблицы на них положить через filegroup).

Хотелось бы услышать совет - вырастет ли производительность так чтобы заметить это не только по счетчикам, а по восторженным возгласам пользователей? А также хотелось бы узнать про подводные камни серверных винтов такого уровня. Думаю не зря дают 3 года гарантии.

Eagle_84rahzerХотя порверил по прайсам, такой винт будет стоить примерно 4530$ зависит от поставщика.

У ТС ссылка ведь есть на такой диск, стоимость 4 тыс

по сабжу
а одна лишь дисковая система узкое место или память тоже?
кстати, 8 дисков RAID 10 под базу, а под логи что? tempdb на отдельном диске или все в куче находится?

На самом деле с RAID10 на 8 дисков для базы я слукавил чтобы сэкономить время. На самом деле дисковая система состоит из 16 дисков (на два контроллера по 8 дисков).
2 диска в RAID1 - система и tempdb
4 диска в RAID10 - все таблицы, кроме трех выделенных таблиц с большой нагрузкой
2 диска в RAID1 - первая таблица
2 диска в RAID1 - вторая таблица
2 диска в RAID1 - третья таблица
4 диска в RAID10 - поделены на два логических диска. Тот, что поменьше отдан под ldf. Побольше - уже ни под что. :)

Исторически сложилось именно такое распределение. Три года назад оно казалось наиболее оптимальным. Дело в том, что предприятие с непрерывным производством и некоторой нестабильностью резервного сервера, поэтому экспериментировать с дисковым массивом рабочего сервера возможности нет. Приходится покупать новый сервер и как раз хотелось бы ЗАВЕДОМОГО роста производительности дискового массива.
Память и проц по счетчикам не узкое место.
Если есть идеи, которые ЗАВЕДОМО дадут визуальный (не по счетчикам) прирост производительности за счет переконфигурирования - прошу хотя бы в двух словах описать.

Пока для себя остановился на следующем варианте.

1. Приобретается СХД с двумя SSD дисками в RAID1 по 200 Гб и парой SAS 15K 72Гб.
Эта полка приходит, подкидывается к рабочему серверу и проводится полноценное тестирование. Без особенной остановки производства все должно получиться.

2. Приобретается (позже) еще один сервер уровня DL380 или чуть выше. Этот сервер будет связан с текущим рабочим через эту полку. Это обязательное условие, т.к. для компании критична система восстановления после сбоя. При сбое системы данные должны в течении часа-двух откатиться максимум на 15 минут назад. Сейчас эта система реализована по жуткой системе по сети на нонэйм сервер через разностные бэкапы.

От того, как проявили себя SSD при тестировании п.1. будет принято решение о дисковой системе нового сервера. Если SSD не оправдало себя, то будет приобретаться полноценный массив на SAS 15k и будем с ним мудрить оптимальное распределение. А если SSD зарекоммендует себя как "вау!", то массив на новый сервер впринципе можно будет не приобретать (разве что система и бэкапы более медленными, дешевыми и большими винтами).

Компания в данном случае попадает максимум на 200 тыс рублей затраченные на приобретение двух SSD-дисков. Надеюсь этого не случится.

Разброс между приобретениями планирую порядка 4-5 месяцев что даст полноценную картину о работе SSD.

Ivan_PisarevskyKaktus_Приобретается СХД с двумя SSD дисками в RAID1 по 200 Гб и парой SAS 15K 72Гб.чуднО. :) купите как все нормальные люди дюжину трехсоток.
семидесятки вроде еол, кто-то по дешевке сливает завалящие остатки?

Хм. Просто с последнего приобретения серверного оборудования прошло три года. Видимо потерялся. Погляжу по цена/объем. Спасибо.

KhodKaktus_,

Я бы под темпы выделил отдельный винт.

Да, под логи и под temdb выделю по отдельным шпинделям. По остальному пока не пойму как лучше поступить - все загнать в один большой RAID10 или выделять шпиндели под интенсивные файлгрупы. Но это уже буду тестить.

Возможно кому-то будет интересно. Были приобретены два серверных жестких диска HP SSD 200Gb MLC, о которых я писал в самом начале поста.
Скажу что я ожидал конечно от них большего.
Просто тестирование бэкапами, восстановлениями, тестовыми и рабочими выборками большими, маленькими и т.п. показали что общая производительность выросла порядка полутора раз. Это то, что касается просто производительности без учета иопсов. Сравнивалось с дисковыми массивами на базе HP SAS 72Gb 15K.
База 150 Гб. Разбита на 4 куска - три из них - это с основными самыми нагруженными таблицами, а четвертый со всеми остальными таблицами БД.
Три куска с основными таблицами лежали каждый на RAID1. (4 диска в RAID10 под четвертый кусок и 4 диска в RAID10 под лог и темпдб). Итого 3 RAID1 (под основные таблицы) были заменены на SSD RAID1. Прирост производительности на живой базе оказался нулевой. Проблема иопсов на этих 3-х RAID1 стояла не очень остро, но была. После перехода на SSD ситуация никаким образом не изменилась ни по личным впечатлениям, ни по результатам трассировок, анализа очередей и т.п. Таким образом получается что два SSD заменили шесть SAS 15K.

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

Памяти на сервере 16Гб. Судя по счетчику "Доступно МБ" в профайлере используется около 15Гб. Я тоже грешил на память - была не вся выделена (я закосячил - платформа 64битная, а я ключ воткнул по привычке PAE в boot.ini и счетчик глядел), но уже месяц как все хорошо, а на производительность что 2 Гб было выделено, что 15 Гб вообще никак не отразилось.

alexeyvgKaktus_Если у кого-то будут идеи как расшевелить иопсы и общую производительность SSD-дисков - велкам. :)Так проблема то какая? К SSD большие очереди, а иопсов столько же, как и было на обычных винтах? Или SSD не используется, а тормозит где то ещё?

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

Основная проблема заключается в том, что я не увидел реального роста производительности ни на каких операциях на реальной базе.
Сервер представляет из себя DL380 G5 с 16 Гб RAM
Винты в нескольких массивах:
1. RAID1 два диска система
2. RAID1 два диска - основная таблица проводок около 10 Гб
3. RAID1 два диска - основная таблица товарных операций около 10 Гб
4. RAID1 два диска - основная таблица производства около 10 Гб
5. RAID10 четыре диска все остальные таблицы БД около 70 Гб
6. RAID10 четыре диска лог и tempdb

все винты SAS 15k

БД одна. С ней работают 80 одновременных пользователей.

Проблем катастрофических с торможением не было. Были чувствительные, но непостоянные очереди к массиву 4, чуть менее чувствительные к массиву 3 и еще менее чувствительные к массиву 2.
Пользователи умеренно жаловались на медленную скорость работы программы. Трассировщик по Duration показывает в среднем ежеминутно порыдка 10 запросов длиной 10-30 секунд. Т.е. как бы все не так уж и плохо, но хотелось чтобы было еще лучше. Поэтому массивы 2,3,4 были заменены на RAID1 из двух SSD дисков. И ситуация не изменилась абсолютно. Как говорится "ни на йоту". Я понимаю что могут быть проблемы с запросами и т.п. мы над этим работаем и по мере возможности фиксим и переделываем (плюс обновление статистики, индексы) но я ожидал роста производительности чисто дисковой хотя бы в полтора раза.

По поводу гигабита. У нас довольно большая сеть, построенная на кольце оптики и от нее через несколько плечей уже по 100Мбитным свичам идет разводка. У нас большое количество запросов и обработок построены на многократных запросах к базе. Т.е. не один большой запрос, а сотни-тысячи мелких. И возникла идея - а не является ли сеть узким местом. У сетевых карт же есть какое-то время обработки пакетов, ожидание отклика и если таких пакетов тысяч сто-миллион, то поидее сеть должна быть достаточно узким местом. Поэтому появился вопрос об ускорении работы сетевых карт.
Терминальная работа пока не рассматривается, т.к. к компьютерам пользователей подключена самая разнообразная техника (принтеры, принтеры этикеток, сканеры, накопительные сканеры, весы и т.п.)
Остановился пока я вот на чем - сетевая гигабитная быстрее в 10 раз обрабатывает пакеты относительно 100 Мбитной или она просто работает с более широким каналом и на множестве мелких пакетов не даст выигрыша. Мы как раз сегодня будем тестировать этот нюанс - посмотрим что получится.

В дополнение к предыдущему сообщению хотел уточнить - на сервере у нас стоит гигабит, а вот все клиентские машины 100 Мбитные самые простные карточки.

KhodKaktus_В дополнение к предыдущему сообщению хотел уточнить - на сервере у нас стоит гигабит, а вот все клиентские машины 100 Мбитные самые простные карточки.

И что?
Свичи сами по себе 100-мегабитные или гигабитные?

Свичи 100-мегабитные.

Сегодня провели масштабное тестирование различных обработок на различных по мощности машинах кидая их с 100 мбит в гигабит.

Вобщем усредненный вывод следующий - то, что на селероне 1.7Ггц со 100 мбитной картой считается за n минут, то на Core2Duo со 100 Мбитной картой считается процентов на 15-20 быстрее, а если еще и в гигабит воткнуть, то еще процентов на 15 быстрее.

Так что будем потихоньку апгрейдить парк начиная с самых заметных в трассировках по Duration и наиболее замеченных в блокировках машин.