Вход | Регистрация

  1  2   
Информационные технологии :: Администрирование

Подбор сервера под нужды 1С

Подбор сервера под нужды 1С
Я
   Mamont_SXI
 
10.10.16 - 13:35
Добрый день форумчане!
Собираемся покупать новый сервер под 1С.
На нём будет стоять Winwows Server, крутиться  SQL и сервер 1С. Объём базы порядка 30 Гб. терминала не будет.
Интересует какой брать процессор Е3 или Е5 и в каком количестве (сильно ли измениться производительность) или лучше сделать упор на память? С какими параметрами сервера 1С работает быстрее(Режим распределения нагрузки - приоритет по производительности или о памяти)
 
 
   Волшебник
 
Модератор
1 - 10.10.16 - 13:37
упор на диски
   Mamont_SXI
 
3 - 10.10.16 - 13:39
(1) предлагаешь использовать ssd?
   Cyberhawk
 
4 - 10.10.16 - 13:44
"терминала не будет. " // Т.е. работать в конфигураторе с этой базой будут с клиентских машин?
   Boleev
 
5 - 10.10.16 - 13:45
   zak555
 
6 - 10.10.16 - 13:48
что за конфа ?
   Mamont_SXI
 
7 - 10.10.16 - 13:54
(4) да, только с клиентских
   Mamont_SXI
 
8 - 10.10.16 - 13:55
(6) ут 11.2
   Волшебник
 
Модератор
9 - 10.10.16 - 13:57
(3) SSD надо использовать правильно. Главное, оставляй резерв свободного места 70%. Минимум нужно 50% свободного места, но у вас база вырастет же, значит диск должен быть 128 Гб. И надо следить за износом ячеек. Так что лучше сразу взять 240 Гб, чтобы раньше времени не крякнулся.
   MrStomak
 
10 - 10.10.16 - 13:59
(1) Чем обосновывается упор на диски?
(9) Нужно как минимум 2 диска в зеркальном рейде, при этом использовать raid-контроллер, поддерживающий TRIM для дисков. Это если на ssd делать
 
 Рекламное место пустует
   H A D G E H O G s
 
11 - 10.10.16 - 14:00
raid ssd под данные
дешевый отдельный ssd под лог+tempdb+tmp 1C
HDD под бэкапы, систему и образ системы
32 гига оперативки
Intel на вкус и оставшиеся средства.
   H A D G E H O G s
 
12 - 10.10.16 - 14:02
(10) "Чем обосновывается упор на диски?"
Правильными алгоритмами, которые не заставят SQL елозить по данным в памяти, дикими nestedloop-ами.
   MrStomak
 
13 - 10.10.16 - 14:03
(12) Это не обоснование "упора на диски"
   arsik
 
14 - 10.10.16 - 14:03
(0) Я обычно вот тут обсуждаю серрвера для 1С.http://3nity.ru/viewforum.php?f=40&sid=712a01d6793df41243eb8b3349f9088f
Не реклама. Нормально ребята помогают.
   oleg_km
 
15 - 10.10.16 - 14:04
(11) Можно тогда 64 гига оперативки и 20-30 рамдиск для темпов. Очень помогает.

(12) Ну если бы СУБД не нужны были диски - их бы давно уже выкинули. К сожалению все равно приходится какое-то данные считывать с диска.
   Fragster
 
16 - 10.10.16 - 14:06
проще под темпы и сеансовые данные сделать рэмбрайв на 8-16 ГБ (это для 1с), а базу на нормальный sas. Это будет не сильно медленнее SSD, но зато места намного больше. не будет проблем развернуть рядом еще пару-тройку копий баз
   MrStomak
 
17 - 10.10.16 - 14:07
(11)
Ага, прекрасно.
Например, Intel® Xeon® Processor E3-1258L v4 с базовой тактовой частотой 1.8Ghz прекрасно подойдёт, да?
   MrStomak
 
18 - 10.10.16 - 14:07
(16) +100500
   Midaw
 
19 - 10.10.16 - 14:07
(16) если уже ВР про SSD на сервере говорит, то это уже грех не использовать их )))
   Волшебник
 
Модератор
20 - 10.10.16 - 14:09
(10) Ни процессор, ни память обычно не являются узкими местами для работы с 1С.
   Cyberhawk
 
21 - 10.10.16 - 14:14
(12) А к чему тут сказано про упоминание о памяти? Чтобы не елозить в памяти, нужно не елозить в данных, которые в эту память попадают с диска.
   H A D G E H O G s
 
