О быстродействии, настройке оборудования для 1С и не только

Если Вы решите заказать услугу оптимизации быстродействия 1С нам — вам сюда. Мы максимально быстро решим проблему, обучим Вас, чтобы после наших настроек Вы могли делать все сами. 

Данная статья написана в авторском стиле и не претендует на истину в последней инстанции. Она посвящается всем, кто хоть как-то взаимодействует с 1С (пользователям, программистам, администраторам, IT-менеджменту и даже владельцам бизнеса). Отдельно хочется выделить матерых системных администраторов, и чуть ниже по тексту вы поймете почему.

Также хотелось бы сказать, что в данной статье мы рассматриваем потребности среднего (с точки зрения нагрузки на информационные системы 1С) бизнеса (до 100 пользователей одной базы данных, до 2000 отгрузочных документов в день). Иными словами, применять мнение автора для крайностей (всего 5 пользователей базы данных или целых 500 пользователей) не следует, т.к. это слишком частные случаи.

 

Если вы не хотите читать основную статью

Тогда сразу приведу краткий список постулатов. Оговорюсь, что под термином «Сервером 1С» я имею ввиду пару приложений «Сервер 1С» + «Сервер SQL», расположенных как на одной физической машине, так и на разных.

Однако в большинстве своем речь идет о приложении «Сервере 1С», как о более (в сравнении с Сервером SQL) нагруженном элементе. Вот этот список:

1. Боритесь с инерцией мышления Главного Сисадмина.
2. Приложению «1С Предприятие» ресурсы машины требуются мгновенно – прямо сейчас, и не секундой позже. Помните это, настраивая виртуальную машину (а лучше – отказываясь от нее) и планы питания.
3. Серверное решение (им. в виду железо) всегда медленнее десктопного (железа) по той-же цене.
4. Серверное решение почти всегда медленнее десктопного по любой цене. Точнее, конечно можно найти сервер за большие деньги, но соотношение вложений и полученных преимуществ не будет эффективным комплексным решением.
5. Для инфраструктуры 1С серверное решение нужно в очень редких случаях, а именно: когда количество Пользователей, Ждущих Отклика Системы более 8 (на момент написания статья) или более 12 (через полгода)
6. Пользователи, Ждущие Отклика Системы – это НЕ активные пользователи и НЕ сумма активных и пассивных (открывших 1С) пользователи в базе.
7. С одним конкретным пользователем 1С работает одно конкретное ядро процессора, от быстродействия которого зависит комфорт работы пользователя, а, иногда, и других пользователей. Работает либо ядро процессора клиента, либо ядро процессора «Сервера 1С», либо ядро процессора «Сервера SQL». Одновременно это не работает. Ядер нужно не так много, но они нужны быстрые.
8. Пользователей, Ждущих Отклика Системы не так много даже среди активных. Большинство обычно обрабатывают результат предыдущей работы, в то время, как ждущих результата – меньшинство. В самом печальном случае, которого быть не должно, но он обязательно будет – пользователи могут просто «ждать на блокировках» Другого Пользователя, не расходуя ядра. И время их ожидания напрямую зависит от скорости работы ядра, занятого этим самым Другим Пользователем.
9. Боритесь с инерцией мышления Главного Сисадмина.
10. Разносите Тонких Клиентов и «Сервер 1С» по разным физическим машинам. Нет, не так выразился! Не позволяйте сисадмину загнать всех клиентов в терминал, который будет выполняться на виртуальной машине на том же физическом компе, на котором работает «Сервер 1С». Если рассматривается ненормальное, извращенное ☺ решение загнать всех в виртуалку (продиктованное чаще всего желанием сисадминов облегчить свою жизнь в ущерб потребности бизнеса – Быстродействию Системы) – то пусть сисадмин выделит для нее отдельную физическую машину.
11. Не держите антивирус на машине, где стоит приложение «Сервере 1С». Вообще не держите на ней ничего лишнего. На машине «Сервера 1С» не должно ничего выполняться, кроме служб 1С. Ничего! Ни самого малюсенького почтового сервера и мааааленького контроллера AD. Вы спросите – как же не ставить антивирус? Я отвечу:
    1. доступ к машине должен быть только у единственного («знает двое – знает и свинья») квалифицированного администратора 1С.
    2. не пробрасывайте на машину «Сервера 1С» порт внешнего ИП-шника для подключения RDP. Ходите на машину «Сервер 1С» через внутренний RDP с другой машины в сети, на которой стоит антивирус.
