Подбираем сервер для 1C:ERP

Публикация № 1411007

Администрирование - ИТ-инфраструктура - Сервера

На Infostart Meetup Ekaterinburg ведущий разработчик 1С в компании ФТО Виталий Онянов рассказал, как подобрать сервер для 1С:ERP и на какие показатели ориентироваться, чтобы оборудование для высоконагруженной системы оправдало вложения.

Меня зовут Виталий Онянов, я ведущий разработчик 1С в компании ФТО. Сегодня поговорим про подбор серверов для 1C:ERP.

Кому интересна видео-версия доклада, вот она:

Ну а всем остальным добро пожаловать под кат. 

 

---

Прежде всего хочу сказать, что я не являюсь экспертом в данном вопросе. Если вы думали, что сейчас придет эксперт и все вам расскажет – к сожалению, это не так.

Все-таки я – разработчик 1С, давно не работал с железом напрямую, не собирал сервера. Я давно ничего не админил, хотя считаю, что админский опыт у меня богатый.

Более того, в 2017 году я на Инфостарте опубликовал статью о том, как подбирать оборудование для серверов 1С, но пришел Вячеслав Гилев и сказал, что я во всем не прав.

Но если так, то почему я решил выступить с таким докладом?

  • Я участвовал в нескольких довольно крупных внедрениях 1С:ERP – участвовал в качестве ведущего разработчика, видел и щупал 1С:ERP изнутри,

  • Я занимался вопросами производительности 1C:ERP. Каждый, кто внедрял 1C:ERP, занимался вопросами производительности. К сожалению, это так.

  • Я сделал несколько успешных подборов оборудования для крупных внедрений. «Успешных» в кавычках, но что я понимаю под успешностью? Мы подобрали оборудование для заказчика, заказчик плюс-минус такое оборудование купил, мы запустили систему, и заказчик остался доволен.

  • Эта тема сейчас актуальна, потому что, как вы знаете, заканчивается поддержка КА1.1, УПП, все переходят на новые системы. Забегая вперед, скажу, что со сменой системы нужно обязательно менять оборудование – там, где работала УПП, 1C:ERP работать точно не будет.

  • Ну и вообще тема холиварная – очень много статей, мнений в интернете. Так почему бы сегодня еще немного не похоливарить?

 

Допущение про отказоустойчивость

Прежде всего, хочу сказать пару слов об отказоустойчивости.

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

Конечно, можно сделать полностью отказоустойчивый контур, предусмотреть все. Но тут надо хорошо считать и понимать, соизмеримы ли соответствующие затраты.

Самый простой пример – вы можете:

  • выписать список всех возможных рисков;

  • оценить вероятность риска;

  • оценить, каким будет простой в часах в случае возникновения этого риска;

  • понять, сколько стоит час простоя вашей системы.

И дальше понять, какие из возможных ситуаций вам нужно обрабатывать, а какие маловероятны и на них не стоит тратить деньги – что для вас выгодней: простой системы или второй сервер в запасе?

В любом случае, не забываем и про резервные копии.

Мы на всех проектах настраиваем некоторый минимально допустимый уровень резервного копирования.

  • Для баз данных это, конечно же, полные и разностные резервные копии – как правило, мы их делаем раз в сутки. Копии журналов транзакций – раз в час или чаще.

  • Обязательно делаем бэкап каталога кластера 1С, той самой папки – 1cv8\srvinfo. Достаточно ее копировать раз в сутки.

  • И слепок виртуальной машины – если используется виртуализация – или резервная копия операционной системы. Сама же операционная система Windows Server прекрасно умеет делать резервные копии самой себя, и это точно нормально работает.

Далее в докладе я расскажу о том, какие сервера хорошо бы подбирать под 1С:ERP. При этом:

  • Вопросов отказоустойчивости я касаться практически не буду. Накладывать на это необходимый вам уровень отказоустойчивости вы сможете самостоятельно.

  • Все оговоренное относится не только к 1C:ERP, но и к другим решениям фирмы «1С» – подход здесь универсальный.

  • Ну и далее мы будем опускаться вниз от правильных способов подбора оборудования к тем, скажем так, которые применяются в реальной жизни.

  • Я дам общие рекомендации по конфигурации серверов и приведу конкретные реальные примеры подборов оборудования.

 

Что говорит про подбор оборудования фирма «1С»

Два года назад на партнерском форуме я создал тему, описал проблемы.

Написал, что у других вендоров, таких, как SAP или Axapta, есть конкретные таблички с расчетом оборудования в зависимости от параметров информационной системы. А что есть у 1С? Много было ответов, но все не по делу.

Самые адекватные ответы отсылали к статье «Расчет параметров серверного оборудования» на сайте 1С:ИТС.

Вроде кажется: вот, то, что надо. Но немного смущает дата – статья от 2015 года. К тому же, если мы начинаем читать статью, то видим, что 1С предлагает нам использовать два вида систем: целевую систему и эталонную систему. И дальше оперирует этими двумя понятиями.

Давайте посмотрим, какие способы подбора оборудования тут есть.

Первое – однопользовательская тестовая система в качестве эталонной. Мы берем нашу будущую систему, в однопользовательском режиме запускаем различные ключевые операции – например, проводим документы – и забиваем время выполнения операций.

Предлагается скачать некоторую Excel-таблицу, куда надо забить время выполнения перечисленных операций, и Excel-таблица подберет нам необходимое количество ядер и оперативной памяти.

То есть я беру 1С:ERP, ставлю на свой ноут, делаю замеры, и мне говорят – сколько надо.

Я не верю в этот способ. Я не проверял, может эта таблица действительно крутая. Но я не верю, что можно таким образом подобрать оборудование для 1С:ERP.

Идем дальше – рабочая система в качестве эталонной. Если система 1С уже запущена в тестовую эксплуатацию, предлагается перенести ее на новый сервер и поработать в ней с разными пользователями.

Это довольно очевидный способ – давайте поработаем на новом оборудовании и посмотрим, что будет.

Следующий способ – найти какую-то аналогичную целевую рабочую систему. Я даже приведу цитату с ИТС: «Если ваша информационная система еще не внедрена, но у вас есть доступ к данным аналогичной системы – вы можете использовать ее в качестве эталонной».

Получается, что если вы собираетесь внедрять 1С:ERP – вы идете и ищете кого-нибудь, у кого система 1С:ERP работает примерно с таким же количеством пользователей, документооборотом, такими же ключевыми операциями, способами ввода документов и так далее.

Предлагается еще вот такая табличка: например, вы нашли эталонную систему на 100 пользователей, а в вашей системе 300 пользователей. Табличка вам посчитает, сколько вам нужно ядер процессора и сколько оперативной памяти.

Ну тоже так себе способ – мне кажется, что количество пользователей не является ключевым параметром. Потому что какой-то пользователь может запускать по паре отчетов в день, а где-то есть кабинеты операторов, которые сидят на телефоне, с утра до вечера принимают заказы и бьют реализации. Я видел такие системы – это совершенно разный документооборот.

И следующее, что предлагается использовать в статье – использовать Тест-центр. Это уже более интересный способ, и о нем мы поговорим подробнее.

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

Считается, что перенос рабочей информационной системы на новое оборудование – самый оптимальный вариант с незначительными трудозатратами, но нужны реальные пользователи. Хотя если посчитать время работы реальных пользователей, неизвестно, будут ли трудозатраты незначительными.

Мне больше нравится вариант с использованием тестовой системы. В статье написано, что в этом варианте требуются большие трудозатраты. Возможно, это так, но нам уже не понадобятся реальные пользователи.

Также здесь написано, что точность расчета небольшая, но я с этим не совсем согласен. Я уверен, если правильно подойти к организации тестовой среды, то и точность расчета можно получить довольно высокую.

 

1C:ERP и Тест-центр