22 - 10.10.16 - 14:19
(16) Копию развернете на HDD.
   H A D G E H O G s
 
23 - 10.10.16 - 14:20
(21) Это вы разработчикам типовых говорите, не мне.
Жесть УТ11.2, как она есть.
   H A D G E H O G s
 
24 - 10.10.16 - 14:20
(17) Откуда столько негатива?
   Дарлок
 
25 - 10.10.16 - 14:28
(24) продажники "инсталляторв" будут впаривать другое, еще потом до кучи и 5E raid настроят.
Это если конечно техника брендовая
   Cyberhawk
 
26 - 10.10.16 - 14:28
(23) Ты что-то юлишь. Про память все-таки объясни пож-та в контексте (12) и (21).
   Cyberhawk
 
27 - 10.10.16 - 14:30
+(26) Я не один, кто не понял твоей мысли про память, вон (13) тоже не согласен с таким обоснованием упора на диски :)
   Дарлок
 
28 - 10.10.16 - 14:35
(27) сколько сейчас предел по объему ОЗУ?
   PR
 
29 - 10.10.16 - 14:37
(20) Процессор еще как является
   MrStomak
 
30 - 10.10.16 - 14:37
(24)
На мой взгляд, есть тенденция к переоценке преимуществ ssd в задачах работы с базами данных. Понятно, что Windows на ssd грузится в 10 раз быстрее, скорость чтения случайных данных у него прекрасная.
Однако, для задач СУБД всё же активно используется кэш MS SQL(для чтения) и кэш raid-контроллера(для записи). Это во многом снижает преимущества ssd по скорости работы с базой данных.

Одновременно с этим есть тенденция к недооценке значимости производительности процессора и памяти в современных конфах вроде УТ11 и ERP.

Лично мне так видится, что делать упор на ssd не стоит, вместо этого лучше собрать raid10 на быстрых sas (который обеспечит заведомо более низкую стоимость гигабайта), а на сэкономленные средства взять более быстрый проц, дабы перелопачивать кучу данных в памяти (в том числе, лопатить кэш SQL), сериализовать огромные таблицы, которые постоянно передаются в УТ11/ERP, производить быструю инициализацию фоновых заданий и кучу всего, что кладет медленные процы в раз.
   Дарлок
 
31 - 10.10.16 - 14:39
(30) как соберешь, скрины счетчиков производительности выкладывай... заценим
   Чихуахуа
 
32 - 10.10.16 - 14:41
(30) Чувак, ты забыл самое главное - нужно два рэйда, один для ОСи, другой для базы. Скуль очень не любит когда винда веник дергает.
   MrStomak
 
33 - 10.10.16 - 14:42
(31) Разрешите бегом??!
 
 
   Fragster
 
34 - 10.10.16 - 14:42
(20) вот эта штука как правило упирается в проц + латентность сети между скулем и 1с сервером:
http://fragster.ru/perfomanceTest/
   Cyberhawk
 
35 - 10.10.16 - 14:43
(28) Штатно в 8.2 вроде 80% от установленного объема на ОС хоста
   Cyberhawk
 
36 - 10.10.16 - 14:43
*в 8.3
   Дарлок
 
37 - 10.10.16 - 14:45
(33) разрешаю.
(35) физически и практически сколько сейчас планок памяти можно запихнуть в серверный решения?
раньше(во времена х32) запихать базу в RAM было нереально.
   Evgueni
 
38 - 10.10.16 - 14:46
(30) У меня форточки на SSD, а скуль на рейде. В данный момент экспериментирую tempdb. Перенёс темпы с рейда на SSD, похоже что только хуже стало.
   Дарлок
 
39 - 10.10.16 - 14:46
(34) оно не напрямую отдельными сетевухами подключено?
   Cyberhawk
 
40 - 10.10.16 - 14:49
(37) А, ясно. Сколько физически хз, вроде за последние лет 5 ни разу не видел серверов 32б
   Jump
 
41 - 10.10.16 - 14:53
(30) Если SQL так оно и есть.
Справятся обычные HDD, главное не грузить их ничем кроме БД.

Если пользователи непосредственно на нем  работать не будут - то можно обойтись и без SSD.
   Дарлок
 
42 - 10.10.16 - 14:55
(40) если базы уйдут в RAM, то будет пофиг на дисковую, что логично.
   Cyberhawk
 