12. Поставьте на машину (или машины) «Сервера 1С» и «Сервера SQL» SSD. SSD диски достаточно надежны, гораздо быстрее и дешевле SAS. Некоторые надежны настолько, насколько это даже не требуется
13. Узнавайте все о процессорах заранее, к примеру, здесь.
14. Оцените процессор своего сервера в сравнении с другими с помощью CPU-Z (функция Bench) и правильно интерпретируйте результаты:
    1. Если производительность процессора плавно увеличивается – то где-то у вас (BIOS, план питания Windows, настройки виртуальной машины) включен режим экономии энергии, который погружает ядро процессора в сон каждый раз, когда он остается в покое. А, потом, долго- очень долго выводит его из спячки — в тот самый критичный момент, когда пользователь выполняет незначительное событие (прокрутка формы списка, открытие формы документа) или значительное (проведение документа «Расчет себестоимости»).
    2. Если производительность процессора скачет – у вас что-то выполняется в фоне. Что-то, что вы возможно, не контролируете. Либо (что еще печальнее), у вас виртуальная машина, на хосте которой работает кто-то еще (вирус или майнер биткоинов).
15. Помните о сериализации/десериализации. При работе с управляемой формой (а в современных Типовых Конфигурациях 1С есть только управляемые формы) данные между приложением «Сервер 1С» и приложением «Клиент 1С» передаются в сериализованном виде (xml текст, пригодный для работы в том числе в типовых браузерах – IE, Mozilla, etc), в который данные нужно предварительно преобразовать. Это еще более повышает нагрузку на процессор машины приложения «Сервер 1С».
16. Старайтесь не использовать виртуальные машины, особенно те, которые не можете контролировать. Обязательно найдется матерый сисадмин, который воткнет на хост еще одну виртуалку с динамическим распределением нагрузки. И в нужный момент у вас не будет ресурсов, которые нужны прямо сейчас. Особенно, не используйте несколько виртуальных машин на одном физическом, разнося сервер 1С и SQL по виртуалкам – это бессмысленно.
17. Латентность (время отклика) сети гораздо важнее пропускной способности. Данных по сети от «Сервера 1С» до «Клиента 1С» передается не так много (сотни килобайт), однако они нужны как можно быстрее.
18. Надежность сети гораздо важнее латентности. Сетевые пакеты от «Сервера 1С» до «Клиента 1С» не должны теряться. Задайте себе вопросы: как далеко физически «Сервер 1С» от «Клиента»? сколько до него свичей? что скажет Ping 192.168.0.100 –l 60000 –t -4? И что будет когда вы начнете печатать tiff изображения на клиентах (загрузите сеть по максимуму)?
19. Боритесь с инерцией мышления Главного Сисадмина.
20. Настраивайте SQL
21. Скорость случайного чтения/записи жесткого диска гораздо важнее линейной скорости. Линейную скорость все современные жесткие диски выдадут примерно одинаковую, а случайную – только SSD. Измеряйте свои диски, например Crystal Disk Mark, сравнивайте с другими и разбирайтесь – почему у вас цифры сильно ниже
22. Разнося приложения «Сервер 1С» и «Сервер SQL», учитывайте факт, что «Сервер 1С» потребляет в 4-6 раз больше процессорного времени, чем «Сервер SQL», а с дисковой системой обменивается примерно тем же объемом данных. И тут должны как-бы возникнуть улыбки в сторону Кривых Разработчиков – но как бы не так. «Сервер 1С» фоном выполняет довольно много работ, не видимых пользователю. Это и обновление индекса полнотекстового поиска, и запись журнала регистрации, и работа с сеансовыми данными и множество фоновых заданий типовых конфигурации, и переключения пользователей с одного rphost на другой. Поэтому, для «Сервера 1С» следует выбирать более производительное оборудование, чем для «Сервера SQL».
23. Собирайте технологический журнал ошибок (событие “excp”) – он вам может поведать о многом.
24. Наличие серверной операционной системы не является обязательным для работы приложения сервера 1С и сервера SQL. Их вполне себе можно развернуть на ОС десктопного типа издания «Professional» (минимальное издание ОС, способное работать в Active Directory). Тонкие клиенты подключаются к приложению сервера 1С через TCP соединения, количество которых лимитировано только количеством свободных портов TCP (примерно 65000 свободных).
25. Не экономьте на серверном и клиентском железе. Пользователи найдут отличное оправдание своей лени мыслями вида “Ну пока тут эта ваша 1С тормозит считает, посмотрю ка я новые мемчики Вконтактике”. Или новости. Или курс доллара. И, 1С, скорее всего давно отработает команду, а пользователь будет ходить по этим вашим интернетам. Поверьте, это работает так. Да и если это особый, немецкий, дисциплинированный пользователь – лучше будет, если он будет работать в 1С,  а не ждать ее отклика.
26. Пример сборки машины «Сервера 1С» и машины «Клиента 1С» можно посмотреть в конце основной статьи.

