Текущая конфигурация такая:
MS SQL 2012
1С:Предприятие 8.3 (8.3.10.2667)
1С:Молокозавод, редакция 1.3 (1.3.112.4)
клиенты сидят на win xp и win 7
После одного из летних обновлений пользователи двух рабочих мест стали жаловаться на периодические (не каждый день) дикие тормоза.
Причем тормоза случаются когда нагрузка на сервер минимальная.
Ранним утром в районе 06-08 часов и днем в районе 15-16 часов.
Тормоза заключаются в том, что сильно замедляется доступ к записям в справочниках. Человек жмет, например, чтобы выбрать контрагента или продукцию и ждет, ждет, ждет.
Windows XP заменил на Windows 7 - не помогло.
Порой помогает перезагрузка рабочего места. Порой это помогает но на непродолжительное время.
Как бы по совокупности симптомов - надо грешить на рабочую станцию.
Но в чем там может быть дело?
Почему тормоза возникают в определенные периоды? Пускай временные рамки этих периодов и размыты, но зависимость наблюдается четкая.
Проверял загрузку исправность и сети. Все ОК. Компьютер и HDD в частности -так же все ОК.
Переставлял ось (как писал выше) - не помогло.
Смотрел шедулер - ничего там особенного нет. А на описываемые периоды - вообще ничего нет.
Какие будут соображения?
MS SQL 2012
1С:Предприятие 8.3 (8.3.10.2667)
1С:Молокозавод, редакция 1.3 (1.3.112.4)
клиенты сидят на win xp и win 7
После одного из летних обновлений пользователи двух рабочих мест стали жаловаться на периодические (не каждый день) дикие тормоза.
Причем тормоза случаются когда нагрузка на сервер минимальная.
Ранним утром в районе 06-08 часов и днем в районе 15-16 часов.
Тормоза заключаются в том, что сильно замедляется доступ к записям в справочниках. Человек жмет, например, чтобы выбрать контрагента или продукцию и ждет, ждет, ждет.
Windows XP заменил на Windows 7 - не помогло.
Порой помогает перезагрузка рабочего места. Порой это помогает но на непродолжительное время.
Как бы по совокупности симптомов - надо грешить на рабочую станцию.
Но в чем там может быть дело?
Почему тормоза возникают в определенные периоды? Пускай временные рамки этих периодов и размыты, но зависимость наблюдается четкая.
Проверял загрузку исправность и сети. Все ОК. Компьютер и HDD в частности -так же все ОК.
Переставлял ось (как писал выше) - не помогло.
Смотрел шедулер - ничего там особенного нет. А на описываемые периоды - вообще ничего нет.
Какие будут соображения?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2)
Да. Нормально.
(2)
Компьютеры поменять без проблем. И обязательно это сделаю. А вот пользователей не получится.
Те. кто там сидит - перейти в другое место не могут.
И другие на эти физические места перейти не могут.
У каждого пользователя своя роль. Так что если выбрать пользователя не работающего на данном участке - ничего не получится. Оператор не сможет выполнить свои задачи.
А перебор пользователей работающих в данном месте и так происходит.
Сегодня пользователь С работал за компьютером В, завтра за компьютером А, а послезавтра он вообще не работает.
(3)
Да нет. 4 Гб памяти, дуалкор на 2,9 Ггц, саташные диски.
Тормозов нет. Если не брать случаи о которых я писал.
(4)
Что то подобное я подозревал. Мониторил сеть. Ничего не обнаружил.
(3)
Не регламент - это точно. Ни sql ни 1с.
(5)
Сперва подключал "анализ долгих запросов" Гилаева. Затем вообще технологический журнал перенастроил и смотрел "вручную".
Во время тормозов резко увеличивается время выполнения запросов.
Вот и все что удалось высмотреть.
А еще наблюдаю такое дело. Раньше этого тоже не было.
Девушки шустрые. Работают они в формах напоминающих экселевские таблицы.
Перематывают таблицу вверх вниз и проставляют напротив продуктов количество.
Так вот. Сперва работа идет шустро. А потом перемотка как бы начинает тормозить.
Девушка нажала курсор вниз, а активная строка вниз еще не успела перейти.
Перезагрузка помогает, но на несколько минут.
(как будто какой то буфер переполняется)
Если работать не торопясь - этого не заметить. А быстро - весьма нервирует.
- у остальных все нормально?
Да. Нормально.
(2)
попробуйте поменять местами компьютеры и пользователей базы
Компьютеры поменять без проблем. И обязательно это сделаю. А вот пользователей не получится.
Те. кто там сидит - перейти в другое место не могут.
И другие на эти физические места перейти не могут.
У каждого пользователя своя роль. Так что если выбрать пользователя не работающего на данном участке - ничего не получится. Оператор не сможет выполнить свои задачи.
А перебор пользователей работающих в данном месте и так происходит.
Сегодня пользователь С работал за компьютером В, завтра за компьютером А, а послезавтра он вообще не работает.
(3)
Если имеется станция на ХР, то судя по всему ей сто лет в обед?
Да нет. 4 Гб памяти, дуалкор на 2,9 Ггц, саташные диски.
Тормозов нет. Если не брать случаи о которых я писал.
(4)
Может в это время по сети что-то летит большое и тяжелое с этих/на эти рабочих мест
Что то подобное я подозревал. Мониторил сеть. Ничего не обнаружил.
(3)
Из неявного - анализируйте список регламентных заданий.
Не регламент - это точно. Ни sql ни 1с.
(5)
Настройте технологический журнал на сервере 1С и посмотрите что такого делал сервер во время тормозов
Сперва подключал "анализ долгих запросов" Гилаева. Затем вообще технологический журнал перенастроил и смотрел "вручную".
Во время тормозов резко увеличивается время выполнения запросов.
Вот и все что удалось высмотреть.
А еще наблюдаю такое дело. Раньше этого тоже не было.
Девушки шустрые. Работают они в формах напоминающих экселевские таблицы.
Перематывают таблицу вверх вниз и проставляют напротив продуктов количество.
Так вот. Сперва работа идет шустро. А потом перемотка как бы начинает тормозить.
Девушка нажала курсор вниз, а активная строка вниз еще не успела перейти.
Перезагрузка помогает, но на несколько минут.
(как будто какой то буфер переполняется)
Если работать не торопясь - этого не заметить. А быстро - весьма нервирует.
Если имеется станция на ХР, то судя по всему ей сто лет в обед? Никакой сервер не спасет, если рабочая станция слабая. Это из явного. Из неявного - анализируйте список регламентных заданий. Вполне вероятно корень зла там находится.
Может в это время по сети что-то летит большое и тяжелое с этих/на эти рабочих мест, у одного моего пользователя было 2 ПЭВМ с перекрестным резервным копированием через robocopy, в 15-00 с одной ПК1 на ПК2, в 16-00 с ПК2 на ПК1. Работать было практически невозможно, дешевый коммутатор и проч.
Не пойму.
Куда то пропал мой вчерашний последний пост.
Да и группировка сообщений в теме какая то странная.
Ну да ладно. Дублирую вчерашнюю информацию.
Вчера нарвался на сильные тормоза.
Проблемные рабочее места чуть ли не впали в ступор.
Даже нажатие на экранные кнопки отрабатывались секунд по 20.
Скорее у девушек запустил RDP.
На сервере - аналогично. Сервер стоит колом.
Стал искать гада. Все чисто.
Надоумило меня заглянуть в регламентные задания.
А там в это время происходило обновление индекса полнотекствого поиска.
Не буду говорить что я сделал - не суть важно.
Сегодня ругается зарплатник. Зарплату клинит не по детски.
А у него стоит ЗУП 3.1 под SQL (базы стоят на том же самом сервере) и платформа та же самая (8.3.10.2667)
Памятуя вчерашние события полез смотреть регламентые/ фоновые задания.
И то же самое. Обновление индекса ППД.
Вопрос.
С какой стати эта "легкая" и быстрая операция стала ставить сервер на дыбы?
До середины лета все было нормально а потом УПП и ЗУП стали очень нервно относится к обновлению индекса.
p.s. я конечно обновление и слияние индекса после этого сделал раз в сутки, но ведь это не порядок. Надо как то лечить таблетками, а не отрубать голову топором.
Куда то пропал мой вчерашний последний пост.
Да и группировка сообщений в теме какая то странная.
Ну да ладно. Дублирую вчерашнюю информацию.
Вчера нарвался на сильные тормоза.
Проблемные рабочее места чуть ли не впали в ступор.
Даже нажатие на экранные кнопки отрабатывались секунд по 20.
Скорее у девушек запустил RDP.
На сервере - аналогично. Сервер стоит колом.
Стал искать гада. Все чисто.
Надоумило меня заглянуть в регламентные задания.
А там в это время происходило обновление индекса полнотекствого поиска.
Не буду говорить что я сделал - не суть важно.
Сегодня ругается зарплатник. Зарплату клинит не по детски.
А у него стоит ЗУП 3.1 под SQL (базы стоят на том же самом сервере) и платформа та же самая (8.3.10.2667)
Памятуя вчерашние события полез смотреть регламентые/ фоновые задания.
И то же самое. Обновление индекса ППД.
Вопрос.
С какой стати эта "легкая" и быстрая операция стала ставить сервер на дыбы?
До середины лета все было нормально а потом УПП и ЗУП стали очень нервно относится к обновлению индекса.
p.s. я конечно обновление и слияние индекса после этого сделал раз в сутки, но ведь это не порядок. Надо как то лечить таблетками, а не отрубать голову топором.
Все же, похоже я нашел причину тормозов.
Допускаю, что обновление индекса могло приводить к тормозам, но это был вторичный симптом.
Виновником оказался tempdb.
Только вот если у людей он бывает растет неумеренно - у меня наоборот - не растет. Дискового пространства - выше крыши, а размер этой базы не превышает 1,9 Гб.
Допускаю, что не растет потому что нет необходимости. Но тогда получается, что tempdb забивается хламом, который как то тормозит работу и почему то не чистится.
В общем - запускаю шринк tempdb и тормоза сразу пропадают.
Никто с такой проблемой не сталкивался?
Не подскажете лекарство?
А то шринк, конечно выход. Поставил его в регламентое задание SQL и все ОК.
Вот только иногда на 1С запускаються операции требующие очень, очень много времени.
Например закрытие месяца, перепроведение документов и пр. И эти операции обязательно попадут под шринк.
И что тогда будет? Задание 1С встанет? Или получим не корректные данные?
В общем то, не хотелось бы прибегать к столь кардинальным мерам, как обрезка временной базы.
p.s. есть небольшая надежда, что поможет SP2 для SQL. Но информация весьма смутная и не факт, что достоверная.
Допускаю, что обновление индекса могло приводить к тормозам, но это был вторичный симптом.
Виновником оказался tempdb.
Только вот если у людей он бывает растет неумеренно - у меня наоборот - не растет. Дискового пространства - выше крыши, а размер этой базы не превышает 1,9 Гб.
Допускаю, что не растет потому что нет необходимости. Но тогда получается, что tempdb забивается хламом, который как то тормозит работу и почему то не чистится.
В общем - запускаю шринк tempdb и тормоза сразу пропадают.
Никто с такой проблемой не сталкивался?
Не подскажете лекарство?
А то шринк, конечно выход. Поставил его в регламентое задание SQL и все ОК.
Вот только иногда на 1С запускаються операции требующие очень, очень много времени.
Например закрытие месяца, перепроведение документов и пр. И эти операции обязательно попадут под шринк.
И что тогда будет? Задание 1С встанет? Или получим не корректные данные?
В общем то, не хотелось бы прибегать к столь кардинальным мерам, как обрезка временной базы.
p.s. есть небольшая надежда, что поможет SP2 для SQL. Но информация весьма смутная и не факт, что достоверная.
И опять мимо кассы!!!
Главный виновник не tempdb.
В пять часов вечера звонок.
Все встало.
Захожу по RDP на сервер.
Постоянная загрузка процессора 50% - что для нас не реальная цифра.
Пробую шринк tempdb. Не помогает. Смотрю регламентные задания - ничего не выполняется.
Смотрю в консоли сервера 1С.
А там у один из клиентов перемолотил объем данных свыше 50 ГБ. Цифра не реально большая. Более чем на порядок выше значения когда все работает без сбоев.
(Этот клиент производит массовую обработку документов и на основе одних (заказ покупателя) - формирует другие документы (накладные сч/фак, пропуска). Но в нормальных условиях такая операция не приводит к каким либо затыкам.
Удалил клиента из консоли сервера - загрузка упала до нуля.
В общем - нет никаких мыслей - куда дальше копать.
Главный виновник не tempdb.
В пять часов вечера звонок.
Все встало.
Захожу по RDP на сервер.
Постоянная загрузка процессора 50% - что для нас не реальная цифра.
Пробую шринк tempdb. Не помогает. Смотрю регламентные задания - ничего не выполняется.
Смотрю в консоли сервера 1С.
А там у один из клиентов перемолотил объем данных свыше 50 ГБ. Цифра не реально большая. Более чем на порядок выше значения когда все работает без сбоев.
(Этот клиент производит массовую обработку документов и на основе одних (заказ покупателя) - формирует другие документы (накладные сч/фак, пропуска). Но в нормальных условиях такая операция не приводит к каким либо затыкам.
Удалил клиента из консоли сервера - загрузка упала до нуля.
В общем - нет никаких мыслей - куда дальше копать.
Есть мысль, что по какой то причине для динамических списков ваших справочников может слетать (программно сниматься?) основная таблица и динамическое чтение данных. Может меняется текст запроса дин.списков для этих ролей? Стоило бы посмотреть план запроса, который отправляется на скуль при открытии этих форм.
(15)
В случае 1С - такое событие от чего зависит? От платформы или конфигурации?
На кого бочку катить? На разработчиков 1С или разработчиков конфигурации?
(15)
Я могу настроить технологический журнал чтобы сохранить текст запроса в случае если запрос продолжается более, например, 5 сек?
Или как можно другим путем вытащить текст запроса?
Хотя, конечно, лучше через технологический журнал. Потому что если это возможно - запрос будет сохранен автоматически.
Сегодня обновил платформу на 1С. Была 8.3.10.2667 - стала 8.3.12.1714
посмотрю - поможет или нет
Есть мысль, что по какой то причине для динамических списков ваших справочников может слетать (программно сниматься?) основная таблица и динамическое чтение данных.
В случае 1С - такое событие от чего зависит? От платформы или конфигурации?
На кого бочку катить? На разработчиков 1С или разработчиков конфигурации?
(15)
Стоило бы посмотреть план запроса, который отправляется на скуль при открытии этих форм.
Я могу настроить технологический журнал чтобы сохранить текст запроса в случае если запрос продолжается более, например, 5 сек?
Или как можно другим путем вытащить текст запроса?
Хотя, конечно, лучше через технологический журнал. Потому что если это возможно - запрос будет сохранен автоматически.
Сегодня обновил платформу на 1С. Была 8.3.10.2667 - стала 8.3.12.1714
посмотрю - поможет или нет
(18)
Запустил и настроил.
Сейчас конфиг такой:
...
<eq property="Name" value="LEAKS"/>
</event>
<event>
<eq property="Name" value="SC0M"/>
</event>
<event>
<eq property="Name" value="QERR"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
<eq property="Func" value="BeginTransaction"/>
</event>
<event>
<eq property="Name" value="DBMSSQL"/>
<ge property="Duration" value="5000"/>
</event>
<property name="All"/>
...
Как? Нормально? Может что то выкинуть или добавить?
А есть вариант:
...
<event>
<eq property="Name" value="DBMSSQL"/>
<ge property="Duration" value="1000"/>
</event>
<event>
<eq property="Name" value="DBV8DBEng" />
</event>
<property name="Sql" />
<property name="Context" />
<property name="Usr" />
<property name="planSQLText" />
...
Может этого достаточно?
Но здесь только текст запроса и объем этого текста для каждого запроса совсем не маленький.
Повторюсь: Настройте технологический журнал на сервере 1С и посмотрите что такого делал сервер во время тормозов.
Запустил и настроил.
Сейчас конфиг такой:
...
<eq property="Name" value="LEAKS"/>
</event>
<event>
<eq property="Name" value="SC0M"/>
</event>
<event>
<eq property="Name" value="QERR"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
<eq property="Func" value="BeginTransaction"/>
</event>
<event>
<eq property="Name" value="DBMSSQL"/>
<ge property="Duration" value="5000"/>
</event>
<property name="All"/>
...
Как? Нормально? Может что то выкинуть или добавить?
А есть вариант:
...
<event>
<eq property="Name" value="DBMSSQL"/>
<ge property="Duration" value="1000"/>
</event>
<event>
<eq property="Name" value="DBV8DBEng" />
</event>
<property name="Sql" />
<property name="Context" />
<property name="Usr" />
<property name="planSQLText" />
...
Может этого достаточно?
Но здесь только текст запроса и объем этого текста для каждого запроса совсем не маленький.
Во вложении файл результатов.
Как видно - стало плохо в районе 13.43-13.44. Потом я вышиб пользователя/процесс в консоли управления сервером 1С
Потом в районе 13.45 пользователь (Бурова) опять зашла в программу и доделала пропуска уже без тормозов.
Обратите внимание.
Если обычно идет чередующаяся последовательность Context SDBL, то когда стало плохо - пошли сплошные SDBL.
Как видно - стало плохо в районе 13.43-13.44. Потом я вышиб пользователя/процесс в консоли управления сервером 1С
Потом в районе 13.45 пользователь (Бурова) опять зашла в программу и доделала пропуска уже без тормозов.
Обратите внимание.
Если обычно идет чередующаяся последовательность Context SDBL, то когда стало плохо - пошли сплошные SDBL.
Прикрепленные файлы:
плохо в районе 13.43-13.44.zip
Кстати. Я просматривал технологические журналы программой из вложения.
Очень удобно. И фильтры есть.
Очень удобно. И фильтры есть.
Прикрепленные файлы:
TechLog1C.exe
В воскресенье тоже были тормоза в 10.19
Работница перезагрузила свой компьютер и все заработало без заминок.
Вот что в этот раз увидел в технологическом журнале:
Два EXCP события
19:14.971000-0,EXCP,0,process=rphost,OSThread=70912,Exception=NetDataExchangeException,Descr='Ping time out expired on direction: directionID=143f9ef9-73d6-405d-bc76-5b225eebdfe8, lastActivity=937164379, lastActivityTestTs=(937216270,937217286,937218301,937219317,937220332,937221348,937222364,937223379), timeout=60000, period=12000, currentTS=937224395, nChecks=3'
19:15.283000-0,EXCP,0,process=rphost,OSThread=72744,ClientID=193,Exception=NetDataExchangeException,Descr=Ping time out expired on connection
Речь идет о подключении рабочей станции к серверу? Была нарушена связь?
Или это что то другое?
Работница перезагрузила свой компьютер и все заработало без заминок.
Вот что в этот раз увидел в технологическом журнале:
Два EXCP события
19:14.971000-0,EXCP,0,process=rphost,OSThread=70912,Exception=NetDataExchangeException,Descr='Ping time out expired on direction: directionID=143f9ef9-73d6-405d-bc76-5b225eebdfe8, lastActivity=937164379, lastActivityTestTs=(937216270,937217286,937218301,937219317,937220332,937221348,937222364,937223379), timeout=60000, period=12000, currentTS=937224395, nChecks=3'
19:15.283000-0,EXCP,0,process=rphost,OSThread=72744,ClientID=193,Exception=NetDataExchangeException,Descr=Ping time out expired on connection
Речь идет о подключении рабочей станции к серверу? Была нарушена связь?
Или это что то другое?
Прикрепленные файлы:
плохо 10.19.zip
Подозреваю, что все же нашел.
Задал в тех. журнале - фиксировать все, что превышает заданный интервал времени.
Журнал во вложении.
И во время тормозов зафиксировал несколько SESN событий с ненормально большим временем исполнения.
38:59.382005-18394821005,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,p:processName=DebugQueryTargets,OSThread=64728,t:clientID=1745,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=zup3,Appl=1CV8C,Nmb=1,ID=69620513-ee71-41bb-ada9-703eeaa1b5eb
39:01.835005-145328979990,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=70648,t:clientID=968,t:applicationName=ServerProcess,t:computerName=server,Func=Attach,IB=MILK,Appl=1CV8,Nmb=44,ID=90f78d0d-7d8a-4210-9f5d-d1d8dc45f9ac
39:01.835006-145328979993,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=70648,t:clientID=968,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=MILK,Appl=1CV8,Nmb=44,ID=90f78d0d-7d8a-4210-9f5d-d1d8dc45f9ac
43:15.232019-27458392013,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=71512,t:clientID=1658,t:applicationName=ServerProcess,t:computerName=server,Func=Attach,IB=milk,Appl=1CV8,Nmb=59,ID=b256391a-6542-4269-825b-2d3331e54200
43:15.232020-27458392016,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=71512,t:clientID=1658,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=milk,Appl=1CV8,Nmb=59,ID=b256391a-6542-4269-825b-2d3331e54200
43:21.232010-188010,CONN,0,process=rmngr,OSThread=69300,t:clientID=1896,t:clientID=1896,t:computerName=exp2,t:applicationName=1CV8,t:connectID=0,Calls=6
Как бы это расшифровать. Или что еще надо в файле настроек, чтобы можно было понять - что это?
Задал в тех. журнале - фиксировать все, что превышает заданный интервал времени.
Журнал во вложении.
И во время тормозов зафиксировал несколько SESN событий с ненормально большим временем исполнения.
38:59.382005-18394821005,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,p:processName=DebugQueryTargets,OSThread=64728,t:clientID=1745,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=zup3,Appl=1CV8C,Nmb=1,ID=69620513-ee71-41bb-ada9-703eeaa1b5eb
39:01.835005-145328979990,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=70648,t:clientID=968,t:applicationName=ServerProcess,t:computerName=server,Func=Attach,IB=MILK,Appl=1CV8,Nmb=44,ID=90f78d0d-7d8a-4210-9f5d-d1d8dc45f9ac
39:01.835006-145328979993,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=70648,t:clientID=968,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=MILK,Appl=1CV8,Nmb=44,ID=90f78d0d-7d8a-4210-9f5d-d1d8dc45f9ac
43:15.232019-27458392013,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=71512,t:clientID=1658,t:applicationName=ServerProcess,t:computerName=server,Func=Attach,IB=milk,Appl=1CV8,Nmb=59,ID=b256391a-6542-4269-825b-2d3331e54200
43:15.232020-27458392016,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=71512,t:clientID=1658,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=milk,Appl=1CV8,Nmb=59,ID=b256391a-6542-4269-825b-2d3331e54200
43:21.232010-188010,CONN,0,process=rmngr,OSThread=69300,t:clientID=1896,t:clientID=1896,t:computerName=exp2,t:applicationName=1CV8,t:connectID=0,Calls=6
Как бы это расшифровать. Или что еще надо в файле настроек, чтобы можно было понять - что это?
Прикрепленные файлы:
Плохо 15.39.zip
Чего криминального может быть в фрагменте лога транзакция из вложения для пользователя Титова Надежда?
Время между 15.39 и 15.44
Время между 15.39 и 15.44
Прикрепленные файлы:
18111915.log
Я не уверен, что поступаю правильно, но решил закрыть эту тему и создать новую.
Здесь я несколько намусорил
Здесь я несколько намусорил
Прикрепленные файлы:
TJLogs.zip
TechLog1C.exe
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот