[ОТВЕТИТЬ]
12.01.2016 17:27
john_the_ripper
 
На одной из баз, очень часто валится в ошибку расчет себестоимости, а точнее в запланированное для расчета время, без проблем осуществляется перенос, но дальнейшая попытка расчета сыпется. В админстративном модуле, в поле "результат последнего расчета" появляется сообщение "Расчёт 13.01.2016 0:00:10 завершён с ОШИБКОЙ". В alert.log, event logах, в логах супермага, по этому поводу абсолютная тишина. Что самое интересное, это если сразу после ошибки запустить вручную расчет себестоимости, он проходит без проблем. Как понять что не нравится расчету?

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

Версии ПО: win2008r2 x64, oracle 10.2.0.5, SM 1.031.2 SP4
12.01.2016 17:34
OlegON
 
Лучше бы оптимайзер не стопил, он в курсе, когда начинается расчет, потом по журналу хоть какая-то информация будет.
Из подозрений - винда. И, например, отвал внешнего линка по сети под нагрузкой. Попробуй, например, вдвое уменьшить количество потоков расчета. В виндожурнале еще можно посмотреть... При разрыве соединения со стороны клиента (т.е. по сети или на машине клиента) никаких сообщений в алертах не будет.
12.01.2016 21:32
Starter
 
Нечто похожее встречал в описаниях сервиспака 1 к версии 1.032.2
23.12.15 (№ 1890) SP № 1

Расчет товародвижения. Исправлено: ошибка "Расчет ПРЕРВАН на этапе: Обработка данных задачи расчета ТД" из-за удаления сессии расчета сервером приложений.
SMRepAdmin.dll, Sm.CtrlSvcPluginConst.dll, Sm.WatchDogSettings.dll, Sm.ControlService.exe, Sm.AppServer.exe

У нас такая проблема была на версии 1.032.1. может обновиться стоит ?
12.01.2016 21:44
OlegON
 
в 1.032.2 они эту багу и добавили, как я помню
13.01.2016 02:38
john_the_ripper
 
В логах винды тоже увы ничего нет. Расчет проводится на той же машине, где крутится сама БД. Разрыв линка из-за нагрузки маловероятен, т.к. в этот момент как таковой нагрузки то и нет, а в моменты обмена с той же 1ской, возникает куда большая нагрузка и ничего не валится, да и при ручном запуске расчета проблема не проявляет себя. Ошибка возникает именно при старте расчета в авто режиме, т.е. даже не на этапе его проведения, а при самом запуске. Тоже была мысль что апдейт вылечит болезнь, просто неприятно что полнейшая тишина в логах и приходится гадать на кофейной гуще, как угодить расчету) Думал может есть тайный вариант дебага
13.01.2016 07:27
OlegON
 
То, что на той же машине все происходит, сеть не исключает, поскольку сливается и заливается по сети.
Насчет нагрузки - это несколько подключений и несколько потоков на этом же сервере, где крутится БД, в которой так же появляются несколько потоков.
Места на диске хватает? При ручном расчете %TEMP% другой, наверное... А дебаг пока в голову не приходит, процедура по уродски сделана.
13.01.2016 08:59
john_the_ripper
 
Места на системном диске вагон(~90Гб), на остальных в разы больше. Сервер приложений даже специально запускал предварительно из под того же пользователя, из под которого делал ручной запуск расчета, что-бы переменные окружения были 100% одни и те же, соответственно %TEMP% тоже. Пробовал даже перезапускать сервер приложений за 10 минут до проведения расчета - эффекта не дает.
13.01.2016 09:04
OlegON
 
Несмотря на мое неприятие того, как это все сделано, я все же больше склонен отнести этот косяк к проблемам ОС.
Вариант - кривой %PATH%, где сначала идут клиентские либы? И все же попробуй уменьшить число потоков до 2, например?
13.01.2016 17:57
john_the_ripper
 
В %path% все красиво, сначала серверные либы, потом клиентские, ; в конце нет.
Кол-во потоков уменьшал, все равно валится.
Сначала пишет "Обработка задачи расчета ТД", потом "расчет артикулов 0 из 96318" и тут же вываливается в ошибку.
Убивает то что в настройках журнала сервера приложений ставил даже уровень логирования "детальный", но все равно полная тишина в логах.
13.01.2016 20:01
OlegON
 
А никакого другого софта на серваке нет? Антивирус там, невзначай? Домен? Может, в базе в этот момент все же кто-то есть?
Попробуй на 1:13 раньше расчет поставить?
14.01.2016 03:26
john_the_ripper
 
Да нет, только оракл и см. Антивируса нет. Машина в домене, но все варианты которые могли возникнуть с правами, уже исключил 20 раз. И один %TEMP% + %TMP% на всех юзеров давал, и все процессы оракл+см от одного юзера запущены с максимальными правами. Перед вчерашними экспериментами с потоками, специально перезагружал сервер, проверял что-бы не было никаких зависших сессий и т.д. Пробовал двигать время расчета позже, эффекта не давало. Раньше не ставил, т.к. расчет запускается с запасом в час, после закрытия магазина - могут не все смены успеть упасть я думаю.

