Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

11.07.22

База данных - HighLoad оптимизация

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

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

 

Инфраструктура

 

Платформа 1С:Предприятие 8, версия 8.3.17.1549

1С:ERP Управление предприятием 2, версия 2.5.5.77

Сервер СУБД: MS SQL Server

Виртуализация средствами VMware

Количество баз ERP: 20+

Все 20 ИБ работают в режиме «20 кластеров на одной ВМ»:

  • один сервер приложений 1C
  • один сервер СУБД
  • один сервер лицензирования

 

Проблема, с которой пришел заказчик

 

В одном крупном отечественном публичном акционерном обществе, в более 20 дочерних организаций (далее ДО) учет ведется в 1С:ERP Управление предприятием 2 (далее ERP) – по базе на ДО. В одной из баз ДО (наиболее крупной) процедуры быстрого закрытия месяца выполнялись неприемлемо долго.

 

Открыть оригинальный размер

 

 

Детализация проблемы – понимаем масштаб бедствия

 

Что показало обследование текущего положения дел:

1. Сроки выполнения закрытия месяца не устраивали заказчика абсолютно. Например, в самой крупной ДО вся процедура стала выполняться более суток!

2. А самая длительная операция – непосредственно расчет себестоимости, – выполнялась порядка 9-11 часов.

3. Длительность операции отражения документов в регламентированном учете достигала 12 часов.

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

5. Исходя из аппаратных мощностей заказчика были попытки запустить на одновременное выполнение закрытие месяца в 20+ баз ERP, но эти попытки к успеху не привели –  фатальная деградация производительности возникала и в этом случае.

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

 

 

Самое начало – декомпозиция проблемы

 

После обследования проблему заказчика укрупненно разбили на две подзадачи:

  • поиск и устранение проблем стабильности, то есть выявление и борьба с таинственным завершением задания расчета
  • поиск и устранение проблем быстродействия (производительности)

 

Решение задачи стабильности

 

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

То, что фоновое задание расчета регулярно «падало» без каких-либо явных причин, на наш взгляд, требовало первоочередного решения.

В момент прерывания фонового задания единственное, что появлялось в Журнале регистрации 1С (далее ЖР 1С) – это запись, что фоновое задание «отменили». Здесь важно отметить: пользователи «всё отрицали», а сама отмена происходила по ночам, когда люди никак на это не влияли (спали).

 

Открыть оригинальный размер

 

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

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

На инфраструктурном уровне было выявлено три ключевые проблемы:

1. Ощутимо длительная миграция Виртуальных машин (далее ВМ).  

2. Большое количество переподписок на уровне хостов.

3. Софтверное ограничение на количество операций ввода-вывода для дисковой подсистемы в настройках ВМ, особенно на дисках под СУБД.

В связи с проблемами 1 (длительная миграция) и 2 (много переподписок) наблюдались «фризы» гостевой ОС, на которой располагались серверы 1С и СУБД – это показал анализ ТЖ 1С. Такая ситуация приводила к аварийному завершению процессов в кластерах 1С – подсистема отслеживания разрыва соединений 1С завершала их по таймауту, что было вполне штатным поведением в этом случае.

Решением здесь стало устранение миграций ВМ (запретили в настройках). Настроили выделение хостов таким образом, чтобы снизить количество переподписок и их перегрузки. Дополнительно увеличили значения «ping period» и «ping timeout». Теперь время миграции сократилось с минут до секунд, а кластер 1С это переживал штатно и аварийно процессы не завершал.

 

 

Вторая проблема была связана с бизнес-процессами заказчика, т.к. каждый ресурс для ВМ предоставляется «как сервис» и настройки изначально были установлены в режим минимального потребления. Ограничение IOPS для дисков с базой данных и tempdb на сервере СУБД было установлено в 8000. Наблюдалось огромное накопленное ожидание времени отклика и очереди к дискам.

Здесь добились снятия ограничений.

 

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

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

