Данная статья написана в авторском стиле и не претендует на истину в последней инстанции. Она посвящается всем, кто хоть как-то взаимодействует с 1С (пользователям, программистам, администраторам, IT-менеджменту и даже владельцам бизнеса). Отдельно хочется выделить матерых системных администраторов, и чуть ниже по тексту вы поймете почему.
Также хотелось бы сказать, что в данной статье мы рассматриваем потребности среднего (с точки зрения нагрузки на информационные системы 1С) бизнеса (до 100 пользователей одной базы данных, до 2000 отгрузочных документов в день). Иными словами, применять мнение автора для крайностей (всего 5 пользователей базы данных или целых 500 пользователей) не следует, т.к. это слишком частные случаи.
Тогда сразу приведу краткий список постулатов. Оговорюсь, что под термином «Сервером 1С» я имею ввиду пару приложений «Сервер 1С» + «Сервер SQL», расположенных как на одной физической машине, так и на разных.
Однако в большинстве своем речь идет о приложении «Сервере 1С», как о более (в сравнении с Сервером SQL) нагруженном элементе. Вот этот список:
Статья, в целом, родилась под влиянием впечатлений о поголовном непонимании современного положения в области оборудовании и политической ситуации в целом, но мы начнем с 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С» преобразует (сериализует) “сырые” данные в xdto пакеты, которые в виде xml текста отправляются на «Клиента 1С». «Клиент 1С» выполняет обратный процесс (десериализацию) и наполняет управляемую форму важными и нужными данными. С первого взгляда – это не долгий процесс, однако он происходит достаточно часто – например, когда пользователь выполняет прокрутку табличных частей, табличных документов, так как данные на «Клиента 1С» передаются динамически. И вот тут-то раскрывается вышеописанная проблема заснувших ядер процессора – если в момент прокрутки списка – на сервере нет «горячего» ядра (а его точно нет, засыпание выполняется мгновенно, а с предыдущего обращения уже прошла вечность с точки зрения процессора) – ядро начнет медленно просыпаться. И оно будет медленно просыпаться каждый момент прокрутки. Именно поэтому – всегда проверяйте план питания и ваши управляемые формы будут гладкими и шелковистыми. Отдельно отмечу, что и ядро клиента выполняет десериализацию и сериализацию при обмене с сервером и клиентскую машину тоже бы было бы хорошо оснастить быстрым малоядерным процессором и настроить ему план питания.
В последние годы набрало течение виртуальщиков – когда вся инфраструктура предприятия размещается в контексте виртуальных машин, которые работают на нескольких мощных (а иногда – нифига не мощных) физических хостах. Я считаю, что это – печально, и вот почему. Когда у нас появляется виртуальная машина – у нас появляется еще один потенциальный узел проблем. Мы разделяем одну среду выполнения на 2 и более. И нам становится менее понятно, что в это время делает физический хост.
Да, можно записывать лог загрузки ресурсов в длинный файл и смотреть просадки, но будете ли вы это делать?
Кроме того, всегда может найтись админ, который зайдет на физический хост, и, заметив малую загрузку «в моменте» – развернет на нем 2 виртуальную машину с динамическим распределением ресурсов, что негативно скажется на производительности.
Еще более недальновидным будет размещением «Сервера 1С» и «Сервера SQL» на разных виртуальных машинах в рамках одного хоста. Мало того, что теряется более эффективное подключение через shared memory/ loopback IP, так и еще происходит постоянное переключение ресурсов с одной виртуальной машины на другую. Также можно отметить тот факт, что на поддержание инфраструктуры виртуальных машин тоже расходуются ресурсы процессора – по некоторым оценкам от 5%-10%, что нельзя игнорировать.
В любом случае, если мы не можем прийти к компромиссу с сисадминами – настаиваем хотя бы на том, что «Сервер 1С» и «Сервер SQL» должны быть размещены на одной виртуальной машине, на физическом хосте которой больше ничего не работает. Либо выносим «Сервер SQL» на виртуальную машину, а «Сервер 1С» на физическую (хост), аргументируя тем, что все данные хранятся на «Сервере SQL» и в плане безопасности и администрирования — все хорошо, отстаньте от меня, молодой человек.
Сеть. Обычная такая сеть предприятия может доставить много загадочных часов размышлений, обид на разработчиков и этот мир в целом. Ваша сеть может отлично прокачивать файлы в гигабайты, транслировать видео и печатать tiff постеры в полиграфическом качестве на сетевой принтер, но она может не очень хорошо работать с 1С.
Основное требование к сети – латентность (скорость отклика). Обмен Сервер-Клиент передает достаточно мало данных: открытие формы документа «Реализация» в типовой УТ не займет больше 200 Кбайт. Однако, передачу данных необходимо провести быстро, без ожиданий, при любой нагрузки сети, без потерь пакетов, иначе пользователь будет ждать, сервер будет ждать, оборудование будет ждать, а причина будет непонятна.
Также, ваш «Сервер 1С» может находится в другом здании — за сотню метров, связанный 100Мб сеткой без репитера, и вы об этом узнаете только тогда, когда на Тонких клиентов полезут сообщения вида “Ошибка post запроса /e1cib/logForm”
Либо в техжурнал 1С (он же у вас настроен, ведь да?) повалятся ошибки сети.
Причем ошибки могут проявляться также в моменты, когда сеть загружена даже не трафиком 1С, что еще более затрудняет поиск причины. Рекомендуем замерять передачу пакетов под нагрузкой, хотя бы простой утилитой ping, либо более сложными и функциональными пакетами. Мне хватает команды:
Ping server1C –t –l 60000 -4
Между «Сервером 1С» и «Сервером SQL» должна быть идеальная сеть.
Не забывайте настраивать сервер и регламенты SQL.
Контролируйте их выполнение – возможно, ранее настроенные, они не выполняются по какой-то причине. Настройте оповещение по почте при ошибке выполнения.
Жесткий диск не так важен, как процессор, но, все равно важен. В принципе, все современные жестки диски обеспечивают достаточную линейную скорость чтения/записи, но у HDD возникают проблемы с произвольной скоростью. По большому счету, «Сервер SQL» при наличии оперативной памяти все со временем кэширует и с ним проблем обычно не возникает, во всяком случае, я с таким не сталкивался. Однако, у нас остается «Сервер 1С», который активно работает с дисковой системой. Это и
Весь этот зоопарк обменивается с дисковой системой гораздо большими объемами данных, чем 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С.
Просматривая его, вы узнаете много нового, например, проблемы с сетью, доступом, сервером 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С, ваши, Ежов Дмитрий Сергеевич при информационной и организационной поддержке ООО «Алкосфера».
Мы разделили вопросы на категории, чтобы вам было проще найти ответ.
просьба объяснить такое поведение системы: приёмка\сверка марки сканируются без привязки упаковки
При работе в программе возникает ошибка удержания временных таблиц после серверного вызова.
Оставьте свой номер телефона,
и мы бесплатно ответим на ваши вопросы.
Оставьте свой номер телефона, и мы бесплатно проконсультируем вас по возникшим вопросам.
Оставьте ваши контактные данные, и мы свяжемся с вами, чтобы уточнить детали вашего проекта.