43 - 10.10.16 - 14:56
(42) И как тогда понимаешь (12)?
   H A D G E H O G s
 
44 - 10.10.16 - 14:56
О пользе выбора мощного процессора
http://www.ixbt.com/cpu/intel-ci7-23456.shtml

Такие дела.
   Jump
 
45 - 10.10.16 - 14:57
(38) tempdb это активная запись.
Необходимо чтобы работал TRIM и было много свободного места.

Если проблемы с TRIM, например диски в рэйде или еще чего - то обязательно оставлять резерв неразмеченный опять же в достаточных масштабах.

Иначе закономердая деградация скорости записи до очень плачевных цифр.
   Дарлок
 
46 - 10.10.16 - 14:58
(43) если базы большие в месяца по 10гб роста, то RAM рано или поздно закончится, и скорее это будет рано
   MrStomak
 
47 - 10.10.16 - 14:59
(44) То есть можно смело брать 1.8Ghz, да?
   Дарлок
 
48 - 10.10.16 - 15:00
(34) ethernet gigabit не тянет
https://habrahabr.ru/post/249501/
   Jump
 
49 - 10.10.16 - 15:01
Если говорить о SQL то там особых требований к дискам нет кроме скорости.
Т.е диск тупо должен уметь быстро читать/писать. Режим чтения/записи близок к линейному.
SQL основную работу ведет в памяти и практически не делает случайных выборок с диска.
 
 Рекламное место пустует
   MrStomak
 
50 - 10.10.16 - 15:01
(49)
+1
   Cyberhawk
 
51 - 10.10.16 - 15:02
(47) Я б не рекомендовал. На сходных ПК с Вин7 / Вин 8.1 с одинаковыми дисками и объемом ОЗУ у меня типовые демобазы УТ / БП шустро работают на i7, а на втором железе с i5 уже медленнее.
   MaxS
 
52 - 10.10.16 - 15:02
Бывают же гибридные контроллеры - SSD для кэша и HDD для остального.
Может быть существуют контроллеры с RAM + SSD + HDD
   Cyberhawk
 
53 - 10.10.16 - 15:02
(49) Как тогда понимаешь реплику в (12)?
   Cyberhawk
 
54 - 10.10.16 - 15:03
(46) Ну закончится. И что? Как это объясняет, что для скуля надо "делать упор на диски"?
   Jump
 
55 - 10.10.16 - 15:04
(53) Я ее не понимаю.
Если кто объяснит ее смысл - может пойму.
Но пока никто не удосужился.
   Дарлок
 
56 - 10.10.16 - 15:04
(54) очередь к диску начинает расти
   H A D G E H O G s
 
57 - 10.10.16 - 15:05
(47) Надо убрать снобизм и почитать статью.
   Fragster
 
58 - 10.10.16 - 15:06
(39) даже напрямую отдельными сетевухами задержки зависят от множества факторов
   MrStomak
 
59 - 10.10.16 - 15:06
(51)
Вот и у меня такие наблюдения.
Наблюдал вот именно УТ11 на xeon с 1.8Ghz.
Никакие ссд не помогали - оно вообще не шевелилось.
   Дарлок
 
60 - 10.10.16 - 15:07
(58) масштабируемость недостижима?
   H A D G E H O G s
 
61 - 10.10.16 - 15:09
(53) Это был сарказм.
   H A D G E H O G s
 
62 - 10.10.16 - 15:11
Мне вот интересно, столько тысяч страниц индексов и данных обновляется при проведении средненького РТУ в УТ11.2 и в каких местах диска они расположены?
   Jump
 
63 - 10.10.16 - 15:14
(56) Очередь не будет расти - там ближе к линейке запись и чтение.
А очередь активно растет когда куча конкурентных запросов, либо работа с мелкими блоками.
   Jump
 
64 - 10.10.16 - 15:16
Под скуль и сервер 1с надо процессор как можно шустрей.
Памяти - чем больше тем лучше.
А диски - они должны быть, особых требований нет.

Ну если не рассматривать ситуации когда у вас на одном диске или массиве и база и ОС. Тогда да, будут проблемы с дисками.
   MrStomak
 
65 - 10.10.16 - 15:16
(57) Я вроде задал конкретный вопрос, несложный, разве нет?

(62)
В кратце:
Если перепроводить первый РТУ в базе - то очень много, если последний - то мало.
Их расположение на диске - вопрос философский.
Существует фрагментация, существует кэш.
   XMMS
 
