Комментарии 8
Объем работы большой, это заслуживает уважения. Но просто пара замечаний по обеим статьям сразу, поскольку ну прям видно что проблему решал специалист по 1С:
Много мокрой и влажной воды и не нужных заумных ссылок.
Нет чистых исходных данных, тобишь что было в железе и что дали. Любой последующий анализ без этой информации просто не имеет смысла.
Из версий ПО увидел упоминание давно снятой с поддержки vSphere 5.5, что вызывает много неудобных вопросов ко всей статье, вы там на hpe gen 6 все это творите что ли?
Бесконечно много вопросов к DBA, администраторам виртуализации и администратором ОС.
Полезность выхлопа статьи равна нулю, но канал порекламирован.
Нет чистых исходных данных, тобишь что было в железе и что дали. Любой последующий анализ без этой информации просто не имеет смысл
Ссылки на версии ОС, SQL , VMWare и железо серверов могу приложить. В статье упор сделан не на добавление в faq "101 ошибка неверной настройки vmware под 1С +MS SQL ", а на демонстрацию методики выявления проблем со стороны специалиста по 1С + СУБД (последнее важно, поскольку 1С не имеет достаточных средств диагностики кроме техжурнала, и по сути генератор запросов). Мне до сих пор помогает пройденная 15 лет назад сертификация Oracle DBA.
Из версий ПО увидел упоминание давно снятой с поддержки vSphere 5.5, что вызывает много
Там всего лишь нагугленный пример опций Power savings в VMWare
Бесконечно много вопросов к DBA, администраторам виртуализации и администратором ОС
По поводу DBA - я DBA задавайте. К администраторам виртуализации у меня тоже бесконечно много вопросов. Казалось бы я могу им показать что на железном сервере быстро, на VMWare медленно при одинаковых версиях 1С + MSQL + ОС. Но ждать от них выявления причин, как показывает практика, можно бесконечно долго. Результат можно получить если обрисовать область куда смотреть + иметь возможность сильно нагрузить кластер. Правильное взаимодействие с администраторами тянет на отдельную статью, поскольку они не знают деталей работы приложения, а я не знаю VMWare
101 способ ошибок и лучшие практики при настроке vmware для 1С хорошо изложен у Гилева в конце ссылки (внимание там реклама) Производительность «1С» в виртуальной машине | Gilev.ru | Ускоряем 1С:Предприятие
Однажды перезжали из виртуалки AWS на виртуалку на dedicated server у обычного хостера. Заметили, что некоторые unit-тесты стали выполняться до двух раз дольше по времени. В качестве гипервизора был Proxmox KVM. Начали копать, включили numa, unsafe writeback дисков, mitigations=off. Часть тестов ускорилось, но в целом все в пределах погрешностей. Пока от безысходности не залезли в BIOS сервера и не переключили Performance Per Watt (DAPC) to Performance. Сразу суммарное время тестов стало плюс-минус пару секунд как в AWS
Дополнительные ссылки
Напр. проекция шара может выглядеть как круг или овал
— устанавливайте профиль электропитания на «Производительный». Это вообще первое, что нужно делать на сервере, а уж для сервера 1С — это вообще «маст хэв #1»;
— выравнивайте ВМ по аппаратной архитектуре.
И будет вам счастье… )
За статьи спасибо, как админу 1С было интересно почитать. Хотя первоначальная интрига и обернулась такими простыми вещами, но всё равно полезно: видно многие ещё не знают этого, или банально забывают.
Эти постулаты работают если среда неизменна.
Напр Выравнивание vm по аппаратной архитектуре оно помогает если виртуальная машина сделана неперемещаемой. А как правило делают перемещаемой , VMWare может ее переместить по своим соображениям кудато еще. Администраторы могут переместить машину куда хотят, они ведь смотрят на ландшафт в целом и ваше счастье у них будет на последнем месте. В ЦОД редко бывает ситуация когда все сервера с одинаковым количеством ядер, и любое перемещение исказит первоначальную картину
Потом нужно помнить, что VM ware архитектурно создает узкие места :
напр "количество потоков данных от виртуального сервера к дисковой системе (регулируется в определенных пределах)"
Сетевые интерфейсы которые тоже под контролем Virtual Networking Made Easy with VMware VMXNET3 Driver | VMware , я в первой статье упоминал о задержках в сети которая была обнаружена 1С + MS SQL против Матрицы виртуализации / Хабр (habr.com) , у Гилева есть рекомендации на эту тему.
Я не вижу в среде виртуализации возможности зафиксировать гарантированную производительность среды. Когда у Вас свой железный кластер со своей дисковой подсистемой, вы можете быть уверены что кроме вирусов его больше никто не использует. Похожий опыт см у Гилева Про виртуализацию и 1С | Gilev.ru | Ускоряем 1С:Предприятие
Можно сколько угодно собирать картинки с Гретой и красивые графики — но физику не обманешь. Облака дают дёшево* некий средний уровень. А в рамках этого среднего параметры могут «гулять» очень широко. И если ваша нагрузка терпима к этим флуктуациям — то у вас всё Ок. Но 1С не из этой категории, это просто нужно держать в голове.
Если у вас своё «частное облако» — в чём проблема доработать регламент для отдела системного администрирования, где будут прописаны эти требования к данной конкретной VM? Типа: «в обычной ситуации не перемещать на другие хосты, при перемещении (авария, обслуживание хоста) — предусмотреть выравнивание ВМ по NUMA нового хоста». Это уже административные процедуры в рамках поддержки ИС 1С.
У вас сотни и тысячи юзеров в 1С, и требования к онлайну высокие? Разверните кластер ВМ 1С, желательно на разных кластерах гипервизора. Но за это и заплатить нужно будет — оборудование, услуги нормального администратора 1С (не бывшего разработчика)… А 10-50-100 юзеров и потерпят перезагрузку сервера, не проблема — клиенты почти всегда сильно переоценивают важность своих бизнес-процессов в плане непрерывности )))
Остальное — это уже косяки админов, которые не утруждают себя настройкой гипервизор, оставляя всё «по дефолту». Особенно «порадовало» использование дефолтных параметров электропитания, это вот прям классика… Лечится легко волшебным пенделем от руководства компании, если оно заинтересовано в работе их 1С конечно же.
* Про «дешевизну» облаков оффтоп: некоторое время анализировал для одного клиента стоимость аренды мощностей в облаке VS свой сервер. Результат предсказуемый: для зарубежных провайдеров свой сервер становится выгодней через примерно 3 года, для российских — 1-2 года: жадные они )))
Плюс все «прелести» облаков разъяснил. Через неделю купили себе новый сервер, работают спокойно с тех пор.
"некоторое время анализировал для одного клиента стоимость аренды мощностей в облаке VS свой сервер. " Если будет возможность напишите об этом статью. Я такой анализ не проводил (не было необходимости) , но интуитивно понимаю что в диапазоне 5 лет разница будет незначительна с учетом инфляции, амортизации
1C MSSQL Против Матрицы виртуализации – Перезагрузка