Приветствую, коллеги!
Имеется база ТиС 7.7 (SQL), за три года размер превысил 20 Гб. Принято решение переходить на 8.2, под это дело будет приобретаться новое оборудование, решено рассмотреть сервер SQL на массиве SSD с целью повышения производительности и снижения стоимости. Кто-нибудь реально внедрял такое? Если да, то какие диски, контроллер, конфигурация массива? Любые мнения, советы и замечания приветствуются

Работал в организации где на SSD PostgreSQL крутился, в среднем диска хватало на полгода, потом неменуемо цикл перезаписи заканчивался. Мое мнение что технология еще сырая, лучше построить правильный RAID массив который даст прирост и дольше проживет.

принципиально быстрее в серверном SQL режиме не будет. дороже - да
проще 10й райд на обычных винтах и больше памяти, которую SQL любит

(2) +1

(1) Какой объём базы? Какой объём дисков? По отзывам, заполнение SSD должно быть не более 40%, тогда жить будет долго.
(2) То есть RAID 10 на дисках SAS и контроллере с памятью не менее 512 Мб даст результат не сильно хуже?

Поставь на SQL-сервер оперативки как размер базы и очереди на диск не будет.

(5)ололо

SSD+SQL = прирост скорости минимальный
SSD+DBF = прирост скорости максимальный
это для 7.7, думаю для 8.х ниче не поменяется

(7)База в 77 20 гигов, файлов вариант в 8 - вы бредите мисье?

(4) баз было несклько, в общем итоге гигов 40 занимали, диск примерно 72 гига, я знаю что в отзывах пишут... на деле это подрыв в 3 часа ночи от звонка дира со всеми вытекающими
+ не знаю насчет SAS, но я хочу попробывать raid на sata 3 дисках с поддержкой AHCI попробывать, вроде хвалят за надежность скорость и недороговизну

Тему IAmAlexey вчера читали по SSD?

(9) Кстати да, любят SSD умирать именно в 3 часа ночи

(8) да может там тупо регистры не закрываются - и реального размера 1-2 гига

(12)Ну как вариант, но все же в 4Гб он очень быстро упрется

(5) Всё равно обмен с диском будет, и немаленький
(7) Файловый вариант - вообще не вариант на таких объёмах
(9) Думаю, если бы SSD был 240 Гб или больше, жил бы в разы дольше. Переход на SATA 3 в реале особо скорости не добавляет, для сервера SATA только как бюджетный вариант, желательно raid edition

(10) Дайте ссылку, пожста, не могу найти

(14) та ладно... насчет прироста это ты сурьезно?))

SQL на массиве SSD  никогда !!!
чтоб умерло в один прекрасный день, точнее в ночь )))
лучше на sata

(14) Если база 20 гигов, контора подозреваю не мелкая?
Я бы не экономил я брал SAS в рейде.

Если затык именно в дисковой системе SQL-сервера, то лекарство там достаточно простое.
1. Выделяем 2 физических винта, объединяем их в RAID-1. Делаем на них 3 раздела:
- C - под ось и софт (гиг на 20-40, все по дефолту)
- D - под своп винды (гиг на 16, размер кластера - 64К, индексирование выключить)
- E - под системные базы MSSQL - master, model, msdb, tempdb (все остальное место, размер кластера - 64К, индексирование выключить)
2. Выделяем 4 физических винта, объединяем их в RAID-10, делаем один раздел, размер кластера и страйпа - 64К, индексирование выключить. Заливаем туда сами базы (*.mdb)
3. Выделяем 2 физических винта, объединяем их в RAID-0, делаем один раздел, размер кластера - 64К, индексирование выключить. Заливаем туда транзакшн логи (*.ldf)
4. Выделяем отдельную машину под бэкапы, с гигабитной сетью и резиновыми винтами. Настраиваем туда бэкап логов - каждые 4 часа, и ежедневный бэкап всей базы

Закон мура о количестве пользователей и оборудовании
при увеличении количества пользователев 2 раза производительность,
оборудования должна возростать в корень из двух раз.
в не зависимости от системы.

