Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Публикация № 1142048 22.10.19

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

Performance Monitor Windows Server 2016 rphost расследование проблем

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

При расследовании проблем производительности в информационных системах на платформе 1С часто приходится проверять не выполнялся ли в момент жалоб пользователей на "зависания" и медленную работу перезапуск рабочих процессов в кластере 1С, т.к. "при аварийном завершении рабочего процесса, кластер серверов запускает новый рабочий процесс. Затем выполняется попытка перенести все клиентские сеансы, которые обслуживал завершившийся рабочий процесс, на новый рабочий процесс. Это приводит к тому, что пользователи могут наблюдать существенные паузы в работе: клиентское приложение перестает реагировать на пользовательские команды, создается ощущение, что клиентское приложение «зависло»." (https://its.1c.ru/db/v8316doc#bookmark:cs:TI000000259). Один из способов это определить - это посмотреть на график использования рабочим процессом памяти (Частный рабочий набор) в байтах. 

И в Perfmon Windows часто приходится видеть такого вида графики:

Почему зелёный график имеет такую форму? Наш основной rphost вдруг освободил чуть ли не всю память, а затем продолжил работать как ни в чём не бывало? 

Спойлер, для ищущих быстрое решение
 
 

Предлагаю рассмотреть этот вопрос подробнее и график, соответственно, поближе.

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

Итак:

Жили-были agent-папа, mngr-мама и сын их rphost и был у него PID 10428. И был rphost одинок.

Как-то сожрали мама с сыном лишних 164 с небольшим мегабайт оперативной памяти и решил папа, что предел его 5-тиминутному терпению лопнул и решил он сына остановить:

28:22.387011-0,ATTN,1,process=ragent,OSThread=11908,Descr=Temporary allowed memory limit exceeded for server,ServerID=7d61e944-8c4f-456b-94c9-46ebeb290d6b,HostName=m1.app.nodeN.domain.local,TotalMemory(Kb)=25165300,TempAllowedProcessesMemory(Kb)=15625000,TempAllowedTimeLimit=300,ExcessStartTime=20191010092321,ExcessDuration(sec)=301,ProcessList[pid, mem(Kb)]='[10428, 14720016], [8296, 1073628]'

28:22.387015-0,ATTN,1,process=ragent,OSThread=11908,Descr=Process exceeded temporary allowed memory limit and would be stopped,agentURL=tcp://m1.app.nodeN.domain.local:1540,procURL=tcp://m1.app.nodeN.domain.local:1560,Pid=10428,Name=rphost

 

Предварительно сделал папа нового сына rphost и присвоила матрица ОСь ему PID 13532, а Performance Monitor окрестил его rphost#1:

28:23.887000-93986,PROC,0,process=ragent,OSThread=4632,Txt='Run process from user. Prog=C:\Program Files\1cv8\8.3.15.1534\bin\rphost.exe, Command=("C:\Program Files\1cv8\8.3.15.1534\bin\rphost.exe" -range 1560:1591 -reghost m1.app.nodeN.domain.local -regport 1541 -pid 354eb8ed-587c-4d61-9e3a-642223f84145 -fromsrvc), Domain=DOMAIN, User=USER, logon success, win API loaded, ProfilePath=C:\Users\USER, user profile loaded, user environment loaded, success, pid=13532'

 

и перестал старший rphost быть одинок пока через полторы минуты не помер, послав на прощание всем своим клиентам ошибку:

30:02.263020-0,PROC,0,process=rphost,OSThread=6296,Txt=Process terminated. Any clients finished with error.

30:02.263022-0,PROC,0,process=rphost,OSThread=6296,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.15.1534) Working Process terminated.

30:02.709019-0,ATTN,1,process=ragent,OSThread=11908,Descr=Process is abandoned,agentURL=tcp://m1.app.nodeN.domain.local:1540,procURL=tcp://m1.app.nodeN.domain.local:1560,Pid=10428,Name=rphost

30:02.709021-0,EXCP,0,process=ragent,OSThread=13496,Exception="GetExitCodeProcess('10428',10428)",Descr=process exited

30:02.709022-0,ATTN,0,process=ragent,OSThread=13496,Descr=Process terminated,agentURL=tcp://m1.app.nodeN.domain.local:1540,procURL=tcp://m1.app.nodeN.domain.local:1560,Pid=10428,Name=rphost

 

Тогда Performance Monitor сделал rphost#1 старшим и переименовал его в rphost.

И жил rphost с PID 13532 счастливо, пока в 14:28:26 не умер из-за сбоя в матрице OSException.

28:26.071000-0,EXCP,0,process=rphost,p:processName=RHostRoot,OSThread=16660,OSException=rphost_8.3.15.1534_0b127ca0_20191010142826_13532 enabled external

Пока умерший rphost с PID 13532 пытался оставить после себя хоть что-то:

