Добрый день форумчане!
Собираемся покупать новый сервер под 1С.
На нём будет стоять Winwows Server, крутиться  SQL и сервер 1С. Объём базы порядка 30 Гб. терминала не будет.
Интересует какой брать процессор Е3 или Е5 и в каком количестве (сильно ли измениться производительность) или лучше сделать упор на память? С какими параметрами сервера 1С работает быстрее(Режим распределения нагрузки - приоритет по производительности или о памяти)

упор на диски

(1) предлагаешь использовать ssd?

"терминала не будет. " // Т.е. работать в конфигураторе с этой базой будут с клиентских машин?

https://its.1c.ru/db/metod8dev#content:5810:hdoc

что за конфа ?

(4) да, только с клиентских

(6) ут 11.2

(3) SSD надо использовать правильно. Главное, оставляй резерв свободного места 70%. Минимум нужно 50% свободного места, но у вас база вырастет же, значит диск должен быть 128 Гб. И надо следить за износом ячеек. Так что лучше сразу взять 240 Гб, чтобы раньше времени не крякнулся.

(1) Чем обосновывается упор на диски?
(9) Нужно как минимум 2 диска в зеркальном рейде, при этом использовать raid-контроллер, поддерживающий TRIM для дисков. Это если на ssd делать

raid ssd под данные
дешевый отдельный ssd под лог+tempdb+tmp 1C
HDD под бэкапы, систему и образ системы
32 гига оперативки
Intel на вкус и оставшиеся средства.

(10) "Чем обосновывается упор на диски?"
Правильными алгоритмами, которые не заставят SQL елозить по данным в памяти, дикими nestedloop-ами.

(12) Это не обоснование "упора на диски"

(0) Я обычно вот тут обсуждаю серрвера для 1С.http://3nity.ru/viewforum.php?f=40&sid=712a01d6793df41243eb8b3349f9088f
Не реклама. Нормально ребята помогают.

(11) Можно тогда 64 гига оперативки и 20-30 рамдиск для темпов. Очень помогает.

(12) Ну если бы СУБД не нужны были диски - их бы давно уже выкинули. К сожалению все равно приходится какое-то данные считывать с диска.

проще под темпы и сеансовые данные сделать рэмбрайв на 8-16 ГБ (это для 1с), а базу на нормальный sas. Это будет не сильно медленнее SSD, но зато места намного больше. не будет проблем развернуть рядом еще пару-тройку копий баз

(11)
Ага, прекрасно.
Например, Intel® Xeon® Processor E3-1258L v4 с базовой тактовой частотой 1.8Ghz прекрасно подойдёт, да?

(16) +100500

(16) если уже ВР про SSD на сервере говорит, то это уже грех не использовать их )))

(10) Ни процессор, ни память обычно не являются узкими местами для работы с 1С.

(12) А к чему тут сказано про упоминание о памяти? Чтобы не елозить в памяти, нужно не елозить в данных, которые в эту память попадают с диска.

(16) Копию развернете на HDD.

(21) Это вы разработчикам типовых говорите, не мне.
Жесть УТ11.2, как она есть.

(17) Откуда столько негатива?

(24) продажники "инсталляторв" будут впаривать другое, еще потом до кучи и 5E raid настроят.
Это если конечно техника брендовая

(23) Ты что-то юлишь. Про память все-таки объясни пож-та в контексте (12) и (21).

+(26) Я не один, кто не понял твоей мысли про память, вон (13) тоже не согласен с таким обоснованием упора на диски :)

(27) сколько сейчас предел по объему ОЗУ?

(20) Процессор еще как является

(24)
На мой взгляд, есть тенденция к переоценке преимуществ ssd в задачах работы с базами данных. Понятно, что Windows на ssd грузится в 10 раз быстрее, скорость чтения случайных данных у него прекрасная.
Однако, для задач СУБД всё же активно используется кэш MS SQL(для чтения) и кэш raid-контроллера(для записи). Это во многом снижает преимущества ssd по скорости работы с базой данных.

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