(16) Для обычных дисков(не SSD) почти ничего не даёт. http://forums.overclockers.ru/viewtopic.php?t=374559
(17) Я всё равно не могу понять, как может умереть ВСЁ СРАЗУ. RAID вроде же для того и создан, чтобы отказ одного диска не привёл к краху системы.
(18) Не мелкая, но средства не разбазаривают. Кроме того, хочется изучить этот вопрос всесторонне, и, может быть, впервые в своей практике опробовать SSD в сервере.

(19)Я бы таки темпдб убрал отдельно, да и смысл на лог. диски разбивать? для порядку?

(20)Рейд в состоянии Degraded страшная вещ ))

(20) прирост кпд от обычного использования SATA 3 конечно сложно заметить, Но не путайте с Sata 3 + AHCI, это примерно 25% прироста к кпд, при раздельном использовании базы, винды и свопа это видно как ясный день

(23)Своп можно оперативкой заменить чтобы винты не грузить, благо память сейчас копеечная

(19) все... можно уходить из топика, профи пришли)) нет сурьезно, так поделить - брависимо!!

(24) хто бы спорил))

Я бы если так хочется, бы сделал на ССД систему, темповые файлы, системный скульные, и как вариант ldf

mdb на отдельный диск с зеркалом хотябы сата, но лучше sas

Да и памяти в скуль бы 32 гига надо.

Где-то видел контроллер, предназначенный для подключения к нему SSD и HDD дисков... С первого быстро читают, на второй быстро пишут...

(19) По п.3 не соглашусь. Вам не доводилось на живой базе случайно прибивать лог транзакций? У меня по юности было. Воспоминания смутные, но безрадостные.
По п.1 - tempdb таки многие гуру настоятельно рекомендуют выделять на отдельный массив

(27)+Винда х64, скуль х64

(28) Я читал, что у свежих интеловских чипсетов такая функция появилась. Но вроде мамки не серверные.

(24) Соглашусь, я сейчас даже в супербюджетные самосборные "сервера" 16 Гб ставлю, чтоб "поставил и забыл"

(28)Есть такая фишка у Адаптека MaxIQ называется, там образно говоря подключенный ССД диск к массиву выступает в качестве кеша. То есть фактически скорость записи имеем от ССД, а скорость чтения зависит от того рейда который сделали

кстати, один у нас таки умер через 9 месяцев в рознице

(28) Технология Adaptec MaxIQ, http://www.thg.ru/storage/adaptec_maxiq/, читайте сразу заключение и выводы

(33)  да и про это  читал. Но тут SSD небольшой для кэша и HDD большой.
А есть ещё SSD и HDD  одинаковые, в рейде.

(30) А кто-то разве ещё ставит x32 ???

(37)А мало ли?

У интела технология Smart Response
http://www.ixbt.com/mainboard/i68z-chipset.shtml

(19), (29)
Размещение файлов БД, "tempdb", логов (redo log, transaction log или иное, смотря какая у вас СУБД) и их бекапов
на отдельных дисках vs один RAID10 из всех дисков
..
Моё мнение таково: если ваша база не на сотни гигабайт и более, с количеством транзакций в секунду в десятки тысяч и более, а дисковая подсистема не СХД среднего уровня или выше со многими десятками или сотнями дисков, то помните, что в этом случае здесь есть два конкурирующих аспекта: производительность и надежность.
И в этом случае в производительности вы ПРОИГРАЕТЕ(!), а в надежности можете выиграть только от размещения логов на другом массиве, созданном на отдельной группе дисков (про отдельный контроллер молчу, его с 99% вероятности у вас в системе просто не будет).
http://forum.ixbt.com/topic.cgi?id=66:7234

(40)На самом деле правда в этом есть )

(40) "И в этом случае в производительности вы ПРОИГРАЕТЕ(!)"
Уточните пожалуйста, вы говорите про отдельные диски или про RAID10 из всех дисков?

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

(42) RAID10 из всех дисков будет быстрее

Сорри, влезу со своим вопросом:
на сколько сильно влияет на производительность разрядность серверной ОСи?

(45) Все зависит от приложений используемых.

(46) Скуль энтерпрайз эдишн.