28:26.071003-0,EXCP,0,process=rphost,p:processName=RHostRoot,OSThread=16660,DumpError=DirBin property is empty

Папа сделал ещё одного сына rphost и присвоила матрица ему PID 17064, а Performance Monitor дал ему имя в мониторинге rphost#1:

28:31.368000-77985,PROC,0,process=ragent,OSThread=4632,Txt='Run process from user. Prog=C:\Program Files\1cv8\8.3.15.1534\bin\rphost.exe, Command=("C:\Program Files\1cv8\8.3.15.1534\bin\rphost.exe" -range 1560:1591 -reghost m1.app.nodeN.domain.local -regport 1541 -pid 354eb8ed-587c-4d61-9e3a-642223f84145 -fromsrvc), Domain=DOMAIN, User=USER, logon success, win API loaded, ProfilePath=C:\Users\USER, user profile loaded, user environment loaded, success, pid=17064'

Затем папа понял что старший сын таки потерян:

28:36.446034-0,ATTN,1,process=ragent,OSThread=11908,Descr=Process is abandoned,agentURL=tcp://m1.app.nodeN.domain.local:1540,procURL=tcp://m1.app.nodeN.domain.local:1561,Pid=13532,Name=rphost

И после второго запроса решил, что потерян давно и совсем:

28:46.477031-0,ATTN,0,process=ragent,OSThread=2872,Descr=Process is abandoned long enough,agentURL=tcp://m1.app.nodeN.domain.local:1540,procURL=tcp://m1.app.nodeN.domain.local:1561,Pid=13532,Name=rphost,expirationTimeout=100,abandonedTimestamp=-946632333

И решил его добить:

28:46.477032-0,ATTN,0,process=ragent,OSThread=2872,Descr=Process will be killed,agentURL=tcp://m1.app.nodeN.domain.local:1540,procURL=tcp://m1.app.nodeN.domain.local:1561,Pid=13532,Name=rphost,logOnly=0,createDump=1

Оставив на память его скальп:

28:46.477033-0,EXCP,0,process=ragent,OSThread=2872,OSException=rphost_8.3.15.1534_00000000_20191010142846_13532 enabled external

30:48.614008-0,EXCP,0,process=ragent,OSThread=2872,DumpError=Created dump file: C:\КаталогСервера\Dumps\rphost_8.3.15.1534_00000000_20191010142846_13532.mdmp

 

В таких случаях при довольно частых опросах (pingTimeout=5000, pingPeriod=1000) папы жив ли сын, сын при обжорстве частенько не успевает оставить после себя полноценный скальп (дамп) со смещением отличным от 00000000 и скальп (типа rphost_8.3.15.1534_0b127ca0_20191010142826_13532) может оказаться недописанным.

 

Это была присказка, а теперь сказка.

 

 Сколько rphostoв перезапустилось в 14:51 судя по данным графика ниже?

Папа версии 8.3.15.1534 очень плодовит. Причём настройки скопления 1С, предполагающие что ему не нужно иметь более одного потомка в один момент времени, ему не указ.

 

Судя по книге жизни, rphost с PID 17064, родившийся в 14:28:31.368, прожил недолго. До 14:51:08 того же дня. Потому что папа-agent наклепал других rphost, они вместе съели всю разрешённую им папой память и даже чуть больше. За что наш 17064-й и поплатился жизнью, так как съел больше остальных, ибо был старшим, и папа решил его остановить:

51:02.422010-0,ATTN,1,process=ragent,OSThread=11908,Descr=Temporary allowed memory limit exceeded for server,ServerID=7d61e944-8c4f-456b-94c9-46ebeb290d6b,HostName=m1.app.nodeN.domain.local,TotalMemory(Kb)=25165300,TempAllowedProcessesMemory(Kb)=15625000,TempAllowedTimeLimit=300,ExcessStartTime=20191010144426,ExcessDuration(sec)=396,ProcessList[pid, mem(Kb)]='[17064, 6640356], [17060, 4938764], [13780, 2529248], [8296, 1077264], [14188, 688396]'

51:02.422014-0,ATTN,1,process=ragent,OSThread=11908,Descr=Process exceeded temporary allowed memory limit and would be stopped,agentURL=tcp://m1.app.nodeN.domain.local:1540,procURL=tcp://m1.app.nodeN.domain.local:1560,Pid=17064,Name=rphost

Мемуары 17064-го оканчиваются такими же строками как и у его предшественника:

51:08.751012-0,PROC,0,process=rphost,OSThread=11960,Txt=Process terminated. Any clients finished with error.

51:08.751013-0,PROC,0,process=rphost,OSThread=11960,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.15.1534) Working Process terminated.

 

Таким образом зелёная линия должна была упереться в землю где-то в точке между 14:50:30 и 14:52:00.

 