Лично мне так видится, что делать упор на ssd не стоит, вместо этого лучше собрать raid10 на быстрых sas (который обеспечит заведомо более низкую стоимость гигабайта), а на сэкономленные средства взять более быстрый проц, дабы перелопачивать кучу данных в памяти (в том числе, лопатить кэш SQL), сериализовать огромные таблицы, которые постоянно передаются в УТ11/ERP, производить быструю инициализацию фоновых заданий и кучу всего, что кладет медленные процы в раз.

(30) как соберешь, скрины счетчиков производительности выкладывай... заценим

(30) Чувак, ты забыл самое главное - нужно два рэйда, один для ОСи, другой для базы. Скуль очень не любит когда винда веник дергает.

(31) Разрешите бегом??!

(20) вот эта штука как правило упирается в проц + латентность сети между скулем и 1с сервером:
http://fragster.ru/perfomanceTest/

(28) Штатно в 8.2 вроде 80% от установленного объема на ОС хоста

*в 8.3

(33) разрешаю.
(35) физически и практически сколько сейчас планок памяти можно запихнуть в серверный решения?
раньше(во времена х32) запихать базу в RAM было нереально.

(30) У меня форточки на SSD, а скуль на рейде. В данный момент экспериментирую tempdb. Перенёс темпы с рейда на SSD, похоже что только хуже стало.

(34) оно не напрямую отдельными сетевухами подключено?

(37) А, ясно. Сколько физически хз, вроде за последние лет 5 ни разу не видел серверов 32б

(30) Если SQL так оно и есть.
Справятся обычные HDD, главное не грузить их ничем кроме БД.

Если пользователи непосредственно на нем  работать не будут - то можно обойтись и без SSD.

(40) если базы уйдут в RAM, то будет пофиг на дисковую, что логично.

(42) И как тогда понимаешь (12)?

О пользе выбора мощного процессора
http://www.ixbt.com/cpu/intel-ci7-23456.shtml

Такие дела.

(38) tempdb это активная запись.
Необходимо чтобы работал TRIM и было много свободного места.

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

Иначе закономердая деградация скорости записи до очень плачевных цифр.

(43) если базы большие в месяца по 10гб роста, то RAM рано или поздно закончится, и скорее это будет рано

(44) То есть можно смело брать 1.8Ghz, да?

(34) ethernet gigabit не тянет
https://habrahabr.ru/post/249501/

Если говорить о SQL то там особых требований к дискам нет кроме скорости.
Т.е диск тупо должен уметь быстро читать/писать. Режим чтения/записи близок к линейному.
SQL основную работу ведет в памяти и практически не делает случайных выборок с диска.

(49)
+1

(47) Я б не рекомендовал. На сходных ПК с Вин7 / Вин 8.1 с одинаковыми дисками и объемом ОЗУ у меня типовые демобазы УТ / БП шустро работают на i7, а на втором железе с i5 уже медленнее.

Бывают же гибридные контроллеры - SSD для кэша и HDD для остального.
Может быть существуют контроллеры с RAM + SSD + HDD

(49) Как тогда понимаешь реплику в (12)?

(46) Ну закончится. И что? Как это объясняет, что для скуля надо "делать упор на диски"?

(53) Я ее не понимаю.
Если кто объяснит ее смысл - может пойму.
Но пока никто не удосужился.

(54) очередь к диску начинает расти

(47) Надо убрать снобизм и почитать статью.

(39) даже напрямую отдельными сетевухами задержки зависят от множества факторов

(51)
Вот и у меня такие наблюдения.
Наблюдал вот именно УТ11 на xeon с 1.8Ghz.
Никакие ссд не помогали - оно вообще не шевелилось.

(58) масштабируемость недостижима?

(53) Это был сарказм.

Мне вот интересно, столько тысяч страниц индексов и данных обновляется при проведении средненького РТУ в УТ11.2 и в каких местах диска они расположены?

(56) Очередь не будет расти - там ближе к линейке запись и чтение.
А очередь активно растет когда куча конкурентных запросов, либо работа с мелкими блоками.

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