ОКей. Настраиваем ТЖ 1С. Помимо «джентльменского набора» из событий ADMIN, CLSTR, PROC, ATTN, EXCP, SESN и CONN, которые мы собираем во всех случаях, здесь нам, кажется, придется добавить и события по SCALL” и “CALL, причем с контекстами - мы хотим понять, кто сделал вызов, который привел к отмене задания. Чтобы логи не были большими, добавим фильтр по имени метода MName=cancelJobs:

   <event>
      <eq property="name" value="CALL"/>
      <eq property="MName" value="cancelJobs"/>
    </event>
   <event>
      <eq property="name" value="SCALL"/>
      <eq property="MName" value="cancelJobs"/>
    </event>

 

Запускаем контрольный расчет. Дожидаемся очередной «отмены».

Смотрим в ТЖ 1С: на контексты, на пользователей, в них участвующих. Начинаем во всем этом разбираться…

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

Конечно, мы видим в журнале событие ADMIN с Func=killClient:

34:27.654029-0,ADMIN,2,process=rphost,p:processName=ServerJobExecutorContext,OSThread=16140,t:clientID=20,t:applicationName=JobScheduler,t:computerName=ITE-MP-00159,Func=killClient,ClusterID=21a7019b-f1a0-422e-9387-95dab1819984,ConnectionID=0f337f02-6264-4b0d-86a5-917909aa7cc3,Mode=0,Ref=Expert_ERP(Expert_ERP),Host=ITE-MP-00159,Connection=171,Administrator=Unknown,Result=Success

 

Вслед за ним после нотификации CALL с MName=killConnections видим EXCP, тот самый, который увидел пользователь:

34:27.670002-0,EXCP,4,process=rphost,p:processName=Expert_ERP,OSThread=17276,t:clientID=35,t:applicationName=BackgroundJob,t:computerName=ITE-MP-00159,t:connectID=171,SessionID=5,Usr=Administrator,Exception=95c658d1-d3d5-4ea9-8a81-1bf820fea4a8,Descr='src\rscalls\src\RemoteCallListenerImpl.cpp(4014):
95c658d1-d3d5-4ea9-8a81-1bf820fea4a8: Сеанс работы завершен администратором.',Context='
ОбщийМодуль.ЗакрытиеМесяцаСервер.Модуль : 3322 : Обработки.ОперацииЗакрытияМесяца.ВыполнитьРасчетЭтапов(ПараметрыЗапуска);

 

Эта информация нам ничего не дает. Зато сделанный примерно в то же время в сеансе пользователя, запустившего фоновое задание, исходящий вызов:

34:26.779013-4,SCALL,3,process=rphost,p:processName=Expert_ERP,OSThread=23516,t:clientID=19,t:applicationName=1CV8C,t:computerName=ITE-MP-00159,t:connectID=1,SessionID=1,Usr=Administrator,AppID=1CV8C,ClientID=46,Interface=90d50089-2b1d-4316-ad85-32c83d325a76,IName=IClusterJobManager,Method=9,CallID=12735,MName=cancelJobs,DstClientID=62,Context='Форма.Вызов : Обработка.ОперацииЗакрытияМесяца.Форма.ЗакрытиеМесяца.Модуль.ЗавершениеЗаданийПриЗакрытииФормы
Обработка.ОперацииЗакрытияМесяца.Форма.ЗакрытиеМесяца.Форма : 1293 : ОтменитьФоновоеЗадание(ИдентификаторЗаданияРасчетаЭтапов, Ложь);
	Обработка.ОперацииЗакрытияМесяца.Форма.ЗакрытиеМесяца.Форма : 1939 : Если НЕ ЗакрытиеМесяцаСервер.ОтменитьВыполнениеФоновогоЗадания(ИдентификаторЗадания) Тогда
		ОбщийМодуль.ЗакрытиеМесяцаСервер.Модуль : 4732 : СостояниеЗадания.Задание.Отменить();'

 

 

Наконец приоткрываем завесу тайны.

…оказывается, пользователь действительно не нажимал никаких «отмен».

 

НО!

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

 

 

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

 

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

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

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

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

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

 

 

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

Соединение с сервером баз данных разорвано администратором

 

Обращаемся к администраторам с вопросом, зачем они с нами так. Ожидаемый ответ: «мы ничего не делали». Идем в логи ;)

В логах СУБД чисто – никаких команд на разрыв нет. Сервер СУБД вроде как работает штатно. Опять какая-то «магия».

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

