Возможно кому-то будет интересно. Были приобретены два серверных жестких диска 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 и наиболее замеченных в блокировках машин.