Поговорим о Тест-центре.

  • Для 1C:ERP есть готовый релиз с уже встроенным Тест-центром. У него очень длинное название – оно написано на слайде. Это – некоторая конфигурация, где просто сравнением и объединением в 1C:ERP добавлен Тест-центр, прямо в саму конфигурацию.

  • В этом Тест-центре уже реализовано много различных сценариев тестирования именно для 1C:ERP.

  • Можно взять готовые сценарии и прямо на них протестировать 1C:ERP, как, например, тестируется демка. Либо адаптировать скрипты под свои процессы, а еще никто не мешает разрабатывать их самим. Все скрипты написаны на встроенном языке 1С:Предприятия. Каждый скрипт – отдельная обработка в дереве конфигурации.

У 1С есть очень хороший вебинар о нагрузочном тестировании 1C:ERP. Он длинный, трехчасовой, я, например, его смотрел в три захода.

Но в нем последовательно рассказывается:

  • как установить Тест-центр, как его настроить и запустить;

  • как правильно писать скрипты;

  • почему то-то или то-то сделано в Тест-центре именно так,

  • как не наступать на те грабли, которые прошли 1С.

Кто хочет погрузиться в тему нагрузочного тестирования – предлагаю с этого вебинара и начать.

В этой демо-базе 1С:ERP с Тест-центром уже реализованы типовые сценарии тестирования. Например, для закупок есть:

  • разные варианты обеспечения,

  • закупка по импорту,

  • прием на комиссию,

  • ордерная схема,

  • возвратная тара,

  • подотчетники.

Вот так выглядит часть общей схемы тестируемого бизнес-процесса – вся она сюда не влезает. Здесь есть:

  • открытие форм,

  • заполнение элементов формы,

  • проведение и запись документов,

  • печатные формы.

В типовых скриптах, прямо из коробки, есть очень многое и для блока продаж.

Вот часть схемы для блока продаж.

Кроме этого, есть:

  • блок производства;

  • взаиморасчеты;

  • складские операции;

  • регламентные операции;

  • закрытие месяца.

Все это работает сразу из коробки вместе с Тест-центром. Если у вас нет ресурсов на разработку своих скриптов, вы можете на своем новом сервере поставить 1C:ERP с Тест-центром и прогнать все эти типовые скрипты, чтобы понять, какие результаты у вас будут.

 

Плюсы и минусы нагрузочного тестирования

Какие минусы я вижу в нагрузочном тестировании?

  • Дорого, потому что для тестирования на типовых скриптах нужен разработчик, который вникнет, все это поймет, разберется, поймет логику работы Тест-центра, логику написания скриптов. Если хочется написать скрипты, заточенные конкретно под ваши бизнес-процессы – нужен аналитик, консультант, который разберется в текущих процессах предприятия. Это может быть затратно.

Но, плюсов больше:

  • Как я уже сказал, есть много готовых сценариев из коробки.

  • Оборудование можно арендовать: обратиться в дата-центр и взять оборудование, чтобы погонять 1С. Я даже знаю примеры, когда некоторые дата-центры бесплатно выделяли оборудование с целью получить постоянного клиента.

  • Если вам нужно тестировать в облаке, на арендованном оборудовании – вам нужны лицензии. С помощью некоторых бюрократических процедур можно получить тестовые лицензии у «1С». Кроме этого сейчас фирма «1С» выпустила программные лицензии с ограниченным сроком действия – на три и шесть месяцев.

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

  • В результате нагрузочного тестирования можно получить очень релевантные результаты. В качестве замера производительности используется типовая подсистема Аpdex. Тестирование производится на ваших объемах с нужным количеством пользователей. В конце вы сразу же увидите примерное время выполнения тех ключевых операций, которые у вас будут в системе. Вы сможете заранее понять – вот здесь у вас будет все хорошо, а здесь слишком долго, надо оптимизировать.

  • Ну что очень важно, написанные тесты не обязательно потом выкидывать, их можно интегрировать в процесс разработки и продолжать отслеживать производительность вашей системы по методике Apdex в процессе разработки. Основная причина медленной работы 1С – как правило, кривые руки программистов, неоптимальные запросы. А с помощью нагрузочного тестирования вы можете отслеживать, как меняется производительность вашей системы в процессе разработки.

 

С чего начать?

Если вы решили провести нагрузочное тестирование вашей системы, то какой должна быть начальная конфигурация? И что делать, когда на нагрузочный тест нет денег? У нас есть клиенты, которые говорят: «На нагрузочный тест бюджета нет, но нам сервер-то нужен, мы внедряем 1C:ERP, посоветуйте нам что-нибудь».

  • Тут мы вспоминаем про способ, описанный на ИТС – рабочая система, аналогичная целевой. Мы ведем некоторую статистику наших клиентов: кто в какой конфигурации работает, на каком оборудовании, сколько пользователей и какой документооборот, как происходит ввод первички и так далее. Опираясь на эти данные, как на параметры аналогичной рабочей системы, мы можем подобрать клиенту оборудование. Например, клиент говорит: «У меня в 1C:ERP будет работать столько-то пользователей, ожидается столько-то документов». Исходя из нашей статистики мы можем примерно подобрать подходящий кейс с такими же параметрами и, не разглашая ничьих конфиденциальных данных, подобрать клиенту оборудование.

  • Если вы не можете найти аналогичную систему – обратитесь к внешнему подрядчику.

Также на сайте ЦКТП в описании многих проектов приводятся параметры оборудования – правда, здесь тоже критерием выступает количество одновременно работающих пользователей.

На слайде показано аппаратное обеспечение одного из проектов: здесь приводится, какое оборудование было для сервера баз данных и т.д.

Есть сервис подбора у Вячеслава Гилева.

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

Как я уже сказал, количество пользователей не всегда определяет будущую нагрузку оборудования. У меня была возможность погонять этот сервер бесплатно на самых разных данных. И он выкидывает примерно одну и ту же конфигурацию для двух-трех серверов.

Один подбор стоит 500 рублей, наверное, за такую цену это и неплохо.

 

Рекомендации по архитектуре

Перейдем к некоторым рекомендациям по архитектуре.

Первый вопрос – объединять роли сервера приложений и сервера баз данных или не объединять?

  • У нас никогда не бывает так, что приходит клиент и говорит: «Подберите нам любые сервера». Всегда есть бюджет. При фиксированном бюджете всегда выгоднее приобрести один производительный сервер, чем два отдельных сервера. Тем более, если это не арендованное, а физическое оборудование, ведь серверу нужны материнская плата, блок питания, система охлаждения, корпус, операционная система, которая тоже очень дорого стоит. Всегда один производительный сервер будет обходиться дешевле, чем два. Но понятно, что, начиная с какого-то момента, одного сервера будет недостаточно. Если у вас совсем-совсем высоконагруженная система, в какой-то момент все же придется разделить.

  • Кроме того, работает Shared memory. Как пишет сама 1С, Shared memory дает прирост производительности до 10%.

  • Некоторых пугает: как же так, SQL всю память сожрет. Не совсем так, ресурсы между кластером серверов и сервером СУБД можно распределить. И память, и диски, и процессоры – все это разделяется.

  • Как я сказал, для очень высокопроизводительных систем роли придется разделить.

Если не требуется очень высокопроизводительная система, мы рекомендуем использовать единый сервер приложений и баз данных.

На сервере приложений и баз данных строго запрещено поднимать какие-то посторонние службы. К сожалению, мы часто видим, что там еще что-то может крутиться. Какие-то сервисы, которые что-то раздают, какой-нибудь контроллер доменов – встречали и такое.

Никаких посторонних служб быть не должно, а особенно – сервера терминалов. Часто, приходя к клиенту, мы видим сервер СУБД и на нем – сервер терминалов. Спрашиваем: «Зачем вам сервер терминалов?» – «Чтобы администрировать было удобно, чтобы больше двух пользователей могли заходить». На самом деле, на сервер баз данных вообще заходить не надо. Management Studio и консоль кластера можно на терминальном сервере поставить.

  • Во-первых, пользователи терминала создают неконтролируемую нагрузку. Кто-то может запустить какую-то адскую Excel-ку или скопировать на рабочий стол какой-нибудь 4-гиговый файл.

  • А во-вторых, есть еще такая штука – DFSS. Это специальный механизм у Windows Server, который занимается балансировкой рабочих процессов в случае наличия роли терминального сервера. Как только вы на сервере подняли роль терминального сервера, включается вот эта вот штука, и она начинает принижать приоритеты некоторых процессов, чтобы новые пользователи, которые зайдут на терминальный сервер, не смогли завесить весь сервер. Эту штуку тяжело выпилить, и она очень сильно влияет на производительность.

