Имя: Пароль:
IT
Админ
Сервер для 1С на SSD
0 Aksakal
 
23.11.11
13:37
Приветствую, коллеги!
Имеется база ТиС 7.7 (SQL), за три года размер превысил 20 Гб. Принято решение переходить на 8.2, под это дело будет приобретаться новое оборудование, решено рассмотреть сервер SQL на массиве SSD с целью повышения производительности и снижения стоимости. Кто-нибудь реально внедрял такое? Если да, то какие диски, контроллер, конфигурация массива? Любые мнения, советы и замечания приветствуются
1 Septera
 
23.11.11
13:42
Работал в организации где на SSD PostgreSQL крутился, в среднем диска хватало на полгода, потом неменуемо цикл перезаписи заканчивался. Мое мнение что технология еще сырая, лучше построить правильный RAID массив который даст прирост и дольше проживет.
2 kauksi
 
23.11.11
13:44
принципиально быстрее в серверном SQL режиме не будет. дороже - да
проще 10й райд на обычных винтах и больше памяти, которую SQL любит
3 ptiz
 
23.11.11
13:45
(2) +1
4 Aksakal
 
23.11.11
13:46
(1) Какой объём базы? Какой объём дисков? По отзывам, заполнение SSD должно быть не более 40%, тогда жить будет долго.
(2) То есть RAID 10 на дисках SAS и контроллере с памятью не менее 512 Мб даст результат не сильно хуже?
5 ptiz
 
23.11.11
13:49
Поставь на SQL-сервер оперативки как размер базы и очереди на диск не будет.
6 Ленинград
 
23.11.11
13:51
(5)ололо
7 FN
 
23.11.11
13:56
SSD+SQL = прирост скорости минимальный
SSD+DBF = прирост скорости максимальный
это для 7.7, думаю для 8.х ниче не поменяется
8 Ленинград
 
23.11.11
13:57
(7)База в 77 20 гигов, файлов вариант в 8 - вы бредите мисье?
9 Septera
 
23.11.11
13:58
(4) баз было несклько, в общем итоге гигов 40 занимали, диск примерно 72 гига, я знаю что в отзывах пишут... на деле это подрыв в 3 часа ночи от звонка дира со всеми вытекающими
+ не знаю насчет SAS, но я хочу попробывать raid на sata 3 дисках с поддержкой AHCI попробывать, вроде хвалят за надежность скорость и недороговизну
10 vis_tmp
 
23.11.11
13:59
Тему IAmAlexey вчера читали по SSD?
11 Гефест
 
23.11.11
14:00
(9) Кстати да, любят SSD умирать именно в 3 часа ночи
12 FN
 
23.11.11
14:03
(8) да может там тупо регистры не закрываются - и реального размера 1-2 гига
13 Ленинград
 
23.11.11
14:04
(12)Ну как вариант, но все же в 4Гб он очень быстро упрется
14 Aksakal
 
23.11.11
14:05
(5) Всё равно обмен с диском будет, и немаленький
(7) Файловый вариант - вообще не вариант на таких объёмах
(9) Думаю, если бы SSD был 240 Гб или больше, жил бы в разы дольше. Переход на SATA 3 в реале особо скорости не добавляет, для сервера SATA только как бюджетный вариант, желательно raid edition
15 Aksakal
 
23.11.11
14:06
(10) Дайте ссылку, пожста, не могу найти
16 Septera
 
23.11.11
14:09
(14) та ладно... насчет прироста это ты сурьезно?))
17 Lionee
 
23.11.11
14:11
SQL на массиве SSD  никогда !!!
чтоб умерло в один прекрасный день, точнее в ночь )))
лучше на sata
18 Alexor
 
23.11.11
14:14
(14) Если база 20 гигов, контора подозреваю не мелкая?
Я бы не экономил я брал SAS в рейде.
19 kauksi
 
23.11.11
14:17
Если затык именно в дисковой системе 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 раза производительность,
оборудования должна возростать в корень из двух раз.
в не зависимости от системы.
20 Aksakal
 
23.11.11
14:19
(16) Для обычных дисков(не SSD) почти ничего не даёт. http://forums.overclockers.ru/viewtopic.php?t=374559
(17) Я всё равно не могу понять, как может умереть ВСЁ СРАЗУ. RAID вроде же для того и создан, чтобы отказ одного диска не привёл к краху системы.
(18) Не мелкая, но средства не разбазаривают. Кроме того, хочется изучить этот вопрос всесторонне, и, может быть, впервые в своей практике опробовать SSD в сервере.
21 Ленинград
 
23.11.11
14:20
(19)Я бы таки темпдб убрал отдельно, да и смысл на лог. диски разбивать? для порядку?
22 Ленинград
 
