Оптимизация виртуальных машин под 1C на базе ESXi 6.x

[STALKER_SLX]

Доброго времени суток, уважаемые форумчане!
Есть сервер «HP ProLiant ML350p Gen8 SFF» со следующими компонентами:
2х Xeon E5-2643
64 Гб RAM
«HP Smart Array P420i/1G FBWC / +»
4х 900Гб SAS 10k – RAID10
2x SSD 400Гб – RAID1


На указанном сервере будет развернут «ESXi 6.x» с двумя виртуальными машинами «Windows Server 2016» (или 2019): одна ВМ с сервером терминалов, а вторая – для установки и работы 1C-сервера, к которому будут подключаться пользователи с первой ВМ-ки. Обе ВМ-ки будут крутиться на 2x SSD 400Гб в RAID1, а RAID10 – будет бекап баз данных 1C. На текущий момент размер «рабочей» базы 1C составляет около 130Гб.
Планируемая средняя нагрузка – 50-60 пользователей одновременно (может быть и больше).

Учитывая всё выше изложенное, прошу Вас помочь разобраться в вопросе разделения ресурсов всей ноды и оптимизации/тюнинга ВМ-ок для их максимально эффективной/быстрой работы при указанной конфигурации. То есть какие службы или компоненты ОС нужно отключить для максимально производительности. Или может нужно что-то добавить или установить, например, какое-нибудь стороннее ПО?!

[ival]

Мое мнение следующее:

Процессор 2643 хороший камень, но вы кастрируете его именно 64 гб памяти. Это мало, по сути вы на проц выделяете всего 32 гига. Я бы добивал его памятью хотябы по 64 на камень.

Не вижу смысл запускать сервер терминалов на ssd.

Не вижу смысл соединять 1с сервер с sql. Лучше разделить. Обмен будет между машинами через виртуальный коммутатор, поэтому будет приближён к shared memory. Я же правильно понимаю что у вас база на mssql? Ставит сервер 1с (без sql) тоже не вижу смысла на ssd, прироста не будет, а просто потеряете быстрые диски.

А база 130 это чистая база или с логами транзакций?
В Настройки виртуалок не лезте, они из коробки оптимально настроены.

[Уваров А.С.]

Не вижу смысл запускать сервер терминалов на ssd.

Если конфигурация на управляемых формах, то я вообще не вижу смысла в сервере терминалов, тонкий клиент отлично работает по сети.

Не вижу смысл соединять 1с сервер с sql. Лучше разделить. Обмен будет между машинами через виртуальный коммутатор, поэтому будет приближён к shared memory.

В данном случае да, лучше разнести.

Ставит сервер 1с (без sql) тоже не вижу смысла на ssd, прироста не будет

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

[ival]

По кэшу 1с не могу комментировать, т.к. я слышал только про 1 тест для производительности сервера 1с от некого гилева. Если честно не вникал в методику тестирования, но думаю там львиная доля теста направлена на ожидания sql. Собственно по этому я какбы не могу объективно оценить скорость самого сервера 1с. Но из малого опыта могу сказать что был опыт размещения 1с на sas 10к и на sas 15k. Видимой разницы небыло, пользователи вообще не заметили, поэтому оставил на 10к. Если честно больший эффект дал еженочный рестарт службы сервера. Но утверждать не могу, т.к. особо не углублялся именно в производительность 1с независимо от sql

[Уваров А.С.]

Производительность 1С сильно упирается в частоту процессора, чем больше - тем лучше и желательно от 3 ГГц и выше. Также должно быть отключено энергосбережение и все С-состояния процессора в BIOS, в т.ч. и на гипервизоре. Также следует выключить управление частотой CPU, процессор для 1С всегда должен работать на 100% частоты, можно оставить только TurboBust.

т.к. я слышал только про 1 тест для производительности сервера 1с от некого гилева

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

[ival]

Производительность 1С сильно упирается в частоту процессора, чем больше - тем лучше и желательно от 3 ГГц и выше.