Роли сервера терминалов точно не должно быть на сервере баз данных.

Давайте добавим в нашу схему терминальные серверы, с них тоже клиенты могут работать – это было актуально во времена толстых клиентов,

В случае тонких клиентов пользователи могут работать напрямую с рабочих станций – тонкий клиент может работать даже на очень слабом оборудовании.

Веб-сервер. Можно ли размещать веб-сервер на одной физической машине рядом с кластером серверов 1С?

  • Если планируется небольшая нагрузка, и сервер должен быть доступен только из локальной сети, развернуть сервер на той же машине можно. Например, у вас интеграция с 1С:Документооборот, но в этом случае почему бы и нет – развернули и все.

  • Но если сервер у вас смотрит во внешку или планируется какая-то большая нагрузка – например, тысячи менеджеров бегают с мобильными устройствами, и они постоянно синхронизируются – конечно же, нужно обособлять веб-сервер.

Поэтому веб-сервер у нас обособлен, если смотрит во внешку или планируется значительная нагрузка.

Очень желательно разделять рабочую среду от тестовой. Желательно на физическом уровне.

Если нет денег разнести их физически – разнесите как минимум по разным службам. Поднять параллельную службу сервера 1С на параллельных портах, установить еще один инстанс SQL и хотя бы логически их отделить.

Но мы, конечно, всегда рекомендуем держать отдельно среду разработки – это может быть сервер, совмещенный с ролями СУБД и сервера приложений.

И разработчики могут разрабатывать либо со своих машин, либо с серверов терминалов.

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

Сервер лицензирования для программных лицензий удобен тем, что единый сервер позволяет весь пул лицензий распределить по нескольким серверам:

  • в случае с ключами защиты мы использовали nethasp-службу;

  • в случае с программными лицензиями используем сервер лицензирования.

Параметры серверов могут часто меняться, и, как вы знаете, после смены некоторых параметров необходимо заново активировать лицензию по резервному пинкоду. Например, админы ночью поменяли конфигурацию, утром встаем – сервер не работает, где пинкоды – никто не знает, какие регистрационные данные были указаны – никто не знает. Начинается паника.

Сервер лицензирования частично этот вопрос решает. Это некоторая отдельная машина, виртуальная или физическая, на каком-нибудь бесплатном Linux, которая занимается только тем, что раздает лицензии.

И последний – самый холиварный вопрос: использовать ли виртуализацию сервера баз данных и сервера приложений?

Очевидные плюсы виртуализации:

  • легкость миграции серверов;

  • удобство администрирования;

  • есть очень удобные средства резервного копирования.

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

Сейчас, имея большой опыт разработчика 1С, я вижу и некоторые минусы виртуализации.

  • Есть ли снижение производительности – я не знаю. Не проводил таких тестов, чтобы погонять нагрузочное тестирование на физической среде и на виртуальной, поэтому я не могу сравнить и сделать выводы.

  • Но нужны обязательно компетенции по правильной настройке и администрированию гипервизоров. Компетенции, отличные от строгого следования инструкции в интернете. Для высоконагруженных систем есть очень сложные гипервизоры с миллионом настроек, где каждая галочка, каждый параметр может очень сильно убить вашу систему с точки зрения производительности. Поэтому неправильные настройки в вопросах производительности – это потенциально узкое место.

    • Бывают проекты оптимизации, когда нам говорят, что сервер тормозит. Мы идем разбираться и либо не видим на самом сервере проблем, либо видим не те проблемы, на которые в первую очередь жалуется клиент. А проблемы лежат вне области нашего воздействия. Никто не пускает нас к физической машине, если это гипервизор. Всегда есть какой-то специалист, который все это настраивал, который держит оборону и никого не пускает. Говорит: это ваша 1С, вы и разбирайтесь, почему она тормозит.

    • У нас было очень много таких примеров, например, когда неправильно был настроен протокол IPv6 был в гипервизоре, сеть жутко тормозила, и это было очень сложно диагностировать.

    • Были примеры, когда клиент купил СХД за пару миллионов рублей, и был убежден, что теперь все должно летать. А мы запускали тесты, которые показывали очень плохие результаты на СУБД, и говорили, что проблема с дисками. Нам не верили: «Мы пару миллионов на диски потратили, а вы нам снова про них говорите». А проблема была именно в настройках гипервизора.

  • Затрудняется сбор показателей работы оборудования. Счетчики в Windows мы можем настроить, но мы не видим загрузку реального оборудования. Там уже нужны компетенции по настройке Zabbix – не все администраторы у клиентов могут это правильно сами настроить и предоставить доступ к отчетности.

  • Ну и меньше гибкости в настройке оборудования – я об этом позже подробнее расскажу.

Я знаю, что все эти минусы решаемы. Это все можно устранить, если выполняется условие наличия грамотного специалиста, который сможет корректно настраивать и обслуживать виртуальные машины.

Но мы в своей практике, к сожалению, сталкиваемся с обратным – с низкой компетенцией специалистов по виртуализации.

Поэтому мы рекомендуем не использовать виртуализацию для серверов приложений и баз данных. И у нас есть несколько крупных клиентов, которые сознательно для сервера баз данных-сервера приложений ушли от виртуализации на физическое оборудование. Для них производительность системы важнее удобства миграции и администрирования.

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

 

Советы по оборудованию для сервера приложений и баз данных

Диски. Очень хочется, чтобы люди при подборе серверов приложений и баз данных начинали с дисков. Почему-то всегда покупают какой-то СХД с дисками, размещают все на нем, но этого оказывается недостаточно, притом, что и СХД, и диски дорого стоят. Объясню, почему.

Если подойти к дискам с умом, можно сэкономить бюджет и получить довольно производительную систему.

  • Под операционную систему – я рекомендую взять два SSD-диска, объединить их в RAID.

  • Под накопители для СУБД взять:

    • Какие-нибудь промышленные SSD с интерфейсом PCIe, форм-фактор U2, например. Это Intel Optane, у Samsung есть соответствующая серия. Это довольно дорогие диски, но очень эффективные для сервера баз данных – мне кажется, это единственно возможные диски, которые покажут хорошую производительность.

    • Объединять ли их в RAID? Я считаю, что не стоит. Лучше – разнести по назначению. Например, на один диск положить данные базы данных, на другой – журнал транзакций базы данных. В этом месте у некоторых админов начинает дергаться глаз. Как так, а вдруг он выйдет из строя? Во-первых, промышленные SSD сейчас по надежности уже переплюнули физические диски. А во-вторых – бэкапы. Если вам мало делать бэкапы раз в час – делайте их хоть каждые 10 минут. Это не влияет существенно на производительность системы.

  • Под резервные копии места часто не хватает, поэтому я предлагаю для этих нужно отдельно подключить к серверу два любых диска – пусть у вас будет много места для резервных копий. Например, журналы транзакций после какого-нибудь закрытия месяца могут много весить, и их некуда складывать. Диски в этом случае – относительно копеечная затрата. Не обязательно уровня Enterprise, можно и обычные диски SAS или даже SATA – лишь бы они были.

  • Под временные файлы обязательно предусмотрите отдельный накопитель. Это файлы подкачки, папка TEMP, файл TempDB. Можно даже TempDB вынести на RAM-диск, у нас есть такой опыт, и он давал существенные результаты.

  • Предусмотрите отдельный диск для кластера серверов 1С. Это особенно актуально, если у вас совмещены роли сервера приложений и сервера баз данных, так как сам сервер 1С с сеансовыми данными, с журналом регистрации и с папкой TEMP могут создавать значительную нагрузку на диск.

