SQL 2008 1C 7.7 SSD #797181

Итак, есть Server SuperMicro SuperServer 6015BT 2хXeon E5345 2.33Ггц + 16 Gb RAM + 10RAID 4HDD SATA. На всем это хозяйстве стоит Windows 2008R2 + SQL 2008, 1С 7.7 "секретный релиз", работа с базой по сети через файловую шару. Итак попробовал воткнуть в сервер Kingston SSD Fury, залил на него базу, идентичную рабочей, кстати база 31гиг, стоковая Комплексная 7.7. Сделал замер производительности, для примера восстановление последовательности за месяц. 1. 2ч20минут база лежит на RAID 10 из 4HDD SATA 2. 2ч10миунт база лежит на SSD диске. Вообще то думалось что производительность подрастет а тут совсем мизерный выигрыш, почему так ? Настройки баз идентичны, процесс SQL сервера жрет стабильно 10 гигов оперативы. tempdb практически не изменяется в процессе (видимо хватает оперативной памяти). Да и еще не понятно, почему когда выполняются регламентные задания типа ребилда индексов перестройка и пересчет статистик, средствами SQL, (без участия 1С), из 8-ми ядер всегда работает одно (процесс sqlserver ЦП грузит на 13%), видимо тут затык происходит с дисковой подсистемой ? выполнил регламент (Проверка целостности - Перестроение индекса - Реорганизация индекса - Обновление статистики) 1. На RAID 10 - 2ч43м 2. На SSD - 2ч3м вот скорость работы массива Sequential Read (Q= 32,T= 1) : 339.510 MB/s Sequential Write (Q= 32,T= 1) : 213.154 MB/s Random Read 4KiB (Q= 32,T= 1) : 4.968 MB/s [ 1212.9 IOPS] Random Write 4KiB (Q= 32,T= 1) : 0.801 MB/s [ 195.6 IOPS] Sequential Read (T= 1) : 292.732 MB/s Sequential Write (T= 1) : 155.172 MB/s Random Read 4KiB (Q= 1,T= 1) : 0.711 MB/s [ 173.6 IOPS] Random Write 4KiB (Q= 1,T= 1) : 0.698 MB/s [ 170.4 IOPS] А вот скорость работы одиночного SSD Sequential Read (Q= 32,T= 1) : 281.942 MB/s Sequential Write (Q= 32,T= 1) : 166.284 MB/s Random Read 4KiB (Q= 32,T= 1) : 65.173 MB/s [ 15911.4 IOPS] Random Write 4KiB (Q= 32,T= 1) : 162.800 MB/s [ 39746.1 IOPS] Sequential Read (T= 1) : 268.250 MB/s Sequential Write (T= 1) : 166.078 MB/s Random Read 4KiB (Q= 1,T= 1) : 26.596 MB/s [ 6493.2 IOPS] Random Write 4KiB (Q= 1,T= 1) : 59.712 MB/s [ 14578.1 IOPS]

темпы то тоже надо было на ссд положить

+ повыключать на ссд всякие индексирования дисков и прочую муть

tempdb практически не изменяется в процессе (видимо хватает оперативной памяти)

поподробней что за настройки такие ?

А теперь запусти параллельно 15 баз и в каждой запусти "восстановление последовательности за месяц. " Т.е. в монопольном режиме примерно так и будет. А вот когда куча обращений, тогда Sata  диски будут просидать по скорости

Если все эти 15 баз влезут в оперативку для sql сервера то глубоко пофиг какие там hdd или ssd ))

база только одна, размер 31 гигабайт.

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

Нисколько прирост, сколько уменьшения падения производительности при многопользовательской работы Ну т.е. грубо говоря, если раньше 10 пользователей проводили документ и у них выскакивала табличка про блокировку, то сейчас нужно будет 15 пользователей чтобы увидеть эту табличку. P.S. Не стоит забывать что в твоем случае при монопольном доступе дисковая подсистема не является узким местом. Т.е. скорости 10райда достаточно чтобы обеспечить монопольную работу 1с и не тормозить. Обычно узкое место это частота процессора. Т.е. чтобы увидеть прирост, нужно разогнать процессор (или поставить более быстрый процессор, у которого частота на 1 ядро выше чем у твоего)

тогда может не мучать оставить все как есть, систему перенести на SSD. Или же все-таки оставить базу на SSD.

да кто же вас знает зачем вы купили SSD. ИМХО неплохо закинуть туда темп пользователей, а то 1с любить временные DBF создавать

думалось поднимется отзывчиваость базы, все-таки средняя длинна очереди диска крутится в районе 1 и даже больше, а на SSD 0.5.

План электропитания сервера тоже надо проверить, что бы там была "Максимальная производительность". Вообще где-то видел отчет, что ынтерпрайзная версия SQL гораздо активней ядра использует, в отличии от standart, не говоря уж от том, что переиндексировать может в многопользовательском режиме...

Тобишь ты не в курсе как 7.7 работает с SQL? Она фактически просто копирует таблицы в виде dbf в темп пользователя и там делает запросы. Тобишь гораздо больше пользы было бы если именно каталоги пользователя были бы на SSD.

Весь фокус в том что это SQL - он старается по возможности все операции производить в памяти, минимизируя работу с жестким диском. В результате для SQL вполне хватает скорости обычных дисков в вашем случае, ибо режим работы БД с диском близок к линейному чтению. Которое практически одинаковое что у рэйда из HDD, что у SSD. SSD хорош именно на случайном доступе мелкими блоками- Random Read 4KiB (Q= 1,T= 1) : 26.596 MB/s [ 6493.2 IOPS] Random Write 4KiB (Q= 1,T= 1) : 59.712 MB/s [ 14578.1 IOPS] Против Random Read 4KiB (Q= 1,T= 1) : 0.711 MB/s [ 173.6 IOPS] Random Write 4KiB (Q= 1,T= 1) : 0.698 MB/s [ 170.4 IOPS] Явно заметная разница. В итоге - ощутимый выигрыш будет именно в режиме случайного чтения и записи. Если у вас в SQL увеличится количество пользователей, или уменьшится объем памяти - тогда будет больше случайных операций, и будет больше выигрыш от использования SSD.

Да и замеряли вы скорее всего будучи единственным пользователем БД.

Если средняя длина очереди диска один или даже больше это значит что диск в среднем загружен полностью, но справляется в большинстве случаев, т.е особого эффекта от замены не будет. Вот если очередь будет постоянно 2-5 это уже будет ощутимо.