А младшие братья были благополучно переименованы Performance Monitor'ом: rphost#1 в rphost, rphost#2 в rphost#1, rphost#3 в rphost#2. В связи с чем и получаем такие весёлые картинки.

 

Поэтому глядя на подобные графики Performance Monitor мы должны видеть следующее (отредактировано в MS Paint):

Эх, не хватает нам в Performance Monitor’е привязки к ID процесса.

 

Мораль сей басни такова: не стоит обольщаться графиками подобными первому, думая, что наш основной rphost вдруг освободил чуть ли не всю память, а затем продолжил работать как ни в чём не бывало!

Это, как говорится, уже совсем другой rphost

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Evil Beaver 7830 22.10.19 10:49 Сейчас в теме
Статья норм. Единственное, что думать об "освобождении памяти" точно никогда не стоит. Резкий прыг вниз почти всегда означает смерть rphost, собственно ответ на главный вопрос статьи "а что случилось на графике" понятен сразу. А расследование "книги жизни" - интересное. Пишите еще.
ikalmykia; students; ershz; Созинов; vihrov_av; EugeneSemyonov; +6 Ответить
2. EugeneSemyonov 22 22.10.19 16:38 Сейчас в теме
(1) Андрей, спасибо Вам за поддержку!
3. nordoil 23.10.19 10:46 Сейчас в теме
Попробуйте сделать настройку на сервере, чтобы процессы в Performance Monitor’е именовались не по умолчанию rphost, rphost#1, rphost#2, ...., а с PID-ами процессов, вида rphost_17064, rphost_13532, ...., как описано в https://infostart.ru/public/966270/. Тогда возможно все станет яснее.
triviumfan; dvsidelnikov; +2 Ответить
5. EugeneSemyonov 22 23.10.19 17:34 Сейчас в теме
(3) Сергей, спасибо, за подсказку! Добавил указанную Вами публикацию в избранное. Обсужу с коллегами возможность внедрения данной настройки с учётом замечания.
11. VKislitsin 877 19.12.19 19:41 Сейчас в теме
(5)
Евгений, это я публиковал заметку про настройку. Настройка работает на всех моих проектах уже несколько лет.
Проверил, действительно, на сайте MS ссылка теперь выдает 404-ю страницу. Причем все внутренние ссылки у них же так же ведут на прежние расположения. Очень многое не удается найти. Возможно всё-таки поправят или перенесут. Пока я не нашел у Microsoft нового расположения этой статьи KB.
Мир для чего-то бросился перекраивать свои десятилетиями наработанные сайты... Вот и 1С не устояла. На v8.1c.ru тоже теперь половину не найти из того что было.

Веб-архив еще помнит эту страницу:
http://web.archive.org/web/20190420052123/https://support.microsoft.com/en-us/help/281884/the-process-object-in-performance-monitor-can-display-process-ids-pids
4. Gilev.Vyacheslav 1903 23.10.19 14:34 Сейчас в теме
про производительность из заголовка можно убрать, скорее это "про потребление ресурсов, падения, перезапуски и стабильность"
а вообще графики очень познавательно периодически изучать - иногда rphost отрывается от агента и живет своей жизнью и сразу не сообразишь где проблема
6. EugeneSemyonov 22 23.10.19 17:55 Сейчас в теме
(4) Доброго дня, Вячеслав! Спасибо за комментарий и замечание, подумаю как лучше поправить заголовок, но 1С пока не исправила ситуацию с производительностью в момент перезапуска рабочих процессов и пишет об этом открыто в документации к версии для ознакомлении 8.3.16, в которой предлагается использовать резервирование рабочих процессов для уменьшения проявлений "тормозов" клиентских приложений в момент перезапуска рабочих процессов в кластере.
7. Gilev.Vyacheslav 1903 23.10.19 21:39 Сейчас в теме
(6) ну вот с выдержкой из документации этот комментарий в начале статьи и воткните, так хотя бы будет понятна взаимосвязь
8. Созинов 25.10.19 09:30 Сейчас в теме
Отличная статья! Интересная подача, достаточно хорошо разжевали и не скучно было. Пишите еще!
9. EugeneSemyonov 22 26.10.19 20:56 Сейчас в теме
(8) Спасибо, Сергей! Думаю, у меня найдётся интересный материал ещё для парочки публикаций.
10. user846987 29.10.19 19:40 Сейчас в теме
Было занимательно ) пишите еще.
Оставьте свое сообщение

См. также

Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С

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

1С работает с СУБД Postgres более 10 лет, а сейчас это единственный легальный вариант для инсталляций в России. Много ли мы потеряем в производительности по сравнению с MS SQL? Выдержит ли Postgres 15.2 жесткий Highload со стороны 1С? Цель этой статьи - ответить на данные вопросы, с цифрами, которые можно использовать при расчете архитектуры.