Основная статья

Мы не рассчитывали допустить ошибки, но они обязательно будут

Статья, в целом, родилась под влиянием впечатлений о поголовном непонимании современного положения в области оборудовании и политической ситуации в целом, но мы начнем с 2004 года. В 2004 году я, как сейчас помню, еще застал ситуацию, когда сервера были большими, мощными, закрывались в отдельном помещении с доступом по карточкам (что, актуально и сейчас), а начальник грозился оторвать нам все, что шевелиться, если мы хоть пальцем тронем это дорогое многомилионное оборудование, волнуясь, главным образом, за аппаратуру, а не за данные. Я даже не скажу, что там была за начинка, но сильно сомневаюсь, что она была круче обычного ПК 2010 года, однако, для того времени, на голову превосходила все десктопное. И, вот у нас 2017, и, после рывка Intel 2012 года, вот уже как 5 лет, человеки уперлись в потолок текущих архитектур. В потолок уперлись, а мышление осталось. Мышление о том, что сервер должен быть большим, дорогим и HP. Человеки не сильно поменялись, и, это печально. Боритесь с мышлением Главного Сисадмина.

Мы купили сервер…

И вы уже что-то сделали не так. Сделать правильно вы можете только в одном случае — если вы купите современный сервер XEON (Gold, к примеру), цена одного процессора в котором дойдет до 130 тыс. рублей. Во всех остальных случаях вы купите железо, сильно проигрывающее современном десктопу в производительности и цене. Очень сильно. Как правило серверные процессоры строятся по той же архитектуре, что и десктопные, но с задержкой выпуска. Для сравнения — рекомендую тестирование процессора утилитой CPU-Z

Серверные машины – это солидно и надежно

Часто, фирмы выбирают сервер по причине надежности. Резервная система питания, горячая замена жестких дисков в RAID-е, круглосуточная поддержка производителем, вот это все. ИТ-руководители не решаются выйти из колеи стереотипного мышления “Сервер – это надежно”, продолжая эту мысль словами “А десктоп – это нет”. Вспомните, когда в последний раз у вас что-то физически выходило из строя десктопного? А у ваших знакомых? У меня – не было такого случая. Ни одного.

Конечно, есть особые моменты, когда сервер ну просто необходим – критично нагруженная система, не допускающая и 10 минут простоя, но как часто такое встречается в 1С? Я думаю, почти всегда есть 30-60 минут на замену железа.

