зависают инстансы намертво

[material]

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

 

[Deisler]

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

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

 

[oleg21621]

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

скрипты на сайтах могут быть одной из причин зависания инстансов?

 

[Deisler]

скрипты на сайтах могут быть одной из причин зависания инстансов?

Я такого не встречал.

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

 

[Sergodjan]

Начните диагностику с начала, а не с середины.

Наверное, имелась в виду не Диагностика, а Трассировка?

 

[Deisler]

Наверное, имелась в виду не Диагностика, а Трассировка?

Диагностику зависания надо начать с поиска кубика на котором останавливается проект. А для этого нужно включить трассировку. Вы правильно поняли. Спасибо

 

[material]

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

Трассировку нужно делать в один поток, верно? Иначе в файле лога будет серьезный хаос, как мне представляется, так как трассировка будет затрагивать и удачные выполнения проекта и найти потом зависший инстанс будет проблематично.

 

[Ахилес]

Трассировку нужно делать в один поток, верно? Иначе в файле лога будет серьезный хаос, как мне представляется, так как трассировка будет затрагивать и удачные выполнения проекта и найти потом зависший инстанс будет проблематично.

трассировка пишет данные для каждого потока в отдельный файл.
тем более есть офигенный анализатор. ознакомься https://zennolab.com/discussion/threads/analizator-trassirovki-shablona.89877/

 

[ArchiCpa]

Та же проблема как у автора. Как в итоге решили?

Не как) откатился еще тогда на зенку 5,9,9,1 там такой проблемы нету, ее и использую, есть еще 7 версия ее для других целей использую.

 

[Devostator]

Не как) откатился еще тогда на зенку 5,9,9,1 там такой проблемы нету, ее и использую, есть еще 7 версия ее для других целей использую.

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

 

[Deisler]

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

Так может быть надо уже включить трассировку и проанализировать свой шаблон ?

 

[material]

Включил трассировку, вижу пошло логирование, но как теперь сопоставить инстанс с txt файлом самого лога с трассировкой? У инстанса есть название, он же "Port", там +- 10-и значное число, а вот в папке с трассировкой txt файлы называются какими-то рандомными 2-3 значными числами.

Зависнет у меня инстанс и как мне понять, какой файл логирования за него отвечал? Может кто сталкивался с таким шифром и сможет помочь?

 

[Deisler]

Включил трассировку, вижу пошло логирование, но как теперь сопоставить инстанс с txt файлом самого лога с трассировкой? У инстанса есть название, он же "Port", там +- 10-и значное число, а вот в папке с трассировкой txt файлы называются какими-то рандомными 2-3 значными числами.

Зависнет у меня инстанс и как мне понять, какой файл логирования за него отвечал? Может кто сталкивался с таким шифром и сможет помочь?

Я при поиске какого-то зависания старался включать один поток именно для того что бы не путаться в файлах трассировки.
Сопоставления между названием файла трассировки и "Port" нету.

Если зависание происходит именно при включенном многопотоке - то дождитесь зависания. Откройте папку с трассировкой. Убедитесь что время обновления файлов трассировки не меняется (это как раз и будет говорить о том что потоки действительно зависли) и прервите руками один зависший поток. Файл трассировки в этот момент обновится. Таким образом вы сможете понять в какой именно файл записывал этот поток.


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


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

 

[material]

Я при поиске какого-то зависания старался включать один поток именно для того что бы не путаться в файлах трассировки.
Сопоставления между названием файла трассировки и "Port" нету.

Если зависание происходит именно при включенном многопотоке - то дождитесь зависания. Откройте папку с трассировкой. Убедитесь что время обновления файлов трассировки не меняется (это как раз и будет говорить о том что потоки действительно зависли) и прервите руками один зависший поток. Файл трассировки в этот момент обновится. Таким образом вы сможете понять в какой именно файл записывал этот поток.


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


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

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

 

[Devostator]

Так может быть надо уже включить трассировку и проанализировать свой шаблон ?

К счастью все таки удалось с помощью Sergodjan решить проблему. Сменили Zenno ID и проблема пропала.

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

 

[Ахилес]

Включил трассировку, вижу пошло логирование, но как теперь сопоставить инстанс с txt файлом самого лога с трассировкой? У инстанса есть название, он же "Port", там +- 10-и значное число, а вот в папке с трассировкой txt файлы называются какими-то рандомными 2-3 значными числами.

Зависнет у меня инстанс и как мне понять, какой файл логирования за него отвечал? Может кто сталкивался с таким шифром и сможет помочь?

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

и не забудь поставить аварийный выход на 5 минут, в настройках проекта. сможешь тогда визуально 300 000 увидеть в трассировке... ну или примерную цифирь.

 

[material]

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

и не забудь поставить аварийный выход на 5 минут, в настройках проекта. сможешь тогда визуально 300 000 увидеть в трассировке... ну или примерную цифирь.

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

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

