This is topic Тяжелый проект - не хватает ресурсов in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.
Добрый день! У нас на объекте возникла следующая проблема. Проект большой, "тяжело" переходит по экранам. Виснет. Через какое-то время, при переходе, скада вылетает без каких-либо системных сообщений, при этом среда исполнения остается висеть в задачах, перезапуск штатно невозможен, пока принудительно задача не будет снята. В логах при вылете записывается подобная ошибка (0016 00000032[14] Ст-я приема ГПХ:471). Удаляя для тестов "проблемный" экран, ошибка происходит со следующим и тд. Для работы используется trace mode 6.10.2 +патч. ОС Windows 10. Логи прилагаю: LOAD [0] 6103 Jan 19 2017{090819},RTM NT(5.1) 10:00:41 0000 00000000[0] 09.08.2019 10:00:41 0000 00000000[24835] Start 10:09:13 0016 00000032[14] Ст-я приема ГПХ:471 LOAD [0] 6103 Jan 19 2017{090819},RTM NT(5.1) 10:12:33 0000 00000000[0] 09.08.2019 10:12:33 0000 00000000[24835] Start 10:24:34 0016 00000032[14] Ст-я приема ГПХ:471 LOAD [0] 6103 Jan 19 2017{090819},RTM NT(5.1)
[ 15.10.2019, 16:30: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проблемы с графикой, судя по тексту ошибки и описанию. Может не хватать ресурсов системы, проверьте в диспетчере задач сколько процесс занимает Объектов USER и GDI, при работе проекта они меняются? Какая загрузка ОЗУ и процессора?
Если есть возможность, пришлите проект и папку узла проекта, сохраненную после "вылета" на почту техподдержки hotline@adastra.ru
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Veronika, материалы от Вас пока не получили. В тексте письма, пожалуйста, укажите ссылку на этот топик.
Posted by Veronika (Участник № / Member № 6965) on :
Проект и папку узла выслали Вам на почту. Что касается объектов User, то при переключении окон, значение меняется и не превышает 966, GDI- на самом "тяжелом" окне 3000. При этом Загрузка ОЗУ, при работающем процессе, не превышает 37%, процессора- 46%. Причем никаких пиковых колебаний в момент "вылета" не происходит.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Материалы получили, о результатах сообщим электронной почтой.
Posted by Veronika (Участник № / Member № 6965) on :
Добрый день! скажите, на какую почту вы высылаете результаты? До сих пор ничего никуда не пришло
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Здравствуйте, ответ высылается на почту, с которой был прислан запрос.
Что касается проекта, присланные логи обрываются, перед этим ошибок не зафиксировано. Проблема с падением не воспроизводится, проект запустили на долговременное тестирование, пока проблем, кроме действительно замедленной работы графики не выявлено. В ближайшее время направим электронной почтой рекомендации по оптимизации графической части.
Posted by Veronika (Участник № / Member № 6965) on :
Проект и не вылетит, если не переключать тяжелые графические окна. Ситуация случается именно во время переключения. Буду ждать ответа на почту, надеюсь, рекомендации действительно помогут оптимизировать графику. Спасибо
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Добрый день, тестирование запускалось со стресс-тестом, когда постоянно перебираются задействованные в проекте экраны.
Вам дан ответ почтой с описанием результатов, рекомендациями, дополнительными вопросами.
Posted by Veronika (Участник № / Member № 6965) on :
Уважаемая техподдержка! Обрабатываются ли Вами сообщения, посланные на электронную почту? Неделю назад я ответила на Ваше сообщение, присланное почтой. До сих пор никакого ответа не поступило. Проблема не связана с оборудованием, так как воспроизводится на разных компьютерах и операционных системах. Очень прошу помочь решить проблему Вашего приложения. Объект не может запуститься, пока бесконечно вылетает скада. Я понимаю, что у Вас много работы, но мы тоже платим Вам деньги в надежде на качественную продукцию и помощь в ее наладке.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Да, в присланных письмах были дополнительные сведения о данной проблеме, они были учтены. Присланный ранее проект с 29 августа под стрессом проработал корректно до текущего момента. в присланном позже проекте некоторые экраны оптимизированы, но все равно имеют большое количество динамизированных 3d-объектов. Рекомендуем графические объекты в ресурсах сделать на основе плоских ГЭ, т.к. дизайн от этого не сильно пострадает (например те же клапаны), на некоторых экранах остались объемные нединамизированные трубопроводы и объекты (например многоугольник - рамка) под ними. Проект сейчас тестируется, в т.ч. передан разработчикам для изучения. Мы будем благодарны, если Вы сможете отследить точный алгоритм воспроизведения проблемы. При каких условия можно воспроизвести проблему.
Posted by Alexander_ (Участник № / Member № 7778) on :
Здравствуйте, многострадальная Вероника и многоуважаемая техподдержка! Изучив данный пост, не мог не написать, ибо искренно сочувствую и сопереживаю всем участникам проблемы. Как не понаслышке знакомо мне и Ваше положение, Вероника, явившаяся жертвою неумолимых обстоятельств, и Ваше, глубоко чтимая техподдержка, вынужденная держать ответ за, в общем-то, не по Вашей вине происшедшее!.. да и собственно разработчиков я тоже понимаю, ведь, когда твое, кровное, не отрабатывает, ты всегда-то хотел как лучше. Особливо, конечно, хочется выказать поддержку Веронике, пожелать крепости и везения, ибо — истинно! — без везения в нашем деле никуда! ну, а какое это «дело», думаю, Вы сами не без сожаления сознаёте…
Но не мог я не написать еще и потому, что имел (да и имею сейчас) весьма похожую ситуацию и хотелось бы верить, что явленные мною сведения хоть чем, да помогут облегчить страдания тут собравшимся, а то и вовсе — выведут Trace Mode на чистую воду, но обо всем по порядку. ДокМРВ+, релиз 6.10.2., если патч, то лишь тот, что рекомендуют при установке. Проект тоже довольно большой, но, видимо, меньше, чем у Вас, Вероника, однако двух — двух с половиной секунд для перехода между экранов хватает при загрузке системы раза в полтора ниже. Имеется в проекте инструментарий по пользовательской работе с базой данных: интерфейс его сделан на отдельном шаблоне экрана. Напрямую (т.е. путем непосредственной передачи возмущения на вход канала вызова шаблона связи с СУБД) пользователь с этого экрана может инициировать два запроса на чтение в любое время независимо друг от друга. Запрос, связанный с одним из каналов, вызывает представление в SQL, чтобы получить которое, MS SQL Server приходится много считать и агрегировать, т.е. фактически запрос может выполняться очень долго. Другой запрос также вызывает представление, но структура его такова, что результат всегда получается быстро.
Из документации нам известно, что по умолчанию единоновременно МРВ выполняет «только один SQL запрос. Этот режим можно отменить с помощью ключа SQLMANY в файле TMcom_<ordinal>.cnf (см. Задание параметров работы мониторов)». Данный ключ прописан в командном файле узла RTM, откуда посылаются запросы, однако если во время выполнения одного из запросов пользователь инициирует другой, то — факт остается фактом — этот запрос будет поставлен на очередь и выполнится только по завершении предыдущего (где именно происходит распределение запросов во времени, в TM или в СУБД, мне, право, пока не известно). Проблема была в том, что, если, не дождавшись выполнения текущего запроса, пока другой висит на очереди, попытаться перейти на другой экран, — система столь же безнадежно терпела крах — висла и требовала принудительного завершения процесса. Интуитивным решением оказался перевод канала вызова шаблона связи с СУБД, отвечающего за длительный запрос, в поток IDLE (до того, как и остальные, он был в 1 CALC), после чего, инициировав два запроса, стало возможным спокойно покидать экран, возвращаться к нему или переходить на любые другие экраны.
Подчеркну, что структура указанных запросов простейшая — вызов представления: длительность же одного из запросов обеспечивается сложностью формирования оного представления (т.к. были проблемы с передачей сложного синтаксиса из ТМ). По отдельности все запросы всегда выполнялись «штатно». Без покидания экрана два одновременно запущенных запроса также выполнялись «штатно». Продолжительность выполнения, думаю, здесь не играет роли: просто физически воспроизвести попытку перехода на экран при одновременном исполнении двух запросов удается только, когда один из них длится хотя бы три секунды: так, проблему вижу именно в потоках. Кроме того, в проекте присутствует перенаправление архивируемых данных в СУБД (оно вроде как имеет независимый поток).
После обнаружения корня проблемы, все пользовательские каналы вызовов шаблонов связи с СУБД окончательно были переведены в цикл IDLE: таким образом, из оных каналов в CALC остался только @IDW.
Шло время, проект развивался, и теперь в нем появилось обращение к СУБД в момент первого запуска для инициализации кое-каких параметров. Потоки соответствующих каналов были уже IDLE, а выполнение запросов сразу после старта МРВ инициировала пользовательская программа. Поначалу функция работала, как и было запрограммировано. Затем какое-то время шлифовал программу, а также в попытке исключить «дыры» при перенаправлении архивных данных в СУБД — в IDLE перевел @IDW. Давеча откомпилировал, запустил на отладку — в итоге при попытке перехода на любой из экранов наблюдается крах системы (МРВ). Ушел на выходные в полном страхе и замешательстве. На днях новая версия проекта отправлена на производство, благо без этой, еще не отлаженной, функции обращения к СУБД при старте: @IDW там уже в IDLE, но вроде все работает нормально. Что делать? В чем проблема? Скоро потребуют сдачи нового проекта уже с этой функцией и программой — кому писать, куда звонить?
Если решите Вашу проблему, пожалуйста, отпишитeсь. Думаю, от нее не застрахован никто и полученные знания могли бы помочь другим пользователям еще до обращения к техподдержке.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Работа с СУБД в TRACE MODE одушевляется через ODBC-драйвер Windows. MPB не управляет транзакциями и не контролирует их, за целостность БД отвечает CУБД. Поэтому при выполнении большого количества запросов в общем цикле могут возникать проблемы. Перевод в другой поток действительно мог улучшить эту ситуацию. В общем же случае без необходимости не рекомендуем менять потоки и их приоритеты. Рекомендуем управлять запросами СУБД программно, контролируя отработку предыдущего запроса, организовать очередь.
Если крах системы происходит при переходе по экранам, проблема может заключаться не в запросах СУБД. Проблема может быть в несоответствии проекта релизу, в драйверах видеокарты, отсутствии свободной памяти или иных ресурсов системы.
Posted by Veronika (Участник № / Member № 6965) on :
Здравствуйте! Проект создавался в релизе 6,10,2, в таком же и запускается в среде исполнения. Что касается настоящей ситуации, скада проработала месяц, все было хорошо, и вылетела. С тех пор вылетает часто. Из наших действий: мы проверили все, что вы рекомендовали. Версии драйверов, directx установлен последней версии. Также купили более мощный компьютер добились загрузки ЦП на 16%. Проект облегчен насколько возможно(честно говоря, не думаю что это должно так работать). Сами падения происходят случайным образом при переходе по экранам в процессе прогрузки графических элементов, почти со всех. Тенденция такая, что чем менее мощный компьютер используется, тем стабильнее вылеты, вот и все что можно сказать. Самая большая проблема в том, что процесс остается висеть в фоновых диспетчера задач. Таким образом, даже команда TASKKILL не может его убрать. Причем такое чувство, что графическое отображение среды исполнения просто "свернулось", а процесс запущен, и ошибка-13 будет преследовать до тех пор, пока процесс не завершится принудительно снятием задачи. Видео, каким образом происходили вылеты было отправлено на почту. Последний проект также отправлю. Чтобы воспроизвести проблему используйте более слабый компьютер нажимая на кнопки перехода по экранам. Очень надеемся на Вашу помощь!
Posted by Veronika (Участник № / Member № 6965) on :
И еще хотелось бы добавить. Наша фирма давно работает с Trace Mode. Самая стабильная работа наблюдается на версии 6,08. На ней профайлер никогда не вылетает и если уж происходит непредвиденный сбой- никогда не застревает в фоновых процессах, на более новых релизах подобная проблема происходит регулярно (6,10 и 6,10,2). Уверена, что все наши проблемы решились бы, если бы можно было как-то проект "откатать" до версии 6,08. Если такое возможно с вашей помощью, мы были бы благодарны, так как сил воевать с этими вылетами больше нет.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Добрый день! Вы можете перейти на релиз 6.08, однако, мы считаем, что проблема не в этом. У Вас сложный проект, в нем есть ошибки, которые нужно найти и устранить. В сентябре мы проводили исследование Вашего проекта на стенде. Длительное время проект работал в режиме постоянных переходов по экранам и не было зафиксировано ни одного сбоя. Вероятно, в *.prj файле проблема не проявилось. В последнем письме Вы прислали только сам файл проекта *.prj. Выполните наши рекомендации, пришлите сразу после падения папку узла целиком с записанными логами. Иного выхода, как найти и устранить ошибка в проекте у нас нет. То, что проект работает месяц успешно и внезапно появилась проблема свидетельствует о том, что причина не в TRACE MODE, а в изменениях в окружении. Спустя месяц что-то произошло, что стало вызывать нестабильность работы ПО на ПК. Например, установка или попытки установки обновлений ОС, изменения в доступе к системным ресурсам; изменение настроек антивируса, брандмауэра, других программ; дефрагментация диска, проблемы с сетью и т.д. С этим надо разбираться.
Posted by Veronika (Участник № / Member № 6965) on :
Спасибо за ответ. Я выслала Вам на почту файл компиляции после вылета с файлом диагностики внутри, также последний проект. Проект не вылетал месяц скорее из-за того, что его никто не трогал, так как испытания на время заморолизись. Очень надеемся на Вашу помощь так как сил уже нет. Объект не сдается из-за постоянных вылетов. Если проблема все же в проекте, помогите ее найти, пожалуйста
Posted by Veronika (Участник № / Member № 6965) on :
Добрый день! Скажите, дошло ли до вас письмо с узлом проекта?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В последнем письме только сам файл проекта, дошлите папку узла с диагностической информацией.
Posted by Veronika (Участник № / Member № 6965) on :
Я же все выслала, архивом
Posted by Veronika (Участник № / Member № 6965) on :
![[prey / молящийся]](graemlins/prey.gif)