66 - 10.10.16 - 15:22
Изучал тему, довольно много ссылок в том числе и от Гилева, которые подтверждают большую роль частоты процессора.
Пруф: http://www.gilev.ru/bestproc1c/
В Тринити, к слову, с этим не согласились и предлагали процессоры многоядерные и слабые. Но Гилеву + (34) я верю больше.
   MrStomak
 
67 - 10.10.16 - 15:26
(66) Спасибо за линк, познавательный.
Автору топика, на мой взгляд, следует учесть важный вывод статьи, с которым я полностью согласен:
"Могу утверждать, что в среднем при покупке сервере стоимость процессора составляет где то 10% от всего сервера, а вот вклад в общую производительность может достигать 50%. Поэтому если придерживаться принципа парето, экономить на процессоре — это самая большая ошибка имхо."
   Дарлок
 
68 - 10.10.16 - 15:28
(63) дык... типичная нагрузка при 100+ пользователей, не?
   Garykom
 
69 - 10.10.16 - 15:31
Выкинуть из конфиги покупку MS Windows и MS SQL взамен linux+postgres и взамен улучшить железо.
   H A D G E H O G s
 
70 - 10.10.16 - 15:37
(69) самый фееричный совет, который может быть.
   Jump
 
71 - 10.10.16 - 15:38
(68) Если скуль то нет.
Смысл скуля как раз и есть в том чтобы оптимизировать работу.
Линейное чтение большого куска данных - активная работа с ним в памяти, и запись большого куска  данных.
   H A D G E H O G s
 
72 - 10.10.16 - 15:38
(65) Нет, не значит, что нужно бежать и покупать 1.8 ГГЦ. Это значит, что не стоит гнаться за последним поколением, и, возможно за I7
   MrStomak
 
73 - 10.10.16 - 15:39
(68) 100+ пользователей работают, как правило, с несколькими фиксированными областями данных, которые помещаются в кэш SQL
То, что было полтора года назад, никто уже не использует.
Эти данные вообще иногда выделяют и выкидывают на отдельный диск, дабы не мешали.
   Дарлок
 
74 - 10.10.16 - 15:46
(73)
>>Эти данные вообще иногда выделяют и выкидывают на отдельный диск, дабы не мешали.
мы сейчас про 1С говорим? там появилось архивирование данных?

>>100+ пользователей работают, как правило, с несколькими фиксированными областями данных, которые помещаются в кэш SQL

1C-ки часто умудряются запускать фулскан по таблице

(71) для баз от 500gb статистика такая же?
   MrStomak
 
75 - 10.10.16 - 15:46
(72)
Согласен.

Просто обрати внимание, это не вполне соответствует сказанному тобой "Intel на вкус и оставшиеся средства".

Вот поэтому указанную рекомендацию считаю вредной.
   H A D G E H O G s
 
76 - 10.10.16 - 15:48
(71) ACID говорит, что ты не прав.
   Дарлок
 
77 - 10.10.16 - 15:50
(76) мне кажется это должно зависеть  от соотношения RAM и размера базы. У тебя базы по сколько весят?
   MrStomak
 
78 - 10.10.16 - 15:53
(74)
>>там появилось архивирование данных?
секционирование таблиц MS SQL https://msdn.microsoft.com/ru-ru/library/ms190787.aspx
>>1C-ки часто умудряются запускать фулскан по таблице
1с-ки могут и на сервере две таблицы по 100к строк в памяти соединять. Если стоит задача сделать что-то узким местом - это кодится очень быстро.
   H A D G E H O G s
 
79 - 10.10.16 - 15:54
(77) Я вам не корпорация. У меня нет баз.
   H A D G E H O G s
 
80 - 10.10.16 - 15:56
(77) Буковка D в слове ACID говорит, что после Commit транзакции, даже если сервер падет, после его перезапуска, эта транзакция никуда не денется.
   MrStomak
 
81 - 10.10.16 - 15:56
(76) ACID обеспечивается батарейкой в raid-контроллере.
А если у тебя тру-хайлоад система и условных 64Мбайт кэша не хватает, то используется массив SSD для буферизации записи в рэйд из SAS дисков.
   Jump
 
82 - 10.10.16 - 15:57
(74) Дело не только в размере.
Дело в том влазят ли в память все данные с которыми активно работают или нет.
Если не влазят - начинается активная работа с диском, и тормоза.
Тут даже SSD не спасет.
   H A D G E H O G s
 
