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

Публикация № 1692364 11.07.22

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

эксперт быстродействие erp 1С:Эксперт технологическим вопросам платформа деградация производительности производительность высокая нагрузка 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

 

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

Специальные предложения

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


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

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

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


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

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


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

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

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

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

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


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

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

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


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

См. также

Версионирование объектов VS История данных

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

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

06.03.2023    3424    dsdred    32    

107

Практическая шпаргалка по новым возможностям языка запросов 1С

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

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

21.11.2022    14923    quazare    34    

108

Новые возможности языка запросов в платформе 8.3.20

Запросы Платформа 1С v8.3 Запросы Бесплатно (free)

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

27.09.2022    9035    zeltyr    17    

75

1С и Unicode

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

Разбираемся, как 1С работает с текстом и отдельными символами в контексте Unicode.

05.09.2022    3673    Irwin    30    

80

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

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

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

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

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    5843    Chernazem    44    

105

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 1С:Управление холдингом Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    5006    sapervodichka    60    

73

Шпаргалка по функциям АСИНХ

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

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

29.07.2022    12801    zeltyr    17    

137

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 8.3.14 8.3.6 8.3.8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    7256    Neti    7    

86

Динамическое обновление - это зло?

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

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

09.05.2022    16354    Infostart    77    

227

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

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

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

28.02.2022    12565    ivanov660    18    

144

Несколько простых приемов для удобной работы в конфигураторе

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

Простая и удобная среда разработки 1С:Предприятия позволяет практически любому человеку начать работать под капотом 1С - в конфигураторе. Время идет, новички становятся программистами, специалистами, а об удобных приемах работы узнают годами, по ходу своего карьерного пути. А здорово было бы, если бы все знали удобные приемы в начале своего пути? Эти несколько приемов будут полезны новичкам, так как они затрагивают ту область работы, с которой приходится сталкиваться в начале карьеры.

12.11.2021    12047    acces969    95    

138

Видеокурс-практикум: как подготовить и написать ТЗ, ЗНР, ЧТЗ. Промо

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

3 500 рублей

Как спроектировать структуру регистра сведений

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

«Что может быть проще?» — это первое, что приходит в голову. Но что, если это не так? В этой статье мы попробуем затронуть некоторые вопросы, которые могут возникнуть при проектировании больших регистров.

08.11.2021    8569    Neti    60    

108

Готовые механизмы 1С: ЗУП, представления

Механизмы типовых конфигураций Запросы Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Бесплатно (free)

Здесь будет храниться архив запросов, которые могут помочь разработчику правильно строить отчеты и получать данные в 1С: ЗУП. Статью буду периодически дополнять.

03.11.2021    6835    Margo462    19    

88

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

HighLoad оптимизация Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    15629    ivanov660    77    

139

Поиск причин блокировок СУБД

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

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    8138    vasilev2015    14    

84

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Программное создание расширения

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

Создание нового расширения "на лету", только штатными средствами 1С.

06.04.2021    6889    Yashazz    16    

76

Решение нестандартных проблем производительности на реальных примерах

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    7721    AlexKriulin    37    

77

Последний раз про срез последних (на каждую дату в запросе)

Запросы Платформа 1С v8.3 Запросы Бесплатно (free)

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

15.02.2021    32577    randomus    47    

149

Распознавание и загрузка документов в 1С Промо

Универсальная программа-обработка для распознавания любых сканов или фото первичных документов в 1С (счета-фактуры, УПД, ТТН, акты и тд). Точность распознания до 98%.

от 11 рублей

О формах 1С замолвите слово... Необычное использование знакомого всем объекта

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

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

13.01.2021    10521    CyberCerber    46    

101

Наследование свойств элементов, или Как пользователь может сломать вашу форму

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

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

12.01.2021    6394    SeiOkami    27    

111

Аналог PIVOT в запросе 1С (как выполнить транспонирование таблицы в запросе 1С)

Запросы Платформа 1С v8.3 Бесплатно (free)

В статье показывается простой метод реализации аналога оператора PIVOT в запросе 1С без использования соединений.

12.12.2020    8484    Eugen-S    25    

71

Итоги по объединенной совокупности группировок в запросе

Запросы Платформа 1С v8.3 Бесплатно (free)

Способ формирования итогов в запросе по совокупности группировок, объединенных в единый набор, при помощи функции АВТОНОМЕРЗАПИСИ.

18.11.2020    11307    antonivan    21    

99

Новое отображение ошибок в 1С

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

Рассмотрим развитие механизма отображения ошибок в 1С (начиная с 8.3.17)

10.08.2020    37500    SeiOkami    45    

143

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Вы запускаете приложения, но делаете это без уважения

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

О запуске сторонних приложений и скриптов из кода встроенного языка платформы 1С.

21.07.2020    15153    Infostart    32    

133

Использование Стека вызовов в качестве условия оператора Если [...] Тогда

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

Делюсь интересным приёмом, позволяющим использовать данные стека исполнения кода 1С в качестве условия, накладываемого на выполнение кода.

12.07.2020    12924    sapervodichka    65    

92

Серверные вызовы, которые нельзя вызывать

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

Не баян, а классика. Рассмотрим особенность платформы настолько же древнюю, как сами УФ.

12.05.2020    13784    SeiOkami    34    

146

Проводим по БУ "на лету"

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

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

01.05.2020    9236    sapervodichka    1    

93

Эти занимательные временные таблицы

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    25413    Infostart    0    

187

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

HighLoad оптимизация WEB-интеграция Мобильная разработка Администрирование веб-серверов Платформа 1С v8.3 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    18282    informa1555    35    

149

Анализ взаимоблокировок

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

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

20.03.2020    9104    vasilev2015    40    

88

Нечёткий поиск "ПОДОБНО". Нюансы

Запросы Платформа 1С v8.3 Бесплатно (free)

Заметки о "ПОДОБНО" в языке запросов

23.02.2020    58581    Yashazz    34    

120

Эволюция расширения конфигурации

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

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

06.02.2020    21762    Xershi    49    

186