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

(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) Страдает народ без толстого клиента