Ну если не рассматривать ситуации когда у вас на одном диске или массиве и база и ОС. Тогда да, будут проблемы с дисками.

(57) Я вроде задал конкретный вопрос, несложный, разве нет?

(62)
В кратце:
Если перепроводить первый РТУ в базе - то очень много, если последний - то мало.
Их расположение на диске - вопрос философский.
Существует фрагментация, существует кэш.

Изучал тему, довольно много ссылок в том числе и от Гилева, которые подтверждают большую роль частоты процессора.
Пруф: http://www.gilev.ru/bestproc1c/
В Тринити, к слову, с этим не согласились и предлагали процессоры многоядерные и слабые. Но Гилеву + (34) я верю больше.

(66) Спасибо за линк, познавательный.
Автору топика, на мой взгляд, следует учесть важный вывод статьи, с которым я полностью согласен:
"Могу утверждать, что в среднем при покупке сервере стоимость процессора составляет где то 10% от всего сервера, а вот вклад в общую производительность может достигать 50%. Поэтому если придерживаться принципа парето, экономить на процессоре — это самая большая ошибка имхо."

(63) дык... типичная нагрузка при 100+ пользователей, не?

Выкинуть из конфиги покупку MS Windows и MS SQL взамен linux+postgres и взамен улучшить железо.

(69) самый фееричный совет, который может быть.

(68) Если скуль то нет.
Смысл скуля как раз и есть в том чтобы оптимизировать работу.
Линейное чтение большого куска данных - активная работа с ним в памяти, и запись большого куска  данных.

(65) Нет, не значит, что нужно бежать и покупать 1.8 ГГЦ. Это значит, что не стоит гнаться за последним поколением, и, возможно за I7

(68) 100+ пользователей работают, как правило, с несколькими фиксированными областями данных, которые помещаются в кэш SQL
То, что было полтора года назад, никто уже не использует.
Эти данные вообще иногда выделяют и выкидывают на отдельный диск, дабы не мешали.

(73)
>>Эти данные вообще иногда выделяют и выкидывают на отдельный диск, дабы не мешали.
мы сейчас про 1С говорим? там появилось архивирование данных?

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

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

(71) для баз от 500gb статистика такая же?

(72)
Согласен.

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

Вот поэтому указанную рекомендацию считаю вредной.

(71) ACID говорит, что ты не прав.

(76) мне кажется это должно зависеть  от соотношения RAM и размера базы. У тебя базы по сколько весят?

(74)
>>там появилось архивирование данных?
секционирование таблиц MS SQL https://msdn.microsoft.com/ru-ru/library/ms190787.aspx
>>1C-ки часто умудряются запускать фулскан по таблице
1с-ки могут и на сервере две таблицы по 100к строк в памяти соединять. Если стоит задача сделать что-то узким местом - это кодится очень быстро.

(77) Я вам не корпорация. У меня нет баз.

(77) Буковка D в слове ACID говорит, что после Commit транзакции, даже если сервер падет, после его перезапуска, эта транзакция никуда не денется.

(76) ACID обеспечивается батарейкой в raid-контроллере.
А если у тебя тру-хайлоад система и условных 64Мбайт кэша не хватает, то используется массив SSD для буферизации записи в рэйд из SAS дисков.

(74) Дело не только в размере.
Дело в том влазят ли в память все данные с которыми активно работают или нет.
Если не влазят - начинается активная работа с диском, и тормоза.
Тут даже SSD не спасет.

(81) ACID был контраргументом к фразе "Линейное чтение большого куска данных - активная работа с ним в памяти, и запись большого куска  данных."

(83) Грубо говоря - sql пофиг, че у вас там за оборудование, он сбросит данные на диск при commit-е транзакции.

(83) И в чем конкретно проблема касательно ACID?

(82) это сложно вычислить. Проще посчитать косвенно, через соотношение размер памяти и базы.

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

(79) это бушь у следователя рассказывать, Ёж ))

(60) ну, сотни юзеров на типовых - достижимы. тысячи юзеров на самописках - также достижимы. десятки тысяч - с более менее развернутым функционалом - с трудом.

