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

упор на диски

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

что за конфа ?

(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 пользователей вводят? сколько отчетов делают?