Возьмем пример выхода из строя десктопного сервера 1С + SQL. Если выходит матплата/процессор/блокпитания/память – из компьютера извлекается SSD+HDD бэкапов и вставляется в другой компьютер. В принципе – все. У любого сисадмина есть компьютер под рукой, пусть менее мощный, но на время он пойдет, пока идет разбирательство с умершей запчастью.

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

В крайнем случае, если победить стереотипы не удается – приложение «Сервера SQL» можно развернуть на полноценном «высоконадежном» серверном железе, а приложения сервера 1С – на десктопном (приложение «Сервер 1С» поднимается на любой станции в сети за 10 минут и не содержит критичных данных) – это наверняка будет гораздо более высокопроизводительней, чем приложения «Сервера 1С» и «Сервера SQL» на серверном железе.

Серверные машины быстрее — у них ядер больше…

Но они — медленнее. Нет, серьезно, вот есть прекрасная таблица производительности в однопоточном тесте. В топе 30 — десктопы от Интела, и, где-то на 30 месте — первая встреча с XEON-ом.

Да, в воистину многопоточных тестах (16 и более потоков) — Xeon-ы вырываются вперед  но только за счет процессоров в 22 ядра, ценою в 150 тыс рублей. При этом, частота одного ядра составляет жалкие 2,2 Ггц, а ты их еще загрузи, эти ядра…

В тесте нет новой линейки Intel Xeon Bronze/Silver/Gold 2017 года, но учитывая их базовую частоту в 2.2 Ггц с бустом в 3 ГГЦ, они вряд ли доползут до того же I7-7700k в одном потоке. Если уж и брать многоядерный процессор – то я бы посоветовал присмотреться к I9-7920x с его 4.2 Ггц в бусте и 12 ядрами, либо, чем черт не шутит, на похожего AMD Threadripper 1920X.

А ты их еще загрузи (или почему важна скорость одного ядра)

Когда пользователь кликает на кнопочку в этой вашей 1С — в 99% случаев исполнение его кода отправляется на «Сервер 1С». «Сервер 1С» открывает поток, который выполняет код на сервере.

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

Код отрабатывается сначала на клиенте, потом на «Сервере 1С», потом на «Сервере SQL». В каждый конкретный момент времени работает только одно ядро процессора машины (сервера или клиентской) на пользователя, не более того. Как только ядро освободилось – оно может обработать задачу другого пользователя, пока первый корпит над результатом.

Пользователей, Ждущих Отклика Системы 1С (работающих в текущий момент) не так много, как активно работающих (ждущих результат + реагирующих на результат). В самом печальном случае, этот одиночный пользователь может наложить блокировку СУБД 1C на таблицы, которые нужны другим пользователям 1С. При этом, остальные пользователи будут простаивать (не расходуя ресурсы процессора), пока этот единственный пользователь отработает свое обращение и чем быстрее он его отработает (чем быстрее ядро процессора) – тем быстрее продолжат работу другие пользователи. Такого в современных Типовых Конфигурациях 1С быть не должно, но такое – может быть. А ведь есть и нетиповые, кастомизированные.. ☺ .

О вкусной и здоровой пище

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

Однако, это повышение выполняется не мгновенно, а с временным лагом, в чем корень многих бед и разочарований. Windows, следуя этой гринписовской тенденции, по умолчанию, выставляет план питания “Оптимальный”, который разрешает уход процессора в диетический режим. Что из этого получается – можно посмотреть на картинках:

Кто не ест – тот не работает (состояние в самом начале):

Разводим пары (состояние через 2-4 секунды):

Жмем на полную (состояние в самом конце теста):

В целом, выход на максимальную мощь происходит за 2-4 секунды, что печально для работы в 1С.

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

В целом – питайте ваш процессор по заветам И.В., благо мощность в пике не поднимается выше 60 ватт (а это энергопотребление слабой лампочки накаливания и экономить на этом не стоит) и, ваша производительность будет гораздо лучше.