23.11.11
14:21
(20)Рейд в состоянии Degraded страшная вещ ))
23 Septera
 
23.11.11
14:22
(20) прирост кпд от обычного использования SATA 3 конечно сложно заметить, Но не путайте с Sata 3 + AHCI, это примерно 25% прироста к кпд, при раздельном использовании базы, винды и свопа это видно как ясный день
24 Ленинград
 
23.11.11
14:24
(23)Своп можно оперативкой заменить чтобы винты не грузить, благо память сейчас копеечная
25 Septera
 
23.11.11
14:24
(19) все... можно уходить из топика, профи пришли)) нет сурьезно, так поделить - брависимо!!
26 Septera
 
23.11.11
14:25
(24) хто бы спорил))
27 Alexor
 
23.11.11
14:25
Я бы если так хочется, бы сделал на ССД систему, темповые файлы, системный скульные, и как вариант ldf

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

Да и памяти в скуль бы 32 гига надо.
28 MaxS
 
23.11.11
14:26
Где-то видел контроллер, предназначенный для подключения к нему SSD и HDD дисков... С первого быстро читают, на второй быстро пишут...
29 Aksakal
 
23.11.11
14:26
(19) По п.3 не соглашусь. Вам не доводилось на живой базе случайно прибивать лог транзакций? У меня по юности было. Воспоминания смутные, но безрадостные.
По п.1 - tempdb таки многие гуру настоятельно рекомендуют выделять на отдельный массив
30 Ленинград
 
23.11.11
14:26
(27)+Винда х64, скуль х64
31 Alexor
 
23.11.11
14:27
(28) Я читал, что у свежих интеловских чипсетов такая функция появилась. Но вроде мамки не серверные.
32 Aksakal
 
23.11.11
14:27
(24) Соглашусь, я сейчас даже в супербюджетные самосборные "сервера" 16 Гб ставлю, чтоб "поставил и забыл"
33 Ленинград
 
23.11.11
14:27
(28)Есть такая фишка у Адаптека MaxIQ называется, там образно говоря подключенный ССД диск к массиву выступает в качестве кеша. То есть фактически скорость записи имеем от ССД, а скорость чтения зависит от того рейда который сделали
34 Fragster
 
гуру
23.11.11
14:29
кстати, один у нас таки умер через 9 месяцев в рознице
35 Aksakal
 
23.11.11
14:30
(28) Технология Adaptec MaxIQ, http://www.thg.ru/storage/adaptec_maxiq/, читайте сразу заключение и выводы
36 MaxS
 
23.11.11
14:31
(33)  да и про это  читал. Но тут SSD небольшой для кэша и HDD большой.
А есть ещё SSD и HDD  одинаковые, в рейде.
37 Aksakal
 
23.11.11
14:31
(30) А кто-то разве ещё ставит x32 ???
38 Ленинград
 
23.11.11
14:35
(37)А мало ли?
39 Alexor
 
23.11.11
14:38
У интела технология Smart Response
http://www.ixbt.com/mainboard/i68z-chipset.shtml
40 1Снег
 
23.11.11
14:43
(19), (29)
Размещение файлов БД, "tempdb", логов (redo log, transaction log или иное, смотря какая у вас СУБД) и их бекапов
на отдельных дисках vs один RAID10 из всех дисков
..
Моё мнение таково: если ваша база не на сотни гигабайт и более, с количеством транзакций в секунду в десятки тысяч и более, а дисковая подсистема не СХД среднего уровня или выше со многими десятками или сотнями дисков, то помните, что в этом случае здесь есть два конкурирующих аспекта: производительность и надежность.
И в этом случае в производительности вы ПРОИГРАЕТЕ(!), а в надежности можете выиграть только от размещения логов на другом массиве, созданном на отдельной группе дисков (про отдельный контроллер молчу, его с 99% вероятности у вас в системе просто не будет).
http://forum.ixbt.com/topic.cgi?id=66:7234
41 Ленинград
 
23.11.11
14:47
(40)На самом деле правда в этом есть )
42 Aksakal
 
23.11.11
15:00
(40) "И в этом случае в производительности вы ПРОИГРАЕТЕ(!)"
Уточните пожалуйста, вы говорите про отдельные диски или про RAID10 из всех дисков?
43 Axel2009
 
23.11.11
15:02
забейте на SSD, рейд с SAS за глаза для 1с. это потолок производительности
44 1Снег
 
23.11.11
15:05
(42) RAID10 из всех дисков будет быстрее
45 myk0lka
 
23.11.11
15:12
Сорри, влезу со своим вопросом:
на сколько сильно влияет на производительность разрядность серверной ОСи?
46 Alexor
 
23.11.11
15:16
(45) Все зависит от приложений используемых.
47 myk0lka
 