+(47) на нём 2 базы по 60Гб.

(47) К примеру, WinRAR x64 не более чем на 5% быстрее своего x32 собрата. А вообще, главное отличие 32-разрядных процессов от 64-разрядных - невозможность прямой адресации памяти свыше 3 Гб. Но SQL поддерживает т.н. AWE, и может адресовать больше памяти. MS утверждает, что в следующих релизах SQL отключит эту фичу (думаю, просто перестанет выпускать x32 версии). Подробнее http://msdn.microsoft.com/ru-ru/library/ms190673.aspx

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

(31) Там другая система. Z68 для redyBoost SSD винт может юзать

(51) Они опять придумали новый разъём на матери, теперь под SSD, якобы чтобы можно было компактно разместить его на матери. Самое интересное, что это будет тот же SATA, соответственно, и скорости другие. По тому же пути пошла OSZ, но гораздо честнее - выпустила программно-аппаратный продукт, который можно поставить в любую матплату. Подробнее http://www.ocztechnology.com/ocz-synapse-cache-sata-iii-2-5-ssd.html

(51) Вдогонку. Оказывается, OSZ Synapse уже есть в России, ценник менее 5к за 64 Гб версию. Вполне приемлемо

(53) а вы тестировали SSD диски и 1с вместе?

(54) Тестировал отдельно взятый Corsair Force 3 на домашнем компьютере. Быстрее, конечно, но не в разы. К слову, у меня и обычный диск один из самых быстрых среди SATA 7200. Это и понятно: у меня не SQL, а именно SQL очень требовательна к дисковым операциям. На SQL, по сравнению с одиночным традиционным накопителем, разница будет ощутимее. Но на одиночных дисках серьёзные базы ставят только психи :) Вообще для каких-то тяжёлых операций с маленькими базами в файловом достаточно RAM-диска, проведите эксперимент, и Вы поймёте, насколько несовершенен файловый движок БД у 1С

(55) а я тестил перегрузку данных в рамках 1с как файловой так и клиент-серверной. файловая база работает в 6 раз быстрее чем клиент-серверная на ССД дисках. потому как нет "передаста" в виде сервера 1с, который не масштабируется и уперается в производительность процессора. да и то поставив даже самый мощный проц ССД диски будут стоять на 90%.

(55) Да забудь ты про sql+ssd - не стоит оно того. На файловых операциях - да(!) ССД рвет рейды на обычных и даже скйзевых винтах, но при использовании скуля для 1С - ничего ты толком не получишь.

Вот только что провел минитест:
простой запрос
Select * from _1SJOURN
where Docno like '%1000%'
на ноуте с ССД время выполнения 4157, на "серваке" с обычными винтами в зеркале - 4065

А вот если запустить в файловой базе обычную реиндексацию - там ССД покажет себя во всей красе - разница может быть и в десятки раз (смотря что за ССД и с чем сравнивать)

Это все актуально для 7.7

(0) Дохнут они быстро.. очень быстро. Тупо не рекомендую..

(55) А я пробовал в файловом варианте пометку на удаление всех доков и затем контроль и удаление штатной процедурой. Особой разницы не увидел даже на RAM-диске. Думаю, 1cd при достаточном объёме памяти эффективно кэшируется, поэтому разница невелика. SQL на SSD не пробовал.

(57) Уже принято решение брать нормальный контроллер и SAS диски

(58) Спасибо за рекомендацию.
В процессе изучения проблемы выяснил много интересного, например о SSD дисках Hitachi, созданные в партнёрстве с Intel на SLC флеш специально для корпоративного рынка, которые отличаются повышенной живучестью. Но предложений по таким дискам в России я не нашёл. А ещё пришёл к выводу, что через два-три года, скорее всего, начнётся массовый переход на SSD, а следом высока вероятность устаревания SATA. Когда технология избавится от "детских" болезней, не останется никаких препятствий для перехода на бесшумные, быстрые и долговечные накопители. Всплывает аналогия с ЖК-мониторами, которые сначала тоже не дотягивали до ЭЛТ, и всем казалось, что никогда не дотянут, а сейчас это кажется таким само собой разумеющимся.