Все чаще мы сталкиваемся с тем, что у наших клиентов сервера не свои, а арендованные в дата-центре.

Если наши клиенты арендуют сервера, при заказе в дата-центре спрашивают: а вам диски на сколько IOPS надо? Мы не очень любим этот параметр, но приходится иметь дело с тем, что имеем.

Вот так выглядит предыдущий список, но уже с использованием IOPS – такие показатели дисков нужны для каждого типа дисков, для каждого назначения.

Под накопители для базы данных хорошо бы иметь диски от 100 тыс. IOPS при рандомном чтении записи 4 килобайт. Такие диски под базы данных хорошо себя показывают.

Процессоры.

  • Тут очень важна тактовая частота.

    • Желательно производительностью от 3 GHz. Мы проверяли, производительность процессора хорошо влияет на производительность 1С.

    • Хорошо показали себя всякие технологии, типа Turbo Boost, Hyper-Threading.

  • Примеры процессоров – Xeon Gold, Xeon Silver, Xeon D и аналогичные от AMD. Если честно, все наши клиенты на Intel, я не сталкивался с AMD, но уверен, что есть аналоги – просто я про них не знаю.

Про память. Оставшиеся деньги вкладывайте в нее. Ее, по моему опыту, много не бывает. Чем больше – тем лучше.

Для сервера СУБД, сервера приложений, для 1C:ERP нужно от 120 Gb – 1C:ERP очень прожорлива в плане ресурсов и реально потребляет очень много оперативной памяти.

 

Сервер терминалов

Что касается сервера терминалов – количество пользователей:

  • Microsoft рекомендует использовать один сервер терминалов на 50 активных пользователей.

  • На Хабре я читал, что в Windows Server 2019 можно пускать на один сервер уже двести пользователей, но пруфов при подготовке к докладу не нашел, поэтому это не точно.

Процессоры. Для сервера терминалов не нужны очень производительные процессоры. Здесь надо сделать упор на число ядер. Можно использовать процессоры из линейки Intel Xeon или аналогичные.

Память. Для системы нужно 4 Гб. Далее, мы замеряли, сколько сейчас в 1C:ERP может потреблять тонкий клиент. Как замеряли: я захожу на терминальный сервер, открываю диспетчер задач, сортирую все процессы 1С и смотрю, сколько кто памяти потребляет. Так вот, к сожалению, до 1 Гб тонкий клиент потребляет при активной работе в 1C:ERP. Поэтому планируя сервер терминалов, только на 1С закладывайте минимум по 1 Гб на каждого активного пользователя.

Диски. Показатели IOPS для дисков должны быть от 25000 – терминальные сервера, как правило, виртуальные, поэтому здесь стоит говорить об IOPS-ах.

 

Среда разработки

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

  • размер информационной базы;

  • количество разработчиков;

  • количество консультантов.

И вывели вот такую формулу – для сервера баз данных нам достаточно:

  • Процессор – от 4 ядер с частотой от 1.9ГГц

  • Оперативная память, количество которой рассчитывается по формуле – получается примерно 3 Гб на одного разработчика и 0.5 Гб на одного консультанта.

  • Свободное место на диске – по копии продуктивной базы на каждого разработчика

Для сервера приложений оперативной памяти нужно больше – примерно 4 Гб для разработчика, 1 Гб для консультанта.

И вот такие параметры для сервера терминалов.

Обратите внимание, что при разработке в 1С:ERP на сервере терминалов конфигуратор легко может сожрать 5-6 Гб оперативной памяти.

 

Примеры реального подбора оборудования

Здесь я привел два примера реальных подборов оборудования для 1С:ERP.

На слайде приведены входные данные по первому клиенту.

И конкретное оборудование, которое было выбрано для первого случая.

Входные данные по второму клиенту.

И выбранное для второго клиента оборудование.

 

Вопросы:

  • Сколько ядер нужно под СУБД MS SQL

  • Трудно сказать, сколько ядер под MS SQL. Как я говорил, самый правильный способ подобрать оборудование для сервера ERP – это арендовать на месяц сервер, развернуть Тест-центр, понять, сколько у вас пользователей, сколько у вас ключевых операций и просто тесты погонять – хотя бы типовые тесты.

  • Какая должна быть конфигурация компьютера разработчика для ERP?

  • SSD и от 8 Гб оперативной памяти. Если этого нет – даже не пытайтесь ERP разрабатывать. Лучше 16 Гб, но 8 Гб тоже работает. И обязательное условие – SSD.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Ekaterinburg.Online. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта и INFOSTART EVENT 2021 (6-8 мая, СПб).

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Eeeehhhh 26.03.21 14:28 Сейчас в теме
Вижу фразу про рамдиск - закрываю статью. TempDB на него это просто на отлично.
andrey_prykin; +1 1 Ответить
3. Gilev.Vyacheslav 1879 26.03.21 14:49 Сейчас в теме
(1) вы это сотрудникам фирмы 1С скажите, которые на нем одно время журнал регистрации держали )))

а если серьезно, для определенных ситуаций рам-диск бывает спасением, правда как только интел выкатит процы с PCI 4.0 есть смысл https://ark.intel.com/content/www/us/en/ark/products/201859/intel-optane-ssd-dc-p5800x-series-1-6tb-2-5in-pcie-x4-3d-xpoint.html , а для АМД c PCI 4.0 уже сейчас Samsung PM1735 ставить вместо РАМ-диска так как скорости приблизились к скорости оперативной памяти
2. Gilev.Vyacheslav 1879 26.03.21 14:45 Сейчас в теме
И он выкидывает примерно одну и ту же конфигурацию для двух-трех серверов.

Сервис выдает от intel Core i3-10320 для бюджетников на пяток сотрудников до intel Xeon 8268 Platinum для 2000 пользователей. Там есть разные "шаги". Чем ближе к крайним значениям тем меньше будет вариаций.
Наибольшая градация между 100 и 800 пользователями. Кроме того, в отличии от статичных методичек мы модели процессоров, дисков и т.п. регулярно обновляем. На тысячу пользователей при совмещение ролей 1С и СУБД сервис выдаст AMD EPYC 7742 2.25ГГц 64C/128T 2шт.

Делать классификацию дисков только по иопсам очень некачественно.

По рассчитываемым параметрам. Наше мнение что это "заигрывания" когда нужно утвердить сервер подешевле. Яркий пример не раз происходивший на наших проектах именно с ЕРП. Люди переходили ну скажем в 8.3.13 на 8.3.17 и при расчете себестоимости для 300 пользователей потребление оперативки с 90 Гб ОЗУ возрастало до 150 Гб. Получается что расчетный подход "подставляет" тех кто обосновывал железку на этом основании. Или еще более яркий пример - люди покупают сервер под УПП (да,да, она еще много где) а потом мигрируют на ЕРП. Конечно сервер 1С будет на порядок больше только одной оперативки кушать. Или им что выкидывать сервер при миграции? Имхо есть смысл брать сервер помня про то что если брать впритык то даже переделка какого-либо алгоритма с однопоточного на многопоточный может привести к проблемам.
nsirotkin@mail.ru; hafizovdb; starik-2005; sapervodichka; +4 Ответить
4. PerlAmutor 124 26.03.21 18:35 Сейчас в теме
(2)
Люди переходили ну скажем в 8.3.13 на 8.3.17 и при расчете себестоимости для 300 пользователей потребление оперативки с 90 Гб ОЗУ возрастало до 150 Гб.