(86) Загони в базу мильен картинок  - у тебя будет офигенно большая база.
А реально данных с которыми работают - копейки.

(87) сотни и на 77 бегали.  И это без всяких серверов приложений. Пичаль...
(88) кто же картинке в базе до сих пор то хранит?

(87) Ну так нефиг линейно масштабировать.
Разделяй и властвуй.

(89) Ты не поверишь, чего только там не хранят.

(90) ога....
- для чего внедряли ERP?
- для  того, что бы данные были в одной базе... так сказать единое информационное пространство...
- а зачем разделили на разные серверы?
- тормозило-сЪ

К вопросу о бесполезности SSD.
Когда сидели на RAID-10 из 8 дисков, база (400гб) помирала в то время когда батарейка "обучалась", юзеры курили. Перешли на SSD - очередь в диску исчезла вообще.

(89) сотни на 7.7 без приблуд? только в терминале и то, она загибалась на блокировках еще на 20-30 юзерах. прямые запросы и всяческие ухищрения позволяли поднять этот предел, но у людей висел либо вылет по блокировкам при таймауте 0, либо приблуда для вставки таймаута в сервера.
на технологии гибких блокировок можно было сотню пустить, но это уже совершенно другие (относительно снеговика) вложения в разработку и обслуживание. Да и функционал типовых намного беднее.

(84) Вообще говоря, нет.
SQL поддерживает протокол опережающей записи.
Т.е. все модификации базы пишутся линейно в транзакционный журнал, после этого данные меняются в кэше, и только потом - сбрасываются на диск. До сброса данных на диск уже снимается блокировка и происходит Commit, т.е. commit не обязательно завязан на физическую запись именно в таблицы базы данных.
Если вдруг происходит сбой, то СУБД определяет транзакции, которые не успели сбросится на диск, и делает Redo.
https://technet.microsoft.com/en-us/library/cc966500.aspx

(93) Файловая?

(94) там база была забавная. Основа торговля 7.0. Регистры не закрытые, да и вообще они по минимуму использовались. Но база жила без доп. приблуд. Сам вспоминаю и удивляюсь. Активных от 80 до 100 юзверей было.

(93) не обучалась, а умирала. и выключался кэш записи. у нормальных админов такого не происходит.

(94) 180 пользователей Комплексная в DBF без приблуд. Размер базы за 16 гигов.

Транзакции бывают, но жить можно.

(99) а сколько номенклатуры и сколько документов в день эти 180 пользователей вводят? сколько отчетов делают?

(93) Вместо SSD можно было бы поменять raid-контроллер с кэшем в 16Мбайт на хотя бы 512Мбайт (для базы в 400 гигов).
Вышло бы в несколько раз дешевле.

(100) Номенклатура 40 000
Документов 2000 в день.
В каждом в среднем 5-10 поз.

+102 Терминал естественно.

(102) Спс.

ЧТД. 1С пошло совсем не в ту сторону. Проблемы масштабируемости в архитектуре системы, а не в оптимизации запросов и в умении фапать на профайлер.

САП R3 вон воообще join не использует. Выбирает данные с СУБД порциями и на аппликухах обрабатывает

(102) ну, если "без заднего числа", получается на 10 часов рабочего времени 2000 документов. в час - 200 документов. 18 секунд на документ. и без параллельного проведения терпимо. а вот как только начинается всякие рассчитатьрегистрына, контроль партий и сроков дебиторки из этого заднего числа, чтобы в периодах между документом и ТА не было минусов или нарушений каких-либо условий - вот тут получается, что 18 секунд на проведение маловато. Это про те вещи, которые как раз к типовым документам дописываются.

(105)+ 18 секунд - это без использования прямых запросов, только "черными"

(105) Заднее число есть.
Перемещения самые большие там в среднем по 200-300 поз.
Там контролируем только оперативно.

А реализации, там контроль не только остатки и взаиморасчеты. но и другие параметры есть, бюджеты например.