При анализе ТЖ 1С видно – процессы не завершаются, на серверах СУБД нет никакой характерной активности (команду «kill» никто, включая платформу 1С, не вызывал). Следов зависаний и перезапуска ВМ – не видим. Как будто бы все работает штатно.

Единственное, за что зацепился глаз – за 20 минут до аварийного завершения фонового задания, один из сеансов записал в ТЖ 1С ошибку соединения с сервером баз данных.

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

Эти «20 минут» не давали покоя, поэтому не найдя ничего на уровне прикладного ПО и СУБД, мы снова вернулись на уровень инфраструктуры. Детальное расследование показало, что в момент времени «за 20 минут до завершения фонового задания» происходила миграция ВМ – очень быстро и кратковременно. Поэтому в ТЖ это даже никак и не отражалось. При таком стечении обстоятельств соединения с СУБД в пуле, сформированном платформой 1С, могут оказаться невалидны: попытка их использования даже спустя 20 минут после миграции выполняется платформой, но тут же завершается ошибкой.

Дальнейшее расследование привело к регистрации ошибки платформы 1С:

 

Открыть оригинальный размер

 

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

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

Заказчику было рекомендовано обновить версию платформы 1С.

Здесь можно подвести некоторые итоги – так сказать, зафиксировать промежуточный результат:

  1. Решены все проблемы стабильности – в первую очередь в работе длительного фонового задания расчета себестоимости.
  2. При этом расчет выполняется стабильно, но стабильно медленно J

 

 

Переходим к решению вопросов производительности

 

Изучаем подробный протокол расчета себестоимости. В частности, «топ 10» самых медленных этапов.

На примере самого крупного ДО заказчика показатели были такими:

  • расчет согласно протоколу в среднем длился 9 часов
  • при этом на этапе Партионный учет: ЗаписатьСформированныеДвижения в течение более 3 часов записывалось свыше 10 миллионов результирующих записей в регистры по итогам этого расчета

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

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

 

 

После анализа ситуации пользователям запретили заполнять аналитику по подразделениям в табличных частях документов поступлений расходов. Записи в регистры начали выполняться только с аналитикой из шапки этих документов. На бизнес-логику заказчика это никаким образом не повлияло - потом всё равно всё распределялось на все подразделения выпуска

В итоге нам удалось снизить время расчета с 9 часов до 4.5 часов.

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

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

  • Max Degree of Parallelism (MAXDOP) = 8
  • Cost Threshold for Parallelism (cost degree) = 400
  • TF 1224 (заранее понимаем, что без него никак)

ВНИМАНИЕ! Настройки СУБД не являются рекомендованными, подобраны в этой конкретной ситуации опытным путем и приводятся только с целью ознакомления.

 


 

Результат после применения такой настройки по времени выполнения снизился с 4.5 часов до 2.5 часов.

Казалось бы, целевой показатель на базе самого крупного ДО достигнут и можно выдыхать J

Ан нет!

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

Тестовый запуск закрытия месяца в двух ДО одновременно показывает следующее:

  • загрузка процессора на серверах не выше 40 %
  • RAM на сервере кластера 1С – свободна на 50%
  • PLE на сервере СУБД не падает ниже 20-30 тысяч
  • buffer cache hit ratio 100%
  • время отклика дисков – ниже 10 миллисекунд

То есть показатели «железа» в норме и с большим запасом. Однако время расчета и в основном в части записи движений увеличивается в 1.5-2 раза в случае запуска в нескольких базах одновременно. И все эти показатели почти никак не отличаются от показателей во время закрытия месяца в какой-нибудь одной базе, но скорость самого закрытия в таком режиме – в два раза выше.

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

 

Ожидания СУБД при расчете в одной базе

Открыть оригинальный размер

Ожидания СУБД при параллельном расчете в 2 ИБ

Открыть оригинальный размер

СУБД: Page life expectancy

Открыть оригинальный размер

СУБД: Avg. Disk sec/Write

Открыть оригинальный размер

СУБД: % Processor Time

Открыть оригинальный размер

 