Получилось выяснить с чем конкретно это было связано?
sapervodichka; +1 Ответить
5. Gilev.Vyacheslav 1879 26.03.21 20:06 Сейчас в теме
(4) каждый последующий релиз платформы после 8.3.11 потребляет всё больше и больше ресурсов, видимо шуточный закон Вирта действует «программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее» (ребята там тоже как и мы тестировали https://efsol.ru/articles/performance-1s-8.html )

даже пытаться не стали, мы всё равно этим платформу не перепишем, что толку от констатации факта

и это еще молчу про вот-вот выйдущий из беты ДатаАкселератор, вот когда станет тяжело ресурсы прикидывать...
EliasShy; dexxxqqq; sapervodichka; pyrkin_vanya; +4 Ответить
6. pyrkin_vanya 427 26.03.21 23:00 Сейчас в теме
(5)год назад я на своем серваке с nwmeшными дисками мог спокойно запустить 10 баз и работать. А сейчас та же унфка с торможением открывает простую форму списка номенклатуры. Это трешь, товарищи, а что дальше!?))))
Dozkni; Jimbo; XAKEP; +3 Ответить
7. muskul 27.03.21 04:38 Сейчас в теме
(6)зато взаимодействие со смайликами
WellMaster; Dozkni; FatPanzer; XAKEP; +4 Ответить
14. dexxxqqq 27.03.21 21:31 Сейчас в теме
(6) мне бухи как-то сказали после обновления: "ой, какая милая кошечка". Через неделю говорят: "уберите этого **** кота, но сделайте побыстрее!!!"
25. Gilev.Vyacheslav 1879 29.03.21 13:59 Сейчас в теме
(6) в последнее время качество тонкого клиента вызывает много вопросов, мало нам тормознутого скд , так еще мы вот что обнаружили http://www.gilev.ru/hiddenfields/
pyrkin_vanya; +1 Ответить
26. pyrkin_vanya 427 29.03.21 14:04 Сейчас в теме
(25)Любопытное наблюдение.
8. sapervodichka 4280 27.03.21 10:30 Сейчас в теме
Цитата: "Более того, в 2017 году я на Инфостарте опубликовал статью о том, как подбирать оборудование для серверов 1С, но пришел некто В.Гилев и сказал, что я во всем не прав."

- Виталий, большинство прекрасно знает кто такой Вячеслав Гилев и многие опираются на его профессиональное мнение и тысячи компаний и людей пользуются и его сайтом и его сервисами.

Несмотря на то что статья хорошая и полезная и вообще я к твоему материалу и к тебе проникнут уважением, ставлю минус чисто за неправильное человеческое отношение с твоей стороны к труду и пользе, которые публикации Вячеслава принесли многим в работе в том числе и мне.
Вячеслав не некто и не отрицает все в абсолюте, а конкретно очень умный и трудолюбивый человек дающий полезные советы. Писать о нем "некто" низкий пиар на его имени.
На 100 % уверен, что ты мог бы подобрать более уместную формулировку в статье.
hafizovdb; itoptimum; FatPanzer; VAAngelov; +4 4 Ответить
18. Tavalik 2486 29.03.21 09:27 Сейчас в теме
(8)
Добрый день. Ни в коем случае не хотел никого обидеть, в том числе уважаемого мною Вячеслава.
Не думал, что эта фраза будет понята в подобном ключе. Формулировку в статье поменял.
sergey279; Dozkni; sapervodichka; +3 Ответить
23. sapervodichka 4280 29.03.21 10:36 Сейчас в теме
29. sapervodichka 4280 29.03.21 16:43 Сейчас в теме
(24) сколько платят за такую адовую работу?
30. sergey279 99 29.03.21 21:31 Сейчас в теме
(29)
Бенефит еще обсуждать рано. Я являюсь Вице-президентом и заодно Диопером креативного старт Апа. Мы сейчас опробируем модель концепта по Роудмэпу.

Наш Кастомер потребитель Экологически чистых плодов подсолнечника категории премиум. Создана платформа и запущены маркетинговые бюджеты в продвижение. Логистика работает как часы, но наш клиент не всегда знает код подъезда домофона где сидит и применяемые Воркаут под отрыванию магнита не всеми встречаются с одобрением.

Поэтому нам нужные кадры со знанием OLAP кубов и широкими стеками Скилзов, работающие по Аджайл под водопадом, полностью лишенные чувство юмора. Скрам-мастер релокейшен авангардом на первые точки, для Реплай непрогрессивной общественности у лавки перед подъездом всяких панчалайнов "а звонить вас не учили".

Вы нам подходите.
WellMaster; Tavalik; +2 Ответить
31. Tavalik 2486 30.03.21 09:03 Сейчас в теме
(30)

О, я тоже хочу такую работу.

Я вырос в 90-х, поэтому в теме употребления экологически чистых плодов подсолнечника на лавке перед подъездом.
32. sapervodichka 4280 30.03.21 09:34 Сейчас в теме
(30) диктуйте адрес, ручку распишу, подготовлю и пришлю резюме в ближайшее отделение почты россии
28. sapervodichka 4280 29.03.21 16:40 Сейчас в теме
9. starik-2005 2301 27.03.21 11:23 Сейчас в теме
Мне, дично, статья не понравидась. Не понравидась она тем, что автор прыгает с одного на другое, часто это выглядит, как противоречие. Вот такое впечатление. Т.к. отвечаю с мобилы, то цитировать те моменты, которые мне показались противоречивыми, не буду.

Если говорить за ЕРП и платформу, то ЕРП очень по разному можно настроить - можно простой учет вести, выпуск без заказов, передача в кладовую и из нее. Можно же запилить стлпиццот спецификаций, серии с себестоимостью, сотни производственных этапов - мидлиарды мышынных кликов для того, чтобы понять, что еще нужно пару миллиардов этих кликов, ибо нихрена толком P&L не сходится с простым оасчетом в эксельке.

Всегда можно контур ввода документов автоматизировать, сотворив из ЕРП простую и понятную систему фиксации событий хозяйственной деятельности, которые после обработки формируют финансовый результат этой деятельнлсти, отвечая на простые и конкретные вопросы бизнеса. Но ведь почти никто не идет этим путем, т.к. не воспринимают систему, как хранилизе транзакций и поставщика данных для отчетности. Большинство почему-то воспринимает ЕРП, как палочку-выручалочку, которая все сама распланирует, произведет, отразит и выжаст план-факт, профитлосс, баланс, все эти крутые показатели ебитда и т.д. Но все эти показатели в 99% внедрений из-за качества данных очень приблизительны, а иногда даже и близко к правде нет.

Так вот производительность - это способность обслужить множество транзакций - входязих событий. А ЕРП и последняя платформа - это отжираловка памяти на сложных формах АРМ с миллионами реквизитов, гоняемых между сервером и клиентом. Да и документы все более усложняются, в них появляется куча всевеликой хрени для каждого чиха, который есть у 1% пользователей. При том часто отсутствуют нужные здесь и сейчас этому вот клиенту данные (собираемые в событиях аспекты, которых в ЕРП искаропки нет), что выливается или в допреквизиты - дополнительные соединения в запросах для извлечения жанных, или в дообогащение объектов соответствующими полями (и тут соединений нет, что может улучшить жизнь в ряже случаев, т.к. характеристики не превращаются в монструозные обвязки в запросах). Ну и роли - чем их больше, тем дольше 1С-сервер генерит запрос (статья была на днях, 1261 роль заставляла сервер работать 3 секунды, чтобы сгенерить такой же запрос, как под полными правами за сотые доли этой секунды).
philya; Dozkni; pyrkin_vanya; FatPanzer; triviumfan; sapervodichka; +6 Ответить
20. Tavalik 2486 29.03.21 09:31 Сейчас в теме
(9)
Добрый день. Полностью с вами согласен.
Я в докладе про это и говорил, что подобрать железо для 1С:ERP очень непростая и неблагодарная задача. А те способы и источники, которые сейчас есть, мягко говоря, не подходят.
34. starik-2005 2301 30.03.21 12:02 Сейчас в теме
(20)
Я в докладе про это и говорил, что подобрать железо для 1С:ERP очень непростая и неблагодарная задача. А те способы и источники, которые сейчас есть, мягко говоря, не подходят.
Извиняюсь за множество ошибок в сообщении выше - писал без очков со смарта в метро )))

Вообще выбор железа - это проблема не железа, а работы 1С на нем. Ведь та же проблема с ролями решается или скрупулезной настройкой в отдельных ролях для совокупности прав доступа, или же очень быстрым процессором. Ведь ТРИ секунды на одном запросе - это один запрос, а в системе их сотни, а то и тысячи. В итоге получаешь вроде бы хорошую производительность на нагрузочном тесте с неким "усредненным" пользователем, а потом огребаешь проблемы производительности у тех пользователей, с ролями которых ты так не извращался.