83 - 10.10.16 - 15:58
(81) ACID был контраргументом к фразе "Линейное чтение большого куска данных - активная работа с ним в памяти, и запись большого куска  данных."
   H A D G E H O G s
 
84 - 10.10.16 - 16:00
(83) Грубо говоря - sql пофиг, че у вас там за оборудование, он сбросит данные на диск при commit-е транзакции.
   Jump
 
85 - 10.10.16 - 16:00
(83) И в чем конкретно проблема касательно ACID?
   Дарлок
 
86 - 10.10.16 - 16:00
(82) это сложно вычислить. Проще посчитать косвенно, через соотношение размер памяти и базы.

Но мы же как то жили в эпоху х32 12Гб RAM и  250ГБ mdf, тогда не было  никаких SSD. Скази + фаерченнел. И норм УПП бегало

(79) это бушь у следователя рассказывать, Ёж ))
   Fragster
 
87 - 10.10.16 - 16:01
(60) ну, сотни юзеров на типовых - достижимы. тысячи юзеров на самописках - также достижимы. десятки тысяч - с более менее развернутым функционалом - с трудом.
   Jump
 
88 - 10.10.16 - 16:03
(86) Загони в базу мильен картинок  - у тебя будет офигенно большая база.
А реально данных с которыми работают - копейки.
   Дарлок
 
89 - 10.10.16 - 16:04
(87) сотни и на 77 бегали.  И это без всяких серверов приложений. Пичаль...
(88) кто же картинке в базе до сих пор то хранит?
   Jump
 
90 - 10.10.16 - 16:04
(87) Ну так нефиг линейно масштабировать.
Разделяй и властвуй.
   Jump
 
91 - 10.10.16 - 16:05
(89) Ты не поверишь, чего только там не хранят.
   Дарлок
 
92 - 10.10.16 - 16:07
(90) ога....
- для чего внедряли ERP?
- для  того, что бы данные были в одной базе... так сказать единое информационное пространство...
- а зачем разделили на разные серверы?
- тормозило-сЪ
   ptiz
 
93 - 10.10.16 - 16:18
К вопросу о бесполезности SSD.
Когда сидели на RAID-10 из 8 дисков, база (400гб) помирала в то время когда батарейка "обучалась", юзеры курили. Перешли на SSD - очередь в диску исчезла вообще.
   Fragster
 
94 - 10.10.16 - 16:20
(89) сотни на 7.7 без приблуд? только в терминале и то, она загибалась на блокировках еще на 20-30 юзерах. прямые запросы и всяческие ухищрения позволяли поднять этот предел, но у людей висел либо вылет по блокировкам при таймауте 0, либо приблуда для вставки таймаута в сервера.
на технологии гибких блокировок можно было сотню пустить, но это уже совершенно другие (относительно снеговика) вложения в разработку и обслуживание. Да и функционал типовых намного беднее.
   MrStomak
 
95 - 10.10.16 - 16:21
(84) Вообще говоря, нет.
SQL поддерживает протокол опережающей записи.
Т.е. все модификации базы пишутся линейно в транзакционный журнал, после этого данные меняются в кэше, и только потом - сбрасываются на диск. До сброса данных на диск уже снимается блокировка и происходит Commit, т.е. commit не обязательно завязан на физическую запись именно в таблицы базы данных.
Если вдруг происходит сбой, то СУБД определяет транзакции, которые не успели сбросится на диск, и делает Redo.
https://technet.microsoft.com/en-us/library/cc966500.aspx
   Jump
 
96 - 10.10.16 - 16:22
(93) Файловая?
   Дарлок
 
97 - 10.10.16 - 16:23
(94) там база была забавная. Основа торговля 7.0. Регистры не закрытые, да и вообще они по минимуму использовались. Но база жила без доп. приблуд. Сам вспоминаю и удивляюсь. Активных от 80 до 100 юзверей было.
   Fragster
 
98 - 10.10.16 - 16:23
(93) не обучалась, а умирала. и выключался кэш записи. у нормальных админов такого не происходит.
   Alexor
 
99 - 10.10.16 - 16:31
(94) 180 пользователей Комплексная в DBF без приблуд. Размер базы за 16 гигов.

Транзакции бывают, но жить можно.
   Fragster
 
100 - 10.10.16 - 16:33
(99) а сколько номенклатуры и сколько документов в день эти 180 пользователей вводят? сколько отчетов делают?
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует