Посмотрела в логи - а там execution time limit exceeded by agent

[anna]

Добрый день
Есть много разных агентов, но, если проанализировать логи, то десяток раз за день возникает в логах такое сообщение, что агент не успевает выполниться - Execution time limit exceeded by Agent. В настройках сервера стоит 10 минут, что и так много, на мой взгляд.
Примечательно, что все эти агенты, вообще-то, выполняются часто, например, каждые 15 минут. А ошибки возникают спорадически.
Что порекомендует уважаемый all?

 

[alexas1]

Может есть агенты берущие инфу за пределами сервера нотус - подключение к SQL какому нибудь?

 

[lmike]

переписать на тасклеты

 

[oshmianski]

1. Рефакторинг кода проблемного агента
2. Журнализация

 

[anna]

1. Рефакторинг кода проблемного агента
2. Журнализация

так в том-то и дело, что это каждый раз разные агенты, которые обычно выполняются нормально.
[DOUBLEPOST=1443162744,1443162723][/DOUBLEPOST]

переписать на тасклеты

кто такое, почему не знаю
[DOUBLEPOST=1443162841][/DOUBLEPOST]

Может есть агенты берущие инфу за пределами сервера нотус - подключение к SQL какому нибудь?

нет, все свое в той же базе пережевывают

 

[oshmianski]

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

журнализация - малой кровью

 

[savl]

@anna, может он зацикливается где и в результате отпадает?
У нас было похожее, но там был неоптимальный код, документы обрабатывались несколько раз.
А вот если документов много, то лучше посмотреть, сколько можно обработать документов за 10 минут и делить по пачкам.
Если идет обработка коллекции, то можно обработать первые 1000 документов, при следующем запуске еще 1000 и тд
Если это возможно, конечно же.

И да, логи было бы хорошо иметь. банальный Print и анализ Log.nsf может дать ответ на вопрос. Можно еще в файл писать.

 

[lmike]

переписать на тасклеты

кто такое, почему не знаю

по странному совпадению сокращений

Ссылка скрыта от гостей

в смысле выбора направления а не диагноза

Ссылка скрыта от гостей

 

[lmike]

И да, логи было бы хорошо иметь. банальный Print и анализ Log.nsf может дать ответ на вопрос. Можно еще в файл писать.

выцеплять из логов муторно, а вот с файлом - надо буфера регулярно сбрасывать (переоткрывать стрим и т.п.)

 

[ToxaRat]

я бы ничего не делал - и так работает

 

[anna]

пятница такая пятница - написала обработку логов прямо в базе log, посмотрела на результат, покивала головой и забыла. А дизайн ночером обновился - и чего я такой тупой буратино - все мое поудалялось
В общем, итог такой - превышение по времени вообще не связано ни со времнем, ни с какими-то определенными агентами - совершенно случайно выпадает.
Может, это на серваке затык какой-нибудь с ос?

 

[ToxaRat]

пятница такая пятница - написала обработку логов прямо в базе log, посмотрела на результат, покивала головой и забыла. А дизайн ночером обновился - и чего я такой тупой буратино - все мое поудалялось
В общем, итог такой - превышение по времени вообще не связано ни со времнем, ни с какими-то определенными агентами - совершенно случайно выпадает.
Может, это на серваке затык какой-нибудь с ос?

ну да, вот просто так "затык"
попробую угадать db.search в обычное время успевает, а в необычное неа?

 

[anna]

ну да, вот просто так "затык"
попробую угадать db.search в обычное время успевает, а в необычное неа?

в смысле, если в этих агентах есть db.search, то иногда он не успевает? и что же это? занят индексатор?

 

[ToxaRat]

в смысле, если в этих агентах есть db.search, то иногда он не успевает? и что же это? занят индексатор?

хм..... есть у меня подозрение что db.search никак к индексатору не привязан

 

[anna]

хм..... есть у меня подозрение что db.search никак к индексатору не привязан

Окей, намек не понят. Так что не так - убирать db.search, или что сделать? Или есть какой-то способ до поиска определить, доступен ли индекс. Если что, именно search, а не ftsearch.

 

[ToxaRat]

как минимум перейти на лукапы

а так чтобы вообще по минималке - заменить стандартный таймаут агента 15 мин на 60

 

[oshmianski]

Никогда не доверял и не использовал search и ftsearch.

Search - всплывают в папяти блокировки базы (семафоры), что приводит к тормозам в работе с бд.
FTSearch - а как ему вообще можно доверять, если обновление этого индекса переодическое?

Всегда использую коллекции, полученные из представлений по ключу.

 

[VladSh]

@oshmianski,
Как Вы поищете, если надо искать в определённом диапазоне дат (причём полей с датами м.б. несколько) + ещё условия по другим полям, например по частям слов?

 

[oshmianski]

NotesDateRange, NotesDocumentCollection.*(Merge, Subtract, Intersect).
Как-то так.
Варианты могут быть разные, иногда действительно без search или ftsearch не обойтись, но это не отменяет мою не любовь к ним.

 

[lmike]

NotesDateRange, NotesDocumentCollection.*(Merge, Subtract, Intersect).
Как-то так.
Варианты могут быть разные, иногда действительно без search или ftsearch не обойтись, но это не отменяет мою не любовь к ним.

с этими интерсект... - я уже, здесь, упоминал - бился долго, пока не выкинул
оно, сцуко, нарушает сортировку (правильнее сказать - не соблюдает)
и если это важно - все "новомодные" ЛС докрутки использовать не получится