Современные высокие технологии 1С (или как полюбить управляемые формы)

Во всех современных «этих ваших 1С» используется управляемый режим конфигурации и Тонкие формы. Которые работают медленнее обычных форм и особо не понятно почему, однако мы сейчас проясним этот момент. Когда открывается управляемая форма – приложение «Сервер 1С» преобразует (сериализует) “сырые” данные в xdto пакеты, которые в виде xml текста отправляются на «Клиента 1С». «Клиент 1С» выполняет обратный процесс (десериализацию) и наполняет управляемую форму важными и нужными данными. С первого взгляда – это не долгий процесс, однако он происходит достаточно часто – например, когда пользователь выполняет прокрутку табличных частей, табличных документов, так как данные на «Клиента 1С» передаются динамически. И вот тут-то раскрывается вышеописанная проблема заснувших ядер процессора – если в момент прокрутки списка – на сервере нет «горячего» ядра (а его точно нет, засыпание выполняется мгновенно, а с предыдущего обращения уже прошла вечность с точки зрения процессора) – ядро начнет медленно просыпаться. И оно будет медленно просыпаться каждый момент прокрутки. Именно поэтому – всегда проверяйте план питания и ваши управляемые формы будут гладкими и шелковистыми. Отдельно отмечу, что и ядро клиента выполняет десериализацию и сериализацию при обмене с сервером и клиентскую машину тоже бы было бы хорошо оснастить быстрым малоядерным процессором и настроить ему план питания.

Don’t follow the white rabbit, Neo.  Об опасностях виртуальных машин и мышлении Сисадмина. Главного.

В последние годы набрало течение виртуальщиков – когда вся инфраструктура предприятия размещается в контексте виртуальных машин, которые работают на нескольких мощных (а иногда – нифига не мощных) физических хостах. Я считаю, что это – печально, и вот почему. Когда у нас появляется виртуальная машина – у нас появляется еще один потенциальный узел проблем. Мы разделяем одну среду выполнения на 2 и более. И нам становится менее понятно, что в это время делает физический хост.

Да, можно записывать лог загрузки ресурсов в длинный файл и смотреть просадки, но будете ли вы это делать?

Кроме того,  всегда может найтись админ, который зайдет на физический хост, и, заметив малую загрузку «в моменте» – развернет на нем 2 виртуальную машину с динамическим распределением ресурсов, что негативно скажется на производительности.

Еще более недальновидным будет размещением «Сервера 1С» и «Сервера SQL» на разных виртуальных машинах в рамках одного хоста. Мало того, что теряется более эффективное подключение через shared memory/ loopback IP, так и еще происходит постоянное переключение ресурсов с одной виртуальной машины на другую. Также можно отметить тот факт, что на поддержание инфраструктуры виртуальных машин тоже расходуются ресурсы процессора – по некоторым оценкам от 5%-10%, что нельзя игнорировать.

В любом случае, если мы не можем прийти к компромиссу с сисадминами – настаиваем хотя бы на том, что «Сервер 1С» и «Сервер SQL» должны быть размещены на одной виртуальной машине, на физическом хосте которой больше ничего не работает. Либо выносим «Сервер SQL» на виртуальную машину, а «Сервер 1С» на физическую (хост), аргументируя тем, что все данные хранятся на «Сервере SQL» и в плане безопасности и администрирования — все хорошо, отстаньте от меня, молодой человек.

HD видео в 1080p с немецких сайтов не гарантирует такого же удовольствия в 1С

Сеть. Обычная такая сеть предприятия может доставить много загадочных часов размышлений, обид на разработчиков и этот мир в целом. Ваша сеть может отлично прокачивать файлы в гигабайты, транслировать видео и печатать tiff постеры в полиграфическом качестве на сетевой принтер, но она может не очень хорошо работать с 1С.