Зачем сапоставлять порт инстанса с именем логом трассировки? Ответ по сути простой, увидели зависший инстанс, посмотрели его порт, например, 123456789, нашли файл в папке трассировки с именем 123456789.txt, открыли его, опустились в конец файла и мгновенно нашли причину всех проблем. В таком случае поиск проблемы занимает 3-5 секунд в зависимости от ловкости рук и реакции. Сейчас же, чтобы найти проблему, нужно зайти в общий файл логирования, который через 1-2 дня работы будет весить наверное несколько гигабайт и искать в нем не пойми что, и не пойми как... Нотепад ++ наверное справиться с открытием файла txt в 1-2 ГБ., но вот дальше уже наверное проблемы будут. Очень странное решение в любом случае, если мы говорим конкретно о поиске проблемы, именно по зависшему инстансу, когда мы видим его в ZP и видим его ID, то есть Port.

 

[material]

К счастью все таки удалось с помощью Sergodjan решить проблему. Сменили Zenno ID и проблема пропала.

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

Вот такая же и у меня проблема, зависания абсолютно рандомные и не поддаются логики, вплоть до банального экшена ожидания (Пауза). Возможно думаю из-за нагрузки превышеной на железо. Часто вижу 100% на процессоре, есть вероятность, что это может создавать такие вот проблемы.

 

[Devostator]

Вот такая же и у меня проблема, зависания абсолютно рандомные и не поддаются логики, вплоть до банального экшена ожидания (Пауза). Возможно думаю из-за нагрузки превышеной на железо. Часто вижу 100% на процессоре, есть вероятность, что это может создавать такие вот проблемы.

У меня к слову загрузка железа ~5% CP, 20% RAM, <10% диск, <10% канал, <20% GPU

 

[Ахилес]

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

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

Зачем сапоставлять порт инстанса с именем логом трассировки? Ответ по сути простой, увидели зависший инстанс, посмотрели его порт, например, 123456789, нашли файл в папке трассировки с именем 123456789.txt, открыли его, опустились в конец файла и мгновенно нашли причину всех проблем. В таком случае поиск проблемы занимает 3-5 секунд в зависимости от ловкости рук и реакции. Сейчас же, чтобы найти проблему, нужно зайти в общий файл логирования, который через 1-2 дня работы будет весить наверное несколько гигабайт и искать в нем не пойми что, и не пойми как... Нотепад ++ наверное справиться с открытием файла txt в 1-2 ГБ., но вот дальше уже наверное проблемы будут. Очень странное решение в любом случае, если мы говорим конкретно о поиске проблемы, именно по зависшему инстансу, когда мы видим его в ZP и видим его ID, то есть Port.

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

 

[material]

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

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

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

Как найти файл с логом, который соответствовал ID инстанса? CTRL + F - обычный поиск по ID инстанса и сразу же будет показан соответствующий файл, который можно открыть и мгновенно получить информацию о зависшем элементе, а не подключать какие-то ИИ и усложнять себе жизнь на ровном месте. Простая работа должна оставатсья простой, нет смысла ее усложнять. Мной был приведен пример, как за 3-5 секунд найти проблему, при зависании инстанса, если ваш метод занимает больше времени, значит он менее эффективный.

К тому же давайте подумает, что такое поток, в рамках выполнения проекта в многопоточном режиме? Зачем мы разделяем трассировку на потоки и присваиваем каждому потоку отдельный файл трассировки, чем потоки вообще отличаются друг от друга? Правильно ничем, так как они просто распараллеливают соответствующий проект. Их выполнение абсолютно идентично, и нет разницы собираешь ты информацию с потока #1 или с потока #6, если в проекте имеется проблема, то одинаково себя проявит, как на потоке #1, так и на потоке #6. Так какой тогда смысл в 6 файлах трассировки, если в рассматриваемом примере было 6 потоков в проекте?

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

 

[Ахилес]

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

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

Как найти файл с логом, который соответствовал ID инстанса? CTRL + F - обычный поиск по ID инстанса и сразу же будет показан соответствующий файл, который можно открыть и мгновенно получить информацию о зависшем элементе, а не подключать какие-то ИИ и усложнять себе жизнь на ровном месте. Простая работа должна оставатсья простой, нет смысла ее усложнять. Мной был приведен пример, как за 3-5 секунд найти проблему, при зависании инстанса, если ваш метод занимает больше времени, значит он менее эффективный.

К тому же давайте подумает, что такое поток, в рамках выполнения проекта в многопоточном режиме? Зачем мы разделяем трассировку на потоки и присваиваем каждому потоку отдельный файл трассировки, чем потоки вообще отличаются друг от друга? Правильно ничем, так как они просто распараллеливают соответствующий проект. Их выполнение абсолютно идентично, и нет разницы собираешь ты информацию с потока #1 или с потока #6, если в проекте имеется проблема, то одинаково себя проявит, как на потоке #1, так и на потоке #6. Так какой тогда смысл в 6 файлах трассировки, если в рассматриваемом примере было 6 потоков в проекте?

да я у себя быстрее нашел где что зависает, чем прочитал эту простыню

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

 

[material]

да я у себя быстрее нашел где что зависает, чем прочитал эту простыню

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

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

 

[Deisler]

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

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

 

[material]

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

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

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