Единственный момент, когда дважды очищал аналитическую базу, расчет запускался автоматом после без проблем, но один раз)
14.01.2016 07:40
OlegON
 
Давно период закрывал?
14.01.2016 08:42
john_the_ripper
 
Последний раз, ровно 10 дней назад. На выходных планирую ещё часть периода закрыть.
14.01.2016 08:59
OlegON
 
Нет ли такого, что падать начало практически сразу после закрытия?
14.01.2016 09:06
john_the_ripper
 
До закрытия периода мог запустить автоматически расчет, а мог и не запуститься, а вот после закрытия совсем перестал автоматически запускаться. Только после очистки базы, один раз запустился автоматически, а потом снова начал валиться в ошибку.
14.01.2016 09:22
OlegON
 
Оптимизатор точно работает круглосуточно? У меня был аналогичный случай у клиента, вылечил, но по большей части после того, как я его попросил не подпрыгивать с приседаниями и очистками, расчитать ТД и поставил МТ сразу после расчета.
14.01.2016 10:09
john_the_ripper
 
Сейчас MT проходит за несколько часов, до расчета ТД, но на время проведения расчета, я тушу optimizer
18.01.2016 02:51
john_the_ripper
 
Т.е. как я понял, у клиента все решилось постоянными прогонами оптимайзера? Или все таки еще были какие-то нюансы?
Я увеличил время проведения МТ, но эффекта пока никакого не дало.
18.01.2016 07:31
OlegON
 
В общем, еще раз опишу, закрыли период и возникла проблема, как у тебя, с той лишь разницей, что иногда и вручную не считалось.
На месте начали дергаться, очищали период и т.п. Что было сделано - переставили ребут от сразу перед расчетом на три часа раньше. МТ поставили после ТД (длина его не имеет значения, главное, чтобы отработал). Вечером посчитали руками и на этот день не считали автоматом, чтобы бот прошел в МТ по посчитанному.
21.01.2016 03:06
john_the_ripper
 
Поставил последний сервиспак, для имеющийся версии - 1.031.2 SP10. Уже третью ночь расчет стартует без проблем. Тьфу тьфу тьфу. Надеюсь это и было решением проблемы. Наблюдаю дальше
21.01.2016 09:39
john_the_ripper
 
Единственное что хотел ещё спросить - обратил внимание на то, что когда запускаешь ручками расчет, он проходит быстрее, в отличие от случая, когда он запускается автоматом. Кол-во потоков в обоих случаях одинаковое - 5. В чем может быть дело?
21.01.2016 09:40
OlegON
 
Приоритет приложений перед сервисами? Винда она такая винда... В данном случае больше зависит от сети и сервака, где считается.
21.01.2016 10:45
john_the_ripper
 
Приоритет стоит на "службах, работающих в фоновом режиме". Да вот в том то и дело, что в обоих случаях все проходит на одном и том же сервере. Авторежим - 3.5 часа, ручной около 2х Очень странное дело.
21.01.2016 12:12
OlegON
 
Может, случайность? Уж больно велика разница. Параллельно бекапы какие-нибудь или их копирование?
22.01.2016 02:41
john_the_ripper
 
Уже несколько раз замечал такой момент. Прошедшей ночью авторасчет снова сбойнул и пришлось запустить ручками: по итогу, расчет снова прошел значительно быстрее. Может какие-то факторы могут влиять не на сам расчет, а на загрузку данных через sqlldr.exe?

В обоих случаях(авто/ручном), расчет стартует в одно и то же время. Бэкапирование и другие задания, в этот период времени не проводятся.
22.01.2016 07:56
OlegON
 
Боюсь, что тут без детального исследования длины каждого этапа с мониторингом загрузки на каждом из них не обойтись.
Суть расчета - загрузка себе в %TEMP% и обсчет, заливка в базу. Хочешь сказать, что общее время изменяется за счет второго этапа? Там главное - сетка, нагрузка в базе, скорость чтения с диска, способность к записи дисков БД.
23.01.2016 22:24
bob
 
Базу не стопишь - стартуешь перед расчетом автоматом?
25.01.2016 05:34
john_the_ripper
 
Нет, но за час до расчета пробовал перезагружать сервер. Эффекта не дает, увы. Несколько дней после обновления автоматом посчиталось, теперь снова не хочет.
25.01.2016 11:13
OlegON
 
И на каких-то машинах работает, на каких-то нет? Журналы пусты, в алерте ничего на эту тему?
26.01.2016 05:38
john_the_ripper
 
Не работает на одной машине. На всех остальных базах, без проблем все считается. Прогнал скрипт от сервисапака вчера вечером, и ночью расчет без проблем стартанул автоматически. Подозреваю что он перекомпилировал какой-то пакет. Понять бы вот только какой и что его ломает.


Опции темы


Часовой пояс GMT +3, время: 18:50.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.