Внимательно все снова изучив (и не по одному разу), предполагаем, что проблема где-то в сети (потому что все остальное у нас покрыто метриками). Точнее понять, что именно и с чем это связано – не получается. Ни один график загрузки оборудования явных подсказок не дает.

 

Открыть оригинальный размер

 

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

Для этого используем хорошо себя зарекомендовавший Windows Performance Recorder (WPR) в паре с Windows Performance Analyzer (WPA) – подчас именно они выручают в ситуациях, когда «ничего не понятно, но что-то происходит».

Замечаем на сервере СУБД на одном ядре загрузку CPU system time, близкую при параллельном расчете к 100%. При этом остальные ядра могут простаивать. Явно что-то происходит в системных функциях ОС.

Для того чтобы выяснить, что именно происходит в системном слое ОС, включаем трассировку WPR. Открываем в WPA и практически сразу обращаем внимание на системный драйвер «NDIS.SYS» – он с большим отрывом оказался в топе, причем работает действительно на одном ядре в один момент времени - том самом, которое в то же самое время показывало 100% загрузку в привилегированном режиме:

 

Открыть оригинальный размер

 

Иными словами, анализ трассировки WPR сервера СУБД подтвердил предположение о том, что наибольшую нагрузку на CPU в привилегированном режиме создает драйвер сетевого интерфейса NDIS.SYS.

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

Полезно тут отметить вот что. Важно перепроверять не только свои действия/гипотезы, но и работу других команд в процессе решения общей проблемы. Здесь мы выдали в самом начале рекомендации «как устранить», но не проверили их применение. И отсутствие выполнения работ по нашим рекомендациям потом замедлило и усложнило нам путь в решении проблемы. В общем, принцип «доверяй, но проверяй» работает и на ИТ-проектах. Не наступайте на наши грабли! И мы тоже больше не будем ;)

Разбираемся. В настройках ВМ есть параметр Receive Side Scaling (RSS), отвечающий за способ разбора сетевого трафика – одним ядром это выполняется (выключен), либо распараллеливается (включен и указано количество). И в данном случае RSS был включен для ОС, но выключен для сетевого адаптера vmxnet3:

 

 

По рекомендации VMware включаем RSS для адаптера и выполняем его настройку, в частности, задаем Max Number of RSS processors = 4.

Проверяем. Вуаля: разницы при параллельном и последовательном расчете в нескольких базах ERP теперь нет. Сервер СУБД наконец-то загружен на все 70-80%.

Заказчик полученными показателями доволен ;)

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

Благодарим за внимание!

 

 

Вместо Post Scriptum

 

Конечно, процесс оптимизации можно продолжать [бесконечно]. Например, мы выявили что был также выключен прямой доступ к памяти (NetDMA). При необходимости, можно включить и его:

 

 

Узнать подробнее про WPR можно здесь:

https://docs.microsoft.com/ru-ru/windows-hardware/test/wpt/windows-performance-recorder

 

Про WPA там же рядом:

https://docs.microsoft.com/ru-ru/windows-hardware/test/wpt/windows-performance-analyzer

 

Что такое RSS, как технология обеспечивает распределение обработки входящих сетевых потоков по нескольким vCPU – неплохо описано в базе данных Microsoft:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh997036(v=ws.11)

 

Рекомендации по включению и настройке RSS от VMware:

https://kb.vmware.com/s/article/2008925 

 

Примеры настройки RSS:

https://communities.vmware.com/t5/ESXi-Discussions/RSS-issues-at-Windows-2012-R2-with-VMXNET3-and-10-2-0-VM-Tools/td-p/2747421

 

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

эксперт быстродействие erp 1С:Эксперт технологическим вопросам платформа деградация производительности производительность высокая нагрузка highload

См. также

Инструментарий разработчика Роли и права Запросы СКД Программист Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020    140673    772    391    

803

WEB-интеграция Универсальные функции Механизмы платформы 1С Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

28.08.2023    11569    YA_418728146    7    

154

Механизмы платформы 1С Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Мало кто знает, что поле "Глобального поиска" в 1С можно доработать. Добавить свои варианты поиска, кнопочки в результатах и даже целые пользовательские меню.

27.03.2023    7712    SeiOkami    10    

143

Запросы Инструментарий разработчика Программист Бесплатно (free)