Это рекомендации и выполнение этих рекомендаций врятли принесет "летающей 1с". По большей степени это написано везде, но я не уверен что это так. Сразу скажу к связке 1с+MS SQL я отношусь скорее всего к сочувствующим и держусь по дальше от них, но вот в администрировании MS SQL у меня есть кое-какой опыт (маленький в рамках матерых DBA, но достаточный чтобы увидеть проблему). И в силу этого могу сказать, что тормозящий сервер 1С (хотя даже на шикарном железе он будет спотыкаться) чаще всего это либо нехватка ресурсов SQL (при чем как выяснил за свой опыт работы, люди даже не знают как смотреть базовые счетчики SQL и за что они отвечаю, что весьма печально, про ожидания я уж и не говорю) либо бездумный запрос, а как следствие умопомрачительные план выполнения запроса и цифры с бешеными ожиданиями в профайлере. Большинство кто пишут обработки 1С даже не задумываются оптимальный ли это алгоритм или нет и что будет с базой. Просто 1С это не ИТ, это монополистический бизнес который приносит деньги, достаточно изучить язык и можно зарабатывать. При этом из этих разработчиков малая часть знает что такое БД. Опять же например, я нигде не видел чтобы разделяли файл базы 1С, хотя это хорошая практика разрезать базу на разные файлы и раскладывать её по дискам разной скорости в зависимости от таблиц. Или доходило вообще до смешного, например я видел базу под 1С с увеличением файла на 1 МБ. Собственно из всего этого и складываются "1С тормозит", а нам просто предлагают купить железку по-мощнее вместо того, чтоб научить разработчиков быть нормальными разработчиками, написать книги по архитектуре сервиса и его взаимодействии с SQL и заставить выучить ее своим франчайзи, дать людям понять что человек обслуживающий базу должен не только РК уметь делать. А в 1С все через одно место, собственно какой подход такая и программа.

Это мое личное видение, повторюсь у меня нет опыта большого с 1С, но есть понимание SQL.

У нас:
сервер 1С это ВМ на E5-2640 (4 ВП) 20 гБ диски sas 10к (человек 40)
сервер баз это ВМ 2 ноды FO cluster на E5-2640 (8 ВП) 96 гБ на sas 15к+sas ssd (mdf общее гигов на 200, 1с из них наверное 40 ГБ не больше, нагрузка на сервер человек 200 1с и BI)
Жалоб нет, хотя MemoryGrandPending до 2 подскакивает

[Уваров А.С.]

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

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

Также масса случаев, когда сервер 1С безбожно тормозил на каком-нибудь многоядерном, но низкочастотном Xeon и получалось, что новый сервер, объективно вроде-бы более производительный, работает с 1С хуже чем старый.

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

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

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

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

Code Select Expand

"ВЫБРАТЬ
| ТоварыНаСкладахОстатки.КоличествоОстаток КАК КоличествоОстаток,
| ТоварыНаСкладахОстатки.РезервОстаток КАК РезервОстаток
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
|ГДЕ
| ТоварыНаСкладахОстатки.Склад = &Склад
| И ТоварыНаСкладахОстатки.Номенклатура = &Номенклатура
| И ТоварыНаСкладахОстатки.Характеристика = &Характеристика";
Вы можете сказать какой план запроса будет в СУБД? Я - нет. Поэтому говорить о том, что программисты 1С пишут неоптимальный код, я бы не стал. Неоптимально работает платформа, средств повлиять на выполнение запроса у программиста 1С нет, если только он пишет не изначально кривой запрос по меркам 1С.

Просто 1С это не ИТ, это монополистический бизнес который приносит деньги, достаточно изучить язык и можно зарабатывать. При этом из этих разработчиков малая часть знает что такое БД.

Почему же, вполне себе IT, потому как 1С не стала бы монополистом, если бы не позволяла быстро, недорого и эффективно подстраивать программу под свои бизнес-процессы. При этом разработчики 1С работают на более высоком уровне, чем тот же программист на C++ или даже PHP.