Основное требование к сети – латентность (скорость отклика). Обмен Сервер-Клиент передает достаточно мало данных: открытие формы документа «Реализация» в типовой УТ не займет больше 200 Кбайт. Однако, передачу данных необходимо провести быстро, без ожиданий, при любой нагрузки сети, без потерь пакетов, иначе пользователь будет ждать, сервер будет ждать, оборудование будет ждать, а причина будет непонятна.

Также, ваш «Сервер 1С» может находится в другом здании — за сотню метров, связанный 100Мб сеткой без репитера, и вы об этом узнаете только тогда, когда на Тонких клиентов полезут сообщения вида “Ошибка post запроса /e1cib/logForm”

Либо в техжурнал 1С (он же у вас настроен, ведь да?) повалятся ошибки сети.

Причем ошибки могут проявляться также в моменты, когда сеть загружена даже не трафиком 1С, что еще более затрудняет поиск причины. Рекомендуем замерять передачу пакетов под нагрузкой, хотя бы простой утилитой ping, либо более сложными и функциональными пакетами. Мне хватает команды:

Ping server1C –t –l 60000 -4

Между «Сервером 1С» и «Сервером SQL» должна быть идеальная сеть.

Не забывайте о «Сервере SQL»

Не забывайте настраивать сервер и регламенты SQL.

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

Жесткий диск имеет значение

Жесткий диск не так важен, как процессор, но, все равно важен. В принципе, все современные жестки диски обеспечивают достаточную линейную скорость чтения/записи, но у HDD возникают проблемы с произвольной скоростью. По большому счету, «Сервер SQL» при наличии оперативной памяти все со временем кэширует и с ним проблем обычно не возникает, во всяком случае, я с таким не сталкивался. Однако, у нас остается «Сервер 1С», который активно работает с дисковой системой. Это и

• размещение прикладных объектов (таблиц значений, двоичных данных, табличных документов) во временных файлах,
• обмен с периферийными базами через xml,
• формирование индекса полнотекствого поиска,
• запись и чтение журнала регистрации,
• хранение сеансовых данных,
• обмен с другими системами через обработки, выполняемые в 1С (а сейчас любая оптовая компания работающая с федеральными сетями обменивается как минимум по EDI, чего говорить об обменах с WMS, системами мобильной торговли, сайтами/порталами и т.п.)

Весь этот зоопарк обменивается с дисковой системой гораздо большими объемами данных, чем SQL, особо ничего не кэшируя в память (т.к. данные постоянно меняются). Поэтому «Серверу 1С» требуется быстрый диск – и этот быстрый диск – SSD. Инерция мышления говорит нам, что SSD диски – это капризно, ненадежно и несерьезно, однако лет 5 это уже не так. Достаточно посмотреть результаты нагрузочных тестов и сомнений становится меньше:

https://3dnews.ru/938764/page-2.html#Samsung%20960%20EVO

https://3dnews.ru/938764/page-2.html#Samsung%20850%20PRO

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

Вообще, оценить производительность дисковой системы можно с помощью прекрасной программы CrystalDiskMark 5

Самым важным показателем является чтение и запись произвольных 4 Кбайтных блоков, например:

HDD человека, застрявшего в прошлом: HDD WDC WD 10 EZEX Blue 7200 RPM

SSD здорового человека: SSD Samsung 850 Evo

Результат, как говорится, налицо. Конечно, есть быстрые 15000 RPM SAS диски (у меня их под рукой нет), присылайте результаты их тестов, посмотрим.

Мы идем вместе!

Должны ли приложения «Сервер 1С» и «Сервер SQL» стоять на одной машине? С первого взгляда – как бы и нет, не должны. Разные компьютеры – больше ресурсов. Однако, как говорят дочери офицеров — не все так однозначно.

Когда выполняется код на «Сервере 1С» и этот код делает запрос к SQL – поток «Сервера 1С» начинает ожидать результата запроса и освобождает ядро процессора, которое может обработать как поток другого пользователя 1С, так и сам запрос SQL.