Список всех популярных обработок.

17.03.2023    45360    kuzyara    87    

187

Механизмы платформы 1С Программист Платформа 1С v8.3 Бесплатно (free)

Давайте разберемся в механизме «История данных» и поэкспериментируем для наглядности. Сравним «Версионирование объектов» и «Историю данных».

06.03.2023    24284    dsdred    60    

200

Механизмы платформы 1С Программист Платформа 1С v8.3 Россия Бесплатно (free)

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

29.07.2022    51740    zeltyr    24    

204

Механизмы платформы 1С Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Копнем глубже в тему "Что же такое динамическое обновление" и почему оно может привести к проблемам. И может ли?

09.05.2022    29948    Infostart    83    

244

HighLoad оптимизация Технологический журнал Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    18096    ivanov660    18    

157
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. PerlAmutor 130 12.07.22 05:54 Сейчас в теме
Для статей, которые распределяются на производственные затраты по всем подразделениям, установлена аналитика расходов – подразделение. При оформлении поступления таких расходов в документе подразделение указывается в шапке, но затем еще в строках пользователями указывается иная, отличная от подразделения в шапке аналитика затрат. Именно это порождало избыточные записи прихода прочих затрат, которые далее в такой же детализации декартовым произведением распределялись на приходные записи незавершенного производства по всем подразделениям выпуска.


А можно поподробнее этот момент осветить? Пользователи наверняка не просто так в аналитике расходов указывали подразделение отличное от подразделения документа. Скажем, если Цех №1 оказывает услугу Цеху №2, то в аналитике расходов должен быть Цех №2, но никак не Цех №1. Если затрата распределяется по всем подразделениям, то в аналитике расходов должно быть пусто. Если затрата собственная, то в аналитике расходов должно быть свое подразделение, чтобы затрата не распределилась на всех.

По поводу падения рабочих процессов.
Тоже у себя увеличивали параметр PingTimeout до того пока не разобрались, что устаревший драйвер SSD диска на гипервизоре фризил. Вообще странное решение со стороны вендора прибивать рабочие процессы. Может надо было работу с сокетами иначе организовывать, чтобы таких таймаутов не возникало вовсе даже когда основной поток подвис на какой-нибудь файловой операции. Пусть работает медленней, но стабильно, без сюрпризов и с отражением таких проблем в ТЖ.
binx; AlekseyBelyy; sasha_r; it-expertise; +4 Ответить
2. it-expertise 328 12.07.22 10:19 Сейчас в теме
(1) По поводу первого вопроса-уточнения - эксперт сейчас в отпуске, попробуем через недельку ответить

По поводу второго (поведение платформы) - была зарегистрирована ошибка платформы, которая затем была исправлена.
3. it-expertise 328 12.07.22 11:15 Сейчас в теме
(1)
А можно поподробнее этот момент осветить? Пользователи наверняка не просто так в аналитике расходов указывали подразделение отличное от подразделения документа. Скажем, если Цех №1 оказывает услугу Цеху №2, то в аналитике расходов должен быть Цех №2, но никак не Цех №1. Если затрата распределяется по всем подразделениям, то в аналитике расходов должно быть пусто. Если затрата собственная, то в аналитике расходов должно быть свое подразделение, чтобы затрата не распределилась на всех.


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

Разумеется, решение, описанное в статье, о запрете заполнения аналитики в табличной части мы не принимали самостоятельно, оно было согласовано методологами заказчика и реализовано им самостоятельно. Мы всего лишь указали на проблему и предложили варианты решения.
sashocq; binx; sasha_r; +3 Ответить
4. it-expertise 328 12.07.22 11:18 Сейчас в теме
(1)
По поводу падения рабочих процессов.
Тоже у себя увеличивали параметр PingTimeout до того пока не разобрались, что устаревший драйвер SSD диска на гипервизоре фризил. Вообще странное решение со стороны вендора прибивать рабочие процессы. Может надо было работу с сокетами иначе организовывать, чтобы таких таймаутов не возникало вовсе даже когда основной поток подвис на какой-нибудь файловой операции. Пусть работает медленней, но стабильно, без сюрпризов и с отражением таких проблем в ТЖ.