Также сценарии теста обычно завязаны на транзакционную деятельность, но в реальной жизни в фоне будет масса запросов к OLAP-кубику, т.е. все эти ОСВ, карточки счетов и т.д. в сотнях разрезов. И поэтому без выноса OLAP-нагрузки ты получишь кучу тех самых "микроожиданий", вызывающих просто нереальную нагрузку на сервер - и память на них расходуется, и процессорное время, и дисковый IOPS. А в базовый тестовый функционал все эти попытки прочитать много данных для разнообразных отчетов никак не включаются. И народ удивляется, что тестовый стенд вроде как работал в пределах целевых показателей APDEX, а после того, как на него упала рабочая нагрузка (а база растет, количество транзакций увеличивается каждый день, растет фрагментация индексов, потребление памяти, дисковой очереди, процессорного времени на все большем количестве пустых циклов "микроожиданий"), все начинает мягко говоря "тормозить".

Вот на мастер-классе одном сотрудник Софтпоинта (или как их там) рассказывал, что простой вроде бы запрос с соединением по характеристикам без номенклатуры заставил сервер неимоверно жрать ресурсы и, соответственно, освобождать какие-то нужные данные. Так вот нет никакой гарантии, что периодически в рабочей системе не будет появляться вот таких вот запросов. И я больше чем уверен, что 99% 1С-негов даже не понимают, почему при соединении вроде бы по полю из индекса система так себя ведет. Более того, с учетом процента тех, кто после профа по тех.вопросам сдал на эксперта, 90% 1С-негов это не смогут понять никогда.

Так вот с учетом этого всегда есть простое и эффективное решение:
1. Потратить стопиццот кликов на отдельные роли, а не собирать эти роли из тысячи базовых ролей ERP.
2. Выделить OLAP-контур отдельно (копия базы, снапшот, олвэйсон, миграйция журналов транзацкий или даже дата-акселератор или отдельное хранилище данных для отчетности, вплоть до внешнего BI).
3. Не жалеть денег на быстрые диски для транзакционной части. Она, обычно, очень небольшая эта часть - последний месяц или квартал, 90% документов - это вообще оперативные документы, пишутся в конец таблицы, ибо сортировка по периоду. И потом исторические данные мигрировать хоть на HDD - не сильно в скорости потеряете, при том они часто не нужны, если выделены в отдельный BI. С другой стороны, сейчас не очень скоростные SSD энтерпрайзные стоят весьма демократично, а для исторических данных важна скорость последовательного чтения в большинстве своем - вычитывание индекса или таблицы целиком в RAM, а ведь исторические данные вряд ли будут с высоким уровнем фрагментации и неупорядоченности храниться.

Так что при хорошей настройке системы достаточно одного ядра на 10 пользователей. И EPYC, которые выходят в этом году (12 каналов памяти DDR5, 96 ядер, 192 потока, 4 сокета) даже при низкой частоте могут дать жить не одной тысяче юзеров, но только в том случае, если архитектура системы не предполагает архитектуры ларька с тремя пользователями, которые генерируют "гетерогенную" нагрузку на свой R5 1600.
Golovenkin; +1 Ответить
10. user1534961 27.03.21 11:38 Сейчас в теме
А зачем 1261 роль если на каждого пользователя можно сделать свое расширение?
11. sapervodichka 4280 27.03.21 11:44 Сейчас в теме
(10) улыбнул про расширение для каждого пользователя )))) для начала в ЕРП работает в среднем от 100 до 500 пользователей, если открыть ERP и погрузится в реальный мир из тысячи объектов и тысячи ролей, то даже расширение для одного пользователя станет неподъемной задачей
user1534961; +1 Ответить
12. triviumfan 24 27.03.21 16:35 Сейчас в теме
Достаточно подробно, где-то с противоречиями, но все равно спасибо. Плюсик :)
13. kofeinik 23 27.03.21 19:45 Сейчас в теме
Шел 2021 год, "специалисты" по подбору серверного оборудования ssd до сих пор объединяют в raid.
Йожкин Кот; +1 Ответить
21. Tavalik 2486 29.03.21 09:36 Сейчас в теме
(13)
Добрый день.
Так я наоборот в статье говорю о том, что объединять SSD в RAID НЕ нужно.
Но в моей реальной практике общения с IT-специалистами клиентов, у администраторов дергается глаз при упоминании того, чтобы расположить продуктивные базы на SSD без рейда. Аргументируют, что "не надежно" и тому подобное.
15. Tarlich 102 28.03.21 21:54 Сейчас в теме
но пришел некто В.Гилев и сказал, что я во всем не прав.

подожду отзыв и на эту статью -))
Подбор железа - это проблема железячника а не 1с ника -))
Читая отзывы (и статьи) складывается мнение что именно 1С ник купил за свои деньги "Железку" и теперь БОГ ...
22. Tavalik 2486 29.03.21 09:39 Сейчас в теме
(15)
Добрый день.

Подбор железа - это проблема железячника а не 1с ника -))


Полностью согласен. Было бы здорово, если бы так и было. Но на моей практике, приходится заниматься подбором именно "1С-никам", т. к. многие системные администраторы, что называется "на местах", плохо понимают специфику работы 1С.

Очень хочется, чтобы толковых специалистов становилось больше и каждый занимался своим делом.
Evil Beaver; +1 Ответить
16. insurgut 194 28.03.21 22:00 Сейчас в теме
У меня пару раз в рейде SSD померли на порядок раньше, чем в одиночку, при том, что разницы в производительности не заметно было... после этого в рейд их не объединяю. Может особенность рейд-контроллера была, может просто стечение обстоятельств. Впрочем, как на .M2 NVMe появились, SSD SATA я вообще перестал понимать зачем они и для кого.
sapervodichka; +1 Ответить
17. FatPanzer 13 29.03.21 09:20 Сейчас в теме
(16) Рейд - он не совсем для повышения производительности...
19. insurgut 194 29.03.21 09:28 Сейчас в теме
(17) в моем случае ни скорости ни отказоустойчивости не было получено, были и 0 и 1 уровня.
27. Gilev.Vyacheslav 1879 29.03.21 14:05 Сейчас в теме
(16) у нас может и не раньше, но износились в рейда оба SSD с минимальной разницей , для SSD рейд как зеркало ценность представляет минимальную
http://www.gilev.ru/nvmeraid/
нынешние диски NVMe ентерпрайз уровня не имеют рисков старых HDD, но люди по привычке продолжают собирать зеркала
ubnkfl; sapervodichka; insurgut; +3 Ответить
33. ZLENKO 390 30.03.21 10:49 Сейчас в теме
(27) Подскажите каким образом устраняются риски в NVMe Enterpise?
35. starik-2005 2301 30.03.21 12:16 Сейчас в теме
(33) в большинстве своем риск HDD - это "выход из строя" дорожки или ее участка. В итоге при попытке прочитать этот участок диск выдает ошибку. В SSD запись происходит в память, при том при записи происходит исключение вышедших из строя ячеек и они перераспределяются между резервом. Энтерпрайзные NVMe (я так понимаю, тут речь идет об Optane) имеют другие характеристики живучести памяти ячеек и полный аппаратный контроль за каждой из них. Для примера, ресурс "обычного" SSD на базе TLC на 128 Гб - это, учловно, 80-200 TBW (этакая "условная" гарантия, фактически количество перезаписей больше, но гарантия в этом пределе), а на Optane на 100 Гб диске гарантированный производителем TBW превышает 10000, т.е. в СТО раз выше. Такого ресурса для 1С системе хватит лет на СТО )))

НО! Риск выхода из строя накопителя (контроллера, например) все равно остается. Так что я бы не сказал, что все риски закрываются, но самые распространенные - да, ибо нет крутящихся и "трущихся" деталек, нет чувствительности к вибрациям, даже падениям.