По сути 1С представляет прикладное программирование с уже готовыми объектами метаданных (классами в "общепринятых" терминах) на уровне максимально приближенном к учету. Если мне надо хранить данные - я создаю Справочник, мне не надо задумываться как он реализован на нижнем уровне, это готовый объект метаданных (класс) с уже готовыми стандартными процедурами и функциями (методами).

Поэтому я просто могу написать:

Code Select Expand

ЭлементНоменклатуры = Справочники.Номенклатура.СоздатьЭлемент();
ЭлементНоменклатуры.Наименование = "Моя номенклатура";
ЭлементНоменклатуры.ЕдиницаХраненияОстатков = Справочники.ЕдиницыИзмерения.НайтиПоНаименованию("шт");
ЭлементНоменклатуры.Записать();
Это удобно и значительно ускоряет разработку, так как программист оперирует элементами верхнего уровня: Справочниками, Документами и т.д. А также использует привычные для учета действия. Вместо записи данных в БД он записывает набор движений (проводку) в регистр.

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

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

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

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

Этого никто не делает, потому что работа 1С с СУБД - это черный ящик и лезть туда запрещено. Хотя никто не запрещает разобраться что где лежит самому и разделить базы вручную. Но не дай Бог в следующем обновлении 1С что-то поменяет в данных или алгоритме работы с базой и все это навернется - отвечать будет тот, кто это сделал. А любой сторонний специалист и франч с радостью подтвердит, что вы нарушили правила работы с платформой и вас надо вы@#$ть и высушить...

Или доходило вообще до смешного, например я видел базу под 1С с увеличением файла на 1 МБ.

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

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

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

[ival]

И того что вы написали ещё страшнее)) Создан франкенштейн и никто не знает как он устроен. Разработчик всегда должен знать что сделает его запрос в базе, до или после выполнения - он должен знать, если он не знает как ведёт себя база, то это уже утопия. Самое печальное, что говоря 1С все подразумевают бух, кадры, и ещё какие-нибудь маленькие конфигурации, но давайте не будем забывать что есть ещё что есть более объемные продукты как УПП, документооборот или erp. Это монструюзные решения, которые сначала не могут внедрить, потом кое-как допиливают всем селом, а потом боятся обновить, потому что половина отваливается. И все это работает медленно, неповоротливо и все терпят - мыши плакали кололись... Вот примерно то, что Вы написали я и слышал всегда: «Зачем мне знать, я пишу русские слова и это работает». Но это не система, это хаос. У нас разработчики борятся с тем что написали год назад, потому что надо обновится, а нельзя так как сломается. А пишут как? Да как сказал начальник планого отдела: «мужики надо чтоб вот так и так, а тут вот так. Можете?» «Можем. Служебку напиши и все напишем» Потом это пишется, потом это работает, люди начинают работать на этом, бизнес процесс уже или часть БП. И таких самоделок куча, ни документации ничего, половина уже кто писал уволилось. А потом в один прекрасный день изменяется законодательство, вводится дополнительная финтиплюшка. Находится производитель из-за бугра который готов поставить дорогостоящее оборудование для выполнения этой финтиплюшки и даже говорит что у них есть интеграция с 1с, но с 8.3.17 и выше. Ну все знают что у нас то 8.3.15, но и знают что у нас человек 15 разработкой 1с занимаются и обновится должно быть не проблема. Но на совещании эти 15 человек с глазами какающих котов говорят что это невозможно, т.к. половина перестанет работать. И дальше ближайшие пол года они борются с этим монстром которого они собирали предыдущие пол года чтобы обновиться. Это называется бизнес процессы?? По-моему это глупость. Знаете что ещё я заметил, вот если у них костяк основной меняется, приходят другие на их места, говорят что до них писали бездари и самоучки, а они сейчас сделают все по науке и заживем и даже оптимизируем штат разработчиков. И не меняется ничего, они собирают тоже самое что и старые. Про громкие названия всеми известных фирм франчайзи я даже рассказывать не буду, с ними все ещё хуже. И часто вот эти самые люди говорят: да у нас sql тормозит, да у нас процессоры плохие, да у нас памяти мало, да у нас хранилища медленные и сеть не 48gb и «админы» не понимают. А проблема то в единственном, хаос и бабки которые в этом хаосе зарабатываются. И чем кривее эта поделка работает, тем больше людей смогут кормиться вокруг этого ведра. Ни кого не хочу обидеть, но слово разработка и 1с стоять вместе не могут, так же как и производительность и быстродействие. Наверное ушёл уже от темы, извиняюсь