Пинги мы увеличивали, когда миграция ВМ шла долго, чтобы за время фриза не прибивались процессы. Тут никакой ошибки платформы нет. И странным поведение платформы мы не считали (не считаем).
5. muskul 12.07.22 12:04 Сейчас в теме
как и ожидалось вначале больше половина проблем изза виртуалок.
Немного не понял а почему виртуалки мигрируют туда сюда?
6. ivanov660 4544 12.07.22 12:22 Сейчас в теме
(5)Это скорее всего балансировщик нагрузки работает. Опционально отключается админами. С проблемой такой тоже сталкивались, после чего запретили миграцию для некоторых машин.
sasha_r; it-expertise; +2 Ответить
7. it-expertise 328 12.07.22 12:32 Сейчас в теме
(6) (5)

Именно так - это балансировка vmWare.
ВМ мигрирует на менее загруженный хост при сильной загрузке текущего, чтобы обеспечить максимальную производительность.
8. it-expertise 328 12.07.22 12:42 Сейчас в теме
(5)
И кстати отключать миграцию - неправильный с т.з. работы виртуализации подход. Отключать можно и нужно для серверов лицензирования просто потому что это будет приводить к необходимости повторной активации программных лицензий. Во всех остальных случаях правильно искать проблему, по которой миграция мешает работе. Сама по себе она происходит обычно мгновенно.
14. ivanov660 4544 12.07.22 16:14 Сейчас в теме
(8)
1. На сколько я знаю миграция происходит прозрачно и параметры машины не меняются, поэтому почему будет требоваться пере активация лицензий?
2. Проблема в знакомом мне случае (как и в вашем) была в самой 1С. Она так капризно ведет себя даже при таком мгновенном переключении. Сколько времени будет идти фиксация ошибки - доказывание компании 1С (это просто жесть), ее исправление, проверка новой версии и т.п., поэтому решение вполне оправданное, на мой взгляд.
3. Запуск миграции может произойти к примеру из-за запуска бухгалтером закрытия месяца, и машина поехала туда где свободнее.
mitia.mackarevich; sasha_r; +2 Ответить
25. mitia.mackarevich 74 13.07.22 11:14 Сейчас в теме
(14) по поводу 1 пункта, у нас в инфраструктуре столкнулся с тем, что все таки могут меняться даже при условии когда не меняются параметры виртуальной машины. При том, что модель процессора не меняется, а защита ругается на изменение какого то внутреннего уникального номера процессора. Очень интересно и неоднозначно получалось, было это на 8.3.17. Сейчас 8.3.20 как работает сказать не могу, так используем сервер лицензирования (запрещена миграция). Используем vmware
it-expertise; +1 Ответить
9. user1466751 18 12.07.22 12:46 Сейчас в теме
А есть где-нить в сети инструкция по настройке ВМ под 1С?
10. it-expertise 328 12.07.22 12:54 Сейчас в теме
(9) Выше написали наши соображения относительно отключения миграции ВМ для сервера лицензирования. В остальном - нужно по ситуации смотреть.
18. cdiamond 235 12.07.22 19:12 Сейчас в теме
(9) у vmware есть подробный документ по настройке MSSQL на ВМ, на английском конечно, но тот кто этим занимается язык понимать обязан. Нагуглить можно. В статье не все рекомендации, их там в докумете гораздо больше.
11. quazare 3729 12.07.22 13:11 Сейчас в теме
В своем опыте напишу, что вся проблема может заключаться в кривых настройках виртуальных машин.

Фактически сами админы не думаю и не понимаю проблемы…
12. tolyan_ekb 105 12.07.22 15:01 Сейчас в теме
Ну хоть стало понятно чем в ИТ Экспертиза заниматься придется, если надумаю экспертом становиться. ))
it-expertise; +1 Ответить
13. it-expertise 328 12.07.22 15:25 Сейчас в теме
(12) у нас можно сначала заняться (при соответствующем уровне знаний), потом становится 1С:Экспертом ;)
19. tolyan_ekb 105 13.07.22 06:26 Сейчас в теме
(13) Подскажите, сколько примерно времени это заняло, если можно по шагам.
20. it-expertise 328 13.07.22 08:16 Сейчас в теме
(19) Если "это" - вопрос про трудовой процесс на пути к 1С:Эксперту, то приблизительно про требования описано в наших вакансиях (ссылка есть на сайте).