23.11.11
15:18
(46) Скуль энтерпрайз эдишн.
48 myk0lka
 
23.11.11
15:19
+(47) на нём 2 базы по 60Гб.
49 Aksakal
 
23.11.11
23:04
(47) К примеру, WinRAR x64 не более чем на 5% быстрее своего x32 собрата. А вообще, главное отличие 32-разрядных процессов от 64-разрядных - невозможность прямой адресации памяти свыше 3 Гб. Но SQL поддерживает т.н. AWE, и может адресовать больше памяти. MS утверждает, что в следующих релизах SQL отключит эту фичу (думаю, просто перестанет выпускать x32 версии). Подробнее http://msdn.microsoft.com/ru-ru/library/ms190673.aspx
50 Aksakal
 
23.11.11
23:09
(47) Вдогонку. Лично моё мнение - уже давно пора прекратить использование х32 приложений в серверах, да и операционки уже должны быть только х64, как и приложения под них.
51 Aleksey
 
23.11.11
23:11
(31) Там другая система. Z68 для redyBoost SSD винт может юзать
52 Aksakal
 
24.11.11
00:08
(51) Они опять придумали новый разъём на матери, теперь под SSD, якобы чтобы можно было компактно разместить его на матери. Самое интересное, что это будет тот же SATA, соответственно, и скорости другие. По тому же пути пошла OSZ, но гораздо честнее - выпустила программно-аппаратный продукт, который можно поставить в любую матплату. Подробнее http://www.ocztechnology.com/ocz-synapse-cache-sata-iii-2-5-ssd.html
53 Aksakal
 
24.11.11
00:11
(51) Вдогонку. Оказывается, OSZ Synapse уже есть в России, ценник менее 5к за 64 Гб версию. Вполне приемлемо
54 Axel2009
 
24.11.11
10:41
(53) а вы тестировали SSD диски и 1с вместе?
55 Aksakal
 
24.11.11
13:51
(54) Тестировал отдельно взятый Corsair Force 3 на домашнем компьютере. Быстрее, конечно, но не в разы. К слову, у меня и обычный диск один из самых быстрых среди SATA 7200. Это и понятно: у меня не SQL, а именно SQL очень требовательна к дисковым операциям. На SQL, по сравнению с одиночным традиционным накопителем, разница будет ощутимее. Но на одиночных дисках серьёзные базы ставят только психи :) Вообще для каких-то тяжёлых операций с маленькими базами в файловом достаточно RAM-диска, проведите эксперимент, и Вы поймёте, насколько несовершенен файловый движок БД у 1С
56 Axel2009
 
24.11.11
14:01
(55) а я тестил перегрузку данных в рамках 1с как файловой так и клиент-серверной. файловая база работает в 6 раз быстрее чем клиент-серверная на ССД дисках. потому как нет "передаста" в виде сервера 1с, который не масштабируется и уперается в производительность процессора. да и то поставив даже самый мощный проц ССД диски будут стоять на 90%.
57 FN
 
24.11.11
14:25
(55) Да забудь ты про sql+ssd - не стоит оно того. На файловых операциях - да(!) ССД рвет рейды на обычных и даже скйзевых винтах, но при использовании скуля для 1С - ничего ты толком не получишь.

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

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

Это все актуально для 7.7
58 DGorgoN
 
24.11.11
16:06
(0) Дохнут они быстро.. очень быстро. Тупо не рекомендую..
59 Aksakal
 
24.11.11
17:56
(55) А я пробовал в файловом варианте пометку на удаление всех доков и затем контроль и удаление штатной процедурой. Особой разницы не увидел даже на RAM-диске. Думаю, 1cd при достаточном объёме памяти эффективно кэшируется, поэтому разница невелика. SQL на SSD не пробовал.
60 Aksakal
 
24.11.11
17:57
(57) Уже принято решение брать нормальный контроллер и SAS диски
61 Aksakal
 
24.11.11
18:07
(58) Спасибо за рекомендацию.
В процессе изучения проблемы выяснил много интересного, например о SSD дисках Hitachi, созданные в партнёрстве с Intel на SLC флеш специально для корпоративного рынка, которые отличаются повышенной живучестью. Но предложений по таким дискам в России я не нашёл. А ещё пришёл к выводу, что через два-три года, скорее всего, начнётся массовый переход на SSD, а следом высока вероятность устаревания SATA. Когда технология избавится от "детских" болезней, не останется никаких препятствий для перехода на бесшумные, быстрые и долговечные накопители. Всплывает аналогия с ЖК-мониторами, которые сначала тоже не дотягивали до ЭЛТ, и всем казалось, что никогда не дотянут, а сейчас это кажется таким само собой разумеющимся.
Закон Брукера: Даже маленькая практика стоит большой теории.