Ну и скорость резервирования с такого диска на другой такой может быть условно "онлайновой".
Gilev.Vyacheslav; +1 Ответить
36. Gilev.Vyacheslav 1879 30.03.21 12:59 Сейчас в теме
(33) наибольшему риску выхода из строя подвержены детали с "механическим движением" - если это надо расшифровывать, то возможно вы не своим делом занимаетесь
второй по значимости риск - низкий ресурс перезаписи или точнее падение характеристик и увеличения ошибок чтения диска по исчерпанию ресурса перезаписи
третье, в ентерпрайзе отсутствуют ультрарадикальные способы удешевления типа Samsung Intelligent Turbo Write (но это больше к устойчивости характеристик, чем к надежности, но отделить целиком нельзя)
39. ZLENKO 390 30.03.21 18:39 Сейчас в теме
(36)
если это надо расшифровывать, то возможно вы не своим делом занимаетесь

Я занимаюсь своими делами (не сборкой серверов), но тем не менее мне интересны эта тема и Ваше мнение.
40. Gilev.Vyacheslav 1879 30.03.21 20:16 Сейчас в теме
(39) не интересны, ваши поступки выдают вас лучше всяких слов
38. ZLENKO 390 30.03.21 18:35 Сейчас в теме
(27)
нынешние диски NVMe ентерпрайз уровня не имеют рисков старых HDD

Правильно ли я понимаю, что другие SSD (не NVMe и не ентерпрайз) имеют риски старых HDD?
Расшифруйте пожалуйста.
41. Gilev.Vyacheslav 1879 30.03.21 20:19 Сейчас в теме
(38) NVMe - это спецификация на протоколы доступа к твердотельным накопителям (SSD), можно сказать противопоставление SAS|SATA
NVMe - это сужение общего количества SSD до наиболее быстрых
ентерпрайз - это другое сужение SSD до наиболее надежных и годящихся к промышленному применению
user1534961; +1 Ответить
47. ZLENKO 390 31.03.21 11:29 Сейчас в теме
(41) В таком случае верным ли будет высказывание, что все современные SSD не имеют рисков старых HDD, по той простой причине что не имеют движущихся частей, а enterpise версии имеют повышенную надежность?
37. ildary 30.03.21 15:48 Сейчас в теме
Сильно портит впечатление от статьи вот это:

Пользователей надо беречь, поэтому процессор им ставим от 3ГГц, чтобы не тормозило.
А вот программистов не жалко - пусть страдают от тормозов на 2ГГц.
51. Tavalik 2486 31.03.21 12:06 Сейчас в теме
(37)

В моей практике, для тестового сервера хватало и таких процессоров. Но если у вас есть ресурсы для более дорогих и быстрых процессоров для разработчиков, я только за.
63. ildary 31.03.21 16:24 Сейчас в теме
(51)
В моей практике, для тестового сервера хватало и таких процессоров. Но если у вас есть ресурсы для более дорогих и быстрых процессоров для разработчиков, я только за.


Хватало? Для работы или для медитации:

пока конфигуратор откроется,
пока хранилище подтянется,
пока форма документа в кеше обновится,
пока конфигурация сохранится,
пока 1С в режиме предприятия заново загрузится...

И так весь день...
66. Tavalik 2486 31.03.21 17:45 Сейчас в теме
(63)
Эти операции от процессора не сильно зависят.
Проверьте, насколько у вас на тестовом контуре быстрые диски. Без SSD разрабатывать, мягко говоря, не очень удобно.

Также хорошо бы, чтобы у разработчика было 16 и больше Гб. оперативной памяти.
42. Hadgehogs 337 31.03.21 10:17 Сейчас в теме
Дня доброго.
Редко сюда захожу, но такую тему пропустить не мог.
Есть пара вопросов Гилеву Вячеславу, если ему не лениво.

1) В какие случаях вы разделяете сервер СУБД и сервер 1С на разные машины
2) Исследовали ли вы влияние канальности памяти (2, 4, 6 каналов) и ее частоты на производительность?
43. Gilev.Vyacheslav 1879 31.03.21 10:39 Сейчас в теме
(42)
2) Исследовали ли вы влияние канальности памяти (2, 4, 6 каналов) и ее частоты на производительность?
Будет ли достаточно Вам описания в нашей статье gilev.ru/ram или Вы о чём то другом?
46. Hadgehogs 337 31.03.21 11:12 Сейчас в теме
(43)
Будет ли достаточно Вам описания в нашей статье gilev.ru/ram или Вы о чём то другом?


Нет, недостаточно.
Речь об этом, но там как раз сухая теория.

Я спрашивал о практике.
Выполняли ли вы сравнительные тесты именно 1С на примерно равных по частотам процессорах с разной канальностью памяти (2 и 4 к примеру). Или, что проще, 1 и 2.

Я вот сейчас подумал, а я в принципе и сам могу сделать у себя эти тесты, просто вытащив одну из планок памяти и уйдя в одноканальный режим.
61. Gilev.Vyacheslav 1879 31.03.21 15:24 Сейчас в теме
(46) какую конкретно операцию в 1С вы хотите оценить на влияние планок памяти?
44. Gilev.Vyacheslav 1879 31.03.21 11:03 Сейчас в теме
(42)
1) В какие случаях вы разделяете сервер СУБД и сервер 1С на разные машины

Исключительно по бытовым ситуативным ограничениям и приоритетам.
С точки зрения производительности при доступности Shared Memory есть смысл побороться за совмещение.
Но любое совмещение требует большего числа ресурсов, и ядер процессоров в том числе. Поэтому если клиент говорит что он будет покупать только Windows Server Standart и SQL Server Standart, а лицензирование то проходит по общему числу ядер, то экономически оправданным с некой потерей скорости будет разнесение серверов (будет больше доступно суммарно ресурсов). Другими влияющими ситуациями могут быть навязанное зеркалирование, которое отключает Shared Memory или линукс и другие субд. Еще одной причиной разделить даже в ентрепрайз лицензиях будет аппаратной ограничение сверху, может не быть банально достаточно производительной железки. Мы к примеру сервера с интерконнектом типа HPE суперддом к использованию не предлагаем. В автоматическом подборе сейчас без numa на общей памяти процессоров стоят 2х сокетные АМД по 64 ядра для тысячи пользователей.
Ну и еще одним фактором является квалификация и привычки специалистов в плане мониторинга. Есть ситуации когда люди не готовы заниматься разделением ресурсов по ролям на совмещенном сервере, ограничивать скуль по памяти и другим ресурсам если необходимо.
Поэтому совокупность всего перечисленного из приоритетов того чей сервер в итоге позволяет понять сидим ли мы на совмещенном 1С и субд сервере или жертвуем скоростью другим задачам.
Думаю что ничего нового Вам не сказал.
45. Hadgehogs 337 31.03.21 11:08 Сейчас в теме
(44)
Но любое совмещение требует большего числа ресурсов, и ядер процессоров в том числе.


Ну вот тут не согласен. Это массовое заблуждение.
48. Hadgehogs 337 31.03.21 11:51 Сейчас в теме
(45) Клиент отправил запрос на сервер 1С. Сервер создал поток под запрос клиента (не трогая СУБД), поток поделал что-то, ему нужны данные с СУБД. Он делает запрос к СУБД. СУБД начинает выполнять запрос. Что в это время делает поток 1С?