Там ключевое - не обязательно сразу иметь 1С:Эксперта, главное чтоб было желание его получить. Набор опыта гарантирован, обучение за счет компании.

Если есть желание обсудить оставшиеся трудовые вопросы, замкну на наших замечательных HR. Напишите в личку, если будет желание ;)
AlekseyBelyy; sasha_r; tolyan_ekb; +3 Ответить
15. quazare 3729 12.07.22 16:40 Сейчас в теме
Надо тоже рассказ написать как я резал базу 600 гб в одиночку без отрыва от производства )))))
rbdaurov; +1 Ответить
17. it-expertise 328 12.07.22 17:48 Сейчас в теме
(15) с интересом почитаем!!1
;)
32. tango 544 03.01.24 23:37 Сейчас в теме
(15) на хрен
пусть в следующий раз сами режут
16. пользователь 12.07.22 16:50
Сообщение было скрыто модератором.
...
21. bugagashenka 204 13.07.22 08:49 Сейчас в теме
В связи с проблемами 1 (длительная миграция) и 2 (много переподписок) наблюдались «фризы» гостевой ОС, на которой располагались серверы 1С и СУБД – это показал анализ ТЖ 1С


Можно чуть подробнее этот момент?
22. it-expertise 328 13.07.22 09:43 Сейчас в теме
(21) Непосредственно фризы показали графики загрузки оборудования perfmon, и их (факты миграции) подтвердили данные системы виртуализации.

Анализ ТЖ показал, что процессы кластера были перезапущены системой мониторинга кластера после того, как не ответили ей в течение pingTimeout.
AlekseyBelyy; bugagashenka; sasha_r; +3 Ответить
26. bugagashenka 204 13.07.22 11:43 Сейчас в теме
(22) понял. Спасибо за ответ. Просто в статье было указано, что именно в ТЖ были эти данные, вот и подумал, что появилось что-то новое в методиках. Особенно про СУБД и ТЖ смутило
23. KUAvanesov 13.07.22 09:47 Сейчас в теме
Хорошо бы еще узнать в какие сроки был реализован этот проект оптимизации?
it-expertise; dmitryada; +2 Ответить
24. it-expertise 328 13.07.22 10:33 Сейчас в теме
(23) весь процесс занял около двух месяцев.

Но в этом проекте у нас не было прямого доступа к стенду. Мы говорили их ИТ-специалистам, что где настроить и как собрать, они делали, запускали, передавали нам результаты. То есть паузы периодически возникали в процессе и достаточно большие.
AlekseyBelyy; mitia.mackarevich; sasha_r; +3 Ответить
27. capitan 2546 13.07.22 18:07 Сейчас в теме
Вспоминается...
Теорема ускорения серверов
Лучший способ ускорить сервер это ускорить серверного админа.
Следствие
Нет такого сервера, который нельзя было бы ускорить, есть админы, которых вы не можете ускорить.


В небольших компаниях обычно главбух после/перед каждым совещанием зажимает ДИТ в угол с криком: Сделайте что-нибудь!!!!
Потом админа мотивируют отрицательным ростом премии, он пыхтит пару выходных и все налаживается.
А тут 20 дочерних организаций, пришлось бежать за подмогой.
it-expertise; +1 Ответить
28. it-expertise 328 13.07.22 18:34 Сейчас в теме
(27) лучше взять одну квалифицированную подмогу, чем 19 новых админов ;)))
29. tango 544 03.01.24 21:56 Сейчас в теме
изначально мы сразу сделали экспресс-аудит и выдали набор стандартных рекомендаций по самым очевидным вещам, поэтому ожидалось что наши рекомендации учтены и работы по замечаниям выполнены

:))))) это прекрасно я щитаю
30. tango 544 03.01.24 22:24 Сейчас в теме
2.5.15.49
не закрывайте форму
Прикрепленные файлы:
31. tango 544 03.01.24 22:25 Сейчас в теме
(30) ну, по крайней мере одну необходимую доработку я знаю
Оставьте свое сообщение