[Уваров А.С.]

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

Низкий порог входа и низкая стоимость доработки и обеспечило 1С популярность, поверьте, там не все так плохо. Реально я не вижу им реального конкурента не смотря на все их недостатки. Даже на крупных внедрениях. Потому что все можно относительно недорого дописать.

А как это работает внутри, это не к разработчикам 1С, это к разработчикам платформы, это они должны реализовать корректную работу с СУБД, так, чтобы даже неоптимальные запросы разработчика прикладного решения превращались в максимально оптимизированные запросы СУБД.

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

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

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

Да, у 1С как платформы есть проблемы производительности, неоптимальная работа с СУБД, спорные маркетинговые решения, которые еще более ухудшают ситуацию, но сколь-нибудь вменяемого аналога ей нет. Который бы позволял быстро и недорого разрабатывать прикладные решения.

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

У нас разработчики борятся с тем что написали год назад, потому что надо обновится, а нельзя так как сломается. А пишут как? Да как сказал начальник планого отдела: «мужики надо чтоб вот так и так, а тут вот так. Можете?» «Можем. Служебку напиши и все напишем» Потом это пишется, потом это работает, люди начинают работать на этом, бизнес процесс уже или часть БП. И таких самоделок куча, ни документации ничего, половина уже кто писал уволилось.

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

Дополнительный хаос вносят франчи, там существует пагубная модель почасовой оплаты за разработку. А уж сколько фрагментов кода с зашитыми прямо в нем переменными (номенклатурой, контрагентами, пользователями и т.д.) я видел. С точки зрения кода - это работает. С точки зрения правил программирования - это зашквар. Но в этом скрыт свой тайный смысл - заказчик что-то поменял в своих данных и нужно снова дорабатывать обработку, т.е. платить франчу.

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

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

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

Не так давно внедряли мы общепитовскую конфигурацию Трактир, точнее переводили клиента с версии 7.7. То, что касается штатного функционала - работает без вопросов. А вот алкоголь работать так как надо не хотел, поддержка закрывала наши обращения с отпиской "не является ошибкой", вопрос "где это написано в инструкции" игнорировала и предлагала купить платную поддержку.

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

[ival]

Вот видите вы и сами пишите, что это деньги, низкий порог вхождения и отсутствие культуры. Я согласен что SAP дорого и не по финансам 99.9% наших компаний. Но 1С идёт в сторону SAP, части уже есть: документооборот, erp осталось bi сделать(не уверен что его нет ещё) и все готово, можно объединять под общим названием SAP и пытаться продавать. Но со стороны работы: производительность, архитектура, парадигма - все останется как и сейчас. Я согласен что и альтернативы нет у нас. Конечно это все полемика, но почему-то с каждым годом как я сталкиваюсь (в рамках сочувствующего) с 1С я все хуже и хуже начинаю относиться к этой системе. И если честно веры что придёт порядок совсем нет.

[Уваров А.С.]

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

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

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

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

Архитектура 1С в принципе тоже неплоха. Тем более что она очень серьезно изменилась за последние годы, став действительно клиент-серверной. Проведена большая унификация в рамках БСП, БПО и т.д. Много чего хорошего сделано.

А вот производительность. Тут все плохо. Причем плохо настолько, что если я запустил какую-то тяжелую обработку, то параллельно в этом сеансе я делать уже не могу ничего, только смотреть на колесико. Иногда вообще очень трудно понять чем занята 1С и почему это занимает столько времени.

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

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

Отраслевые решения - это тоже бесконечно грустная история. Многие из них также далеки от отрасли, как я от полетов на Луну. Хотя есть и неплохие решения.

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