Больше ресурсов потребуется (оперативная память), но не число ядер.
50. Gilev.Vyacheslav 1879 31.03.21 11:56 Сейчас в теме
(48) а что в это время делает другой поток 1С? у вас упрощенная логика - по вашему все сеансы сначала отъели 1С а потом субд, причем синхронно
52. Hadgehogs 337 31.03.21 12:11 Сейчас в теме
(50) У вас много умных фраз, но суть проста. В данный конкретный момент над одним серверным вызовом работает либо поток SQL (при MDOP=1) либо поток 1С. Одновременно они не работают.
Поэтому ядро процессора загружено либо потоком 1С либо потоком SQL.
Поэтому "совмещение требует большего числа ресурсов, но не ядер процессоров".
54. Gilev.Vyacheslav 1879 31.03.21 12:55 Сейчас в теме
(52) повторяю еще раз - ваша идея могла бы сработать, если бы все пользователи одномоментно выполняли одну и ту же операцию
да и то на их синхронизацию серверу 1С тоже некоторые ресурсы тратить пришлось хотя бы на управляемые блокировки
но на деле выполняются разные операции по профилю нагрузки и главное в разнобой
если Вам всё ещё не понятно, то могу только посочувствовать
56. Hadgehogs 337 31.03.21 13:09 Сейчас в теме
(54) Я вам - аналогично сочувствую.
49. Gilev.Vyacheslav 1879 31.03.21 11:55 Сейчас в теме
(45) каждая роль потребляет ресурсы, у 1с в большинстве случаев это потребление одновременное
если вы добавите третью роль то потребуются еще ресусры
при чем рости должна не обязательно загрузка, а мощности для пикового потребления
так что я не согласен с вашим несогласием ;)
53. Hadgehogs 337 31.03.21 12:13 Сейчас в теме
(49) Выполните на свободной машине запрос с декартовым произведением, и посмотрите в это время на загрузку процессора по серверу 1С.
55. Gilev.Vyacheslav 1879 31.03.21 12:56 Сейчас в теме
(53) выполните одновременно декартово произведение и обновление полнотекстового поиска кластера 1С (не скуля) регламентом 1С или аналогичное потребляющие ресурсы 1С, чего тупить то
или вы исходите из того что на сервере только монопольно один работает )))
57. Hadgehogs 337 31.03.21 13:16 Сейчас в теме
(55) Я веду речь о том, что

Если у нас есть 8 одновременных сферических пользователя, работающих на 100%.
И есть выбор:
1) Взять сервер 1С+СУБД на 8 ядерном процессоре.
2) Или взять 2 сервера под СУБД + 1С на 8 ядер каждый.

То никаким образом 2 вариант не будет быстрее 1-ого.
58. sapervodichka 4280 31.03.21 14:13 Сейчас в теме
(57) т.е. если сделать сценарный тест: где создать 8 rphost 1С (по 1 на каждого сферического пользователя), и забить их на 100% неделимыми алгоритмами расчетов в рамках сервера 1С, и в ходе расчетов в разнобой с каждого rphost запрашивать большие пакеты данных у СУБД.
То наверное это чудо тест как-то сразу намертво положит машину где будет 1С и СУБД совмещены, а если в рамках 2 машин, то наверное как то будет двигаться. Или всё-таки в рамках 1 машины (1С+СУБД) этот сценарий отработает быстрее?
59. Hadgehogs 337 31.03.21 14:28 Сейчас в теме
(58)Естественно, положит машину. Ну, я про то, что интерфейс Винды будет слайдами отрисовываться. Но отработает быстрее, тупо из за отсутствия задержек при работе по сети. Конечно, мы напишем не глупенькие тесты, которые открывают одну обработку и запускают там хороший такой запрос, а маленькие запросики в цикле, которые эмитируют подергивания config, которые входят в топ запросов в реальной жизни (ведь так, Вячеслав?).
60. Hadgehogs 337 31.03.21 14:32 Сейчас в теме
(58) Проблема человеков в том, что многое они пытаются воспринимать многие ситуации как черный ящик, без разбора ситуации. Ну некогда людям копаться.
Вот и тут - держите черный ящик "СУБД-1С на разных серверах", он исторически почему то хорошо работал.

Исторически он хорошо работал, когда ядер тупо не хватало и то, с надеждой на то, что нагрузка размажется по времени на сервер 1С и сервер СУБД по 50% на каждый в оптимальном варианте (что далеко не так, так как сервер 1С забирает больше процессорного времени).
62. Gilev.Vyacheslav 1879 31.03.21 15:34 Сейчас в теме
(58) когда оба роли утилизируют процессор под завязку, то будет происходит это раздельно и совмещенно сильной разницы не будет
это лишь будет говорить о том что той или другой или обеим ролям надо больше ресурсов процессора
если основное время приходится на ожидания очереди к процессорам, то особой значимости отклик дисков или сети не будет играть
(57) рассуждения про сеть при очереди к процессорам неуместны

а вот если мы говорим про нормальную работу, когда ресурсов хватает, ожиданий нет, то для коротких операций длительностью 0.001 сек отклик сети или sahred memory будет значим
такие операции не составляют основную часть, но их хватает (особенно при вызове в цикле) и те кто их игнорируют и например помещают роутер (сегмент) между 1С и субд с откликом отличным от 0 мс вопят что это 1С плохая не понимая сути вещей
sapervodichka; +1 Ответить
64. Hadgehogs 337 31.03.21 16:49 Сейчас в теме
(62)Где вы видите очереди к процессорам в (57) ? В этом примере их как раз нет. Пример сферический, понятно, что будет 8+1 ядро на прикладные расходы ОС.
Что до маленьких запросов
Выполняем
SEL ECT TOP 10
[Execution count] = execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)
,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FR OM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Execution count] DESC;
и видим
Прикрепленные файлы:
Cyberhawk; +1 Ответить
68. Gilev.Vyacheslav 1879 31.03.21 18:54 Сейчас в теме
(64) я с вами спорить не собираюсь, если вы считаете что при 100% загрузке всех ядер не будет очередей, ну ок, считайте дальше
69. Hadgehogs 337 31.03.21 19:02 Сейчас в теме
71. Hadgehogs 337 31.03.21 19:04 Сейчас в теме
(68) А ведь когда то я планировал попробовать пойти к вам работать.
Хорошо, что судьбинушка отвела.
65. Hadgehogs 337 31.03.21 16:54 Сейчас в теме
(62)Еще бы было интересно послушать про кластер из нескольких серверов.

В каких случаях вы бы их использовали?
67. Gilev.Vyacheslav 1879 31.03.21 18:53 Сейчас в теме
(65) а нам было бы интересно за обучение взять деньги, кажется это справедливым
http://www.gilev.ru/kurs/
user754943; +1 Ответить
70. Hadgehogs 337 31.03.21 19:02 Сейчас в теме
(67) Спасибо, не заинтересован.
72. aspirator23 453 01.04.21 11:44 Сейчас в теме
Из публикации более интересны комментарии "некоего" :) Гилева чем сама публикация. Пусть на меня Вячеслав не обижается. :)
user678861_9209206666; WellMaster; +2 Ответить
73. cdiamond 183 16.04.21 09:15 Сейчас в теме
Вообще сперва бы определиться с типом лицензии 1С. А то возьмут ПРОФ и к нему упомянутый в статье CХД и сервер 32-ядерный, в котором еще гипертрейдинг по рекомендации включат. Все эти рекомендации летят коту под хвост.
А ещё есть такая хитрая штука как NUMA со своими особенностями, которые необходимо учитывать, особенно в выборе "марки" СУБД.
Вообще тема выбора именно железа характерна больше для России. Редко кто принимает в расчет тот факт, что например ежегодная плата за лицензию на MSSQL Enterprise будет возможно стоить дороже всего этого железного добра (если платить по чесноку за все ядра).
Оставьте свое сообщение

См. также

Настройка сборки данных в Performance Monitor Windows Server. Рецепты от Капитана

Сервера v8 1cv8.cf Бесплатно (free)

Каждый опытный сисадмин знает, что лучший показатель ухудшения быстродействия 1С, это главный бухгалтер, движущийся в сторону ИТ отдела со скоростью, превышающей 1.1 м/с. Но только мудрейшие из них настраивают сбор счетчиков, чтобы эта встреча не застала их врасплох. Об этом и поговорим под катом...

вчера в 18:00    143    capitan    6    

1C + Linux + PostgreSQL + Apache

Администрирование данных 1С Apache Администрирование СУБД Администрирование веб-серверов Linux Сервера v8 Бесплатно (free)

Дружим 1С с Линуксом ИЛИ Установка окружения для работы с 1С на Линуксе под Постгресом и Апачем (в 2021-м году).

26.03.2018    50442    SerVer1C    84