2000 доков в день, товародвижений наверное 50-70%.

(105) Затык когда банк начинают грузить.

(108) вот видишь, как оно - пакетное создание и все курят. потому что клюшки - однопоточные. и у тебя при 180 юзерах каждый получает по "таймслоту", которого достаточно на указанное тобой количество документов.

хорошая аналоги придумалась - 7.7 это tdma, а снеговик на управляемых блокировках - cdma (слоты по комбинациям измерениям регистров)

(109) Угу. Там еще затык бывает, глюк платформы как я понимаю. Когда пользователь "прыгает" в документ другого пользователя. Вот тогда транзакция глухая. Пока пользователь не перезапустит 1с.
Но обработкой научился вычислять такое.

+111 8-ка в целом конечно лучше и круче. Только вот качество и логика работы последних типовых удручает.

(45) Прогнал я тест на своей базе. tempdb на SDD выигрывает немного на временных таблицах, на РН незначительно проигрывает. И наоборот, когда tempdb переношу на рейд - симметричная картина.

(113) вот я и говорю. с определенного момента увеличение "дисков" не дает эффекта. естественно, в рэйд контроллере должен работать кэш в обе стороны.

(113) А характеристики SSD какие?

(110) В связи с чем 7ка tdma?
Ты хочешь сказать, что в ней невозможна параллельная запись?

(114) а потери на моменте передачи управление клиент-сервер не удавалось замерить?
чисто серверный код, насколько будет быстрее, чем клиент-серверный?

(116) без приблуд типа софтпоинтовских с "гибкими болкировками" - нет

(117) многопоточно сложно замерять. но условно 1 серверный вызов = время сериализации + 0.02 секунды для вызова по локальной сети.

а время сериализации - это процессор :)
время 0.02 - это 1гигабитная сеть + 1 хороший коммутатор. тот же софтпоинт мне говорил, что эту цифру можно снизить в разы для инфинибэндов и прочей требухи с низкими задержками (типа отзывчивость УФ становится как у толстого клиента).

(120) спасибо.

ну, там еще передача данных, да. 0.02 - это совсем без данных, минимальное время

(122) УФ не видел, но уже понял, что штука тормозная ;)
а при вызове сервера с клиента(передаче данных на сервер) серилизация разве не на клиенте будет?

(123) ну так данные-то еще обратно передать надо

(120) Сериализация же не исчезнет. Так что отзывчивость как у толстого клиента недостижима.

(124) клиент- рабочий процесс клиента - процесс сервера
и обратно?

(125) в общем случае - да, тут косяк

(126) Рабочий процесс клиента, он же рабочий процесс сервера, он же rphost.exe. Сериализация только между клиентом (1cv8c) и сервером (rphost, apache и т.д.)

(70) Ценник Windows Server + MS SQL с нужным кол-вом лицух нет желания озвучить?
И сравнить со стоимостью SSD или оперативки/проца?

(0) Для автора темы.
Современный выбор моделей процессоров производства Intel
для серверных решений весьма широк и впечатляюще разнообразен как по характеристикам,
так и в ценовом интервале.
http://ark.intel.com/products/family/91287/Intel-Xeon-Processor-E5-v4-Family#@Server
Как говорится - выбирай не хочу.
Материнские платы(современные) поддерживают от одного до двух ТБ оперативной памяти.
Контроллеры RAID поддерживают до 2 ГБ кэша и 12 ГБ/с SAS HDD(которые, несмотря на ошеломляющий успех SSD у любителей i7,
почему-то продолжают выпускать).
Кстати, сколько у вас там пользователей?

Да, присоединюсь к (30) и (69)

(130) так вопрос в оптимальности этого самого широкого выбора конкретно для 1С.

(131) Частота - от 2.6.
Количество ядер - в зависимости от числа пользователей. Например, по 5 пользователей на ядро.

(128) в тему:
http://catalog.mista.ru/article/bystraya-peredacha-rezultata-zaprosa-na-klient-cherez-com-soedinenie-545369/
Дожили.

(133) Страдает народ без толстого клиента