Также, при размещении «Сервера SQL» и «Сервера 1С» на одной машине – связь между ними будет осуществляться через shared memory в лучшем случае и loopbackIP в худшем, что, однозначно лучше TCP соединения между 2-мя физическими машинами. При наличии большого числа одновременно работающих пользователей – лучше взять процессор с большим количеством ядер (но не в ущерб быстродействию ядра), чем разносить «Сервер 1С» и «Сервер SQL». Если же, по каким-то причинам пришлось их разнести – для «Сервера 1С» следует выбрать компьютер с более мощным процессором, так как он потребляет процессорных ресурсов в несколько раз больше:

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

Пользователи с их Тонкими клиентами должны работать на своих личных персональных машинах. Если вы не можете переломить желание сисадмина загнать всех в терминальное рабство – всеми путями добивайтесь, чтобы терминалка была развернута на иной (чем «Сервер 1С») физической машине. Даже если это будет виртуалка. Даже если сисадмин гарантирует вашему «Серверу 1С» высший приоритет и выделенные ресурсы. «Серверу 1С» ничего не должно мешать.

Следите за 1С

Просто настройте техжурнал на сбор ошибок, как это советует 1С.

Просматривая его, вы узнаете много нового, например, проблемы с сетью, доступом, сервером SQL, ошибками в коде, и.т.д. Кроме того, вы будете видеть, когда перезапускался серверный процесс rphost.exe, а в тяжелых случаях и процесс менеджера rmmgr.exe. Пример файла настройки есть на сайте 1С.

Так много вкусного. Что же выбрать?

I. На текущий момент, для средненагруженной системы на базе УТ11.X (до 1-2 тысяч документов отгрузки в день, 50-80 пользователями, 15-20 активными и 8 одновременно работающими) я бы предложил такую конфигурацию (для «Сервера 1С» и «Сервера SQL» на одной машине):

Идеальная сейчас:

 

 

 

Более бюджетная сейчас:

Тоже самое через несколько месяцев (рекомендую дождаться):

Идеальная будущая (через полгода, прогноз):

Бюджетная будущая (через полгода, прогноз):

Если планируете разнесение сервера – то можно в качестве «Сервера 1С» выбрать мощную машину, в качестве «Сервера SQL» – менее мощную (значит – более дешевую), а память ограничить 32 Гб на машину, SSD – 256 Гб.

II. Если пользователей ожидается гораздо больше, то могу посоветовать присмотреться (только присмотреться, сам опыта не имел) к процессору I9-7920x, либо AMD Threadripper 1920X – 12 ядер и 24 потока на частоте 4.2 Ггц должно хватить каждому.

Для клиентских машин я бы остановился на следующих конфигурациях:

Сейчас:

Будущая (через полгода, прогноз):

Все сборки подобраны в онлайн-конфигураторе одного Московского компьютерного магазина с адекватным ценником. Цена сборок включает в себя цену ОС “Microsoft Windows 8.1 64-bit Russian” ценой в 7000 рублей. Серверные сборки не содержат в себе периферию (монитор, клавиатура, мышь). Клиентские сборки содержат в себе периферию.

И, в завершении, если душит жабка и есть желание арендовать оборудование за 1000 рублей в месяц, или купить б/у серверs — расскажите владельцу бизнеса, что, когда 1С тормозит – пользователи от скуки адской лезут читать вконтактик или новости. Не будет тормозов – не будет мотивации и оправданий не работать. Да и само время сотрудников стоит все дороже, и уж точно дороже оборудования.

В заключение

Возможно, а если честно – надеюсь, я затронул тонкие струны души многих адептов серверных решений, простите меня. Такова моя точка зрения, возможно, она откроет глаза на происходящее и немного отодвинет шоры стереотипов, по которым сервер должен быть на серверном железе. Это было актуально лет 10 назад, но в последние годы десктопное железо доползло до серверного и, похоже, переползло (если мы говорим о сравнимых по цене решениях).

Всем хорошего дня и послушной 1С, ваши, Ежов Дмитрий Сергеевич при информационной и организационной поддержке  ООО «Алкосфера».