23.03.2023    1012    1CUnlimited    8    

16

Delayed durability поможет вашему ORM увеличить производительность на 50% и более, если Вы только будете использовать …

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

ORM (Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли, что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С, и ORM на Java, и наверняка в других ORM. В предыдущих частях показана глубина проблемы. В этой части предложено решение со стороны СУБД (MS SQL, Oracle, Postgres).

13.02.2023    503    1CUnlimited    0    

9

Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД

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

ORM (Object Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений приводит к мысли, что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM. В предыдущей части статьи были изложены результаты теста, в этой статье ответы на самые часто задаваемые вопросы и новый тест.

01.02.2023    498    1CUnlimited    5    

1

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

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

Избавиться от скана таблицы в плане запроса

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

Для запросов, содержащих "LIKE %СтрокаПоиска%". Справедливо для MS SQL и Postgres.

20.12.2022    2821    vasilev2015    31    

23

Концепция ORM как двигатель прогресса - выдержит ли ее ваша СУБД?

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

ORM (Object-Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С, и ORM на Java, и наверняка в других ORM. Причины приоткрывает данная статья.

16.12.2022    1170    1CUnlimited    5    

9

Нагрузочное тестирование в 1С:ERP

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

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

02.11.2022    3573    Tavalik    23    

32

Тормоза при записи номенклатуры в ERP 2.5.8.287

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

Обратил внимание на медленную работу при пакетной записи элементов номенклатуры.

25.10.2022    740    m191    6    

5

Как я Java учил, а потом 1С-у удивлялся

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

Сравнение производительности 1С с Java.

23.09.2022    2539    Hadgehogs    23    

3

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

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

3 500 рублей

Партицированная дисциплина программиста в 1С

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

Почему при росте объемов базы 1С все становится медленней, даже если все индексы правильно сделаны? В статье на простом примере с регистром сведений показана причина и как этого избежать. Кто виноват больше, 1С или MS SQL решать Вам :)

20.09.2022    1859    1CUnlimited    2    

6

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

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

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

29.08.2022    5915    Chernazem    44    

106

Workaround me в 1С/MS SQL и не только, системный подход к созданию костылей

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

Workaround свидетельствует о невозможности решить проблему "правильным путем" и вызывает чувство стыда. Но практика показывает, что способность решать проблемы через workaround является порой единственным способом решить проблему в разумное время. А победителей, как говорят, не судят, так почему бы не создавать workaround по системе?

15.08.2022    1245    1CUnlimited    0    

6

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

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

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

10.08.2022    5040    sapervodichka    60    

73

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

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

от 11 рублей

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

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

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

05.08.2022    1652    1CUnlimited    0    

14

Методика похудения для 1С – 100%

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

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

28.07.2022    5638    1CUnlimited    37    

43

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

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

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

11.07.2022    5400    it-expertise    27    

56

Производительный режим работы 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    7581    Neti    7    

88

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

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

Любовь. Быстродействие. 1С

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

Несколько эпизодов на общую тему, собранные за последние полгода. Первый вариант, будет исправляться и дополняться.

26.05.2022    3971    vasilev2015    20    

34

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

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

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

24.05.2022    4046    avolsed    15    

33

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

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

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    2258    it-expertise    19    

23

Тестирование - игровое моделирование

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

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1542    ivanov660    0    

15

Работа с 1С:Аналитика Промо

Онлайн-курс предусматривает изучение возможностей системы “1С:Аналитика”, которая работает как составная часть платформы “1С:Предприятие” и обеспечивает оперативный просмотр и анализ необходимых данных.

4500 рублей

Несколько слов про платформенный механизм оптимизации RLS

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

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3673    ivanov660    23    

69

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

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

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

05.04.2022    5193    DBOdin_Lab    33    

29

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

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

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    5568    it-expertise    92    

67

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

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

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    4044    it-expertise    48    

30

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

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

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

28.02.2022    12736    ivanov660    18    

145

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

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

Ускорение работы конфигуратора 1С с большими прикладными решениями

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

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    7214    stg2005    105    

40

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

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

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

06.12.2021    1778    Rokky78    6    

12

Повышение производительности веб-сервисов. Переиспользование сеансов

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

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    4591    sorter1    3    

47

Оптимизация проведения документов списания партий в УПП 1.3

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

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    1428    info1i    5    

8

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

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

Адекватный параллелизм в 1С

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

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    14008    Shmell    8    

55

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

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

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

02.08.2021    15767    ivanov660    77    

139

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

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

Решение проблемы с заглавными буквами в power shell, поиск русского имени счетчика по английскому, и еще кое-что.

02.08.2021    1332    unichkin    4    

7

Parameter sniffing и генерация планов для разработчиков 1С

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

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    15253    vasilev2015    17    

35

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

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

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

28.04.2021    8182    vasilev2015    14    

84