Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

Мёртвое зависание СД

Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти

Страницы: 1 2 След.
Мёртвое зависание СД
Привет!
Что случилось
В последнее время спокойно жить не даёт одна очень неприятная проблема.
Начались глухие зависания при работе в СД. Никаких ошибок не возникает, просто при любом действии клиент виснет и уже не оживает. Если закрыть СД и попробовать запустить заново, то так же виснет на запуске, не выдавая никаких ошибок — ни ошибок подключения к серверу, ни ошибок Явы, ничего.

Что проверял
В логах прикладного сервера чисто. Никаких ошибок приложений или системы — ничего. Нагрузки на процессор или оперативку нет. Оракловая база лежит на другом сервере, с ней тоже всё нормально, никаких аномальных нагрузок, напрямую база доступна для подключения.

Что делаю
Я перезапускаю службу сд-шного сервера или перезагружаю сам сервак, зависание проходит,всё работает нормально, письма приходят, заявки регистрируются, но через 5-10 минут всё повторяется снова. При этом, если в момент зависания открыть лог, там будет одна и та же запись в конце:
Sat, 19/11/2016 13:28:15 <SMTP> Started parsing E-mail

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

После 10-20 перезагрузки службы проблема может просто пропасть сама собой и не проявляться ещё неделю или месяц, затем всё начинается по-новой.

HP OVSD 4.5 SP39, никаких бекапов, профилактических работ и т. п. ни с базой, ни с сервером в момент зависаний не проводится, закономерностей появления проблемы не выявлено.

Пожалуйста, подскажите, куда смотреть, что проверить?
Рисунок
sd.jpg (204.14 КБ) [ Скачать ]
Рисунок
log.jpg (327.18 КБ) [ Скачать ]
Переустановил на серваке Яву с 1.7 до последней 1.8, переустановил службы HPOVSD сервера и агента. Посмотрю, исправит ли это ситуацию.
Обнаружил косяк.
Установка версии явы выше 1.7 (пробовал все доступные на сайте Оракл 1.8) приводят к тому, что письма из Лотуса в СД попадают со сбитой кодировкой. В логе ошибка:

<SMTPERROR> Converter class not useable (sun.io.CharToByteKOI8_R)
Continuing without characterset conversion. A probable cause is a non-internationalized Java Virtual Machine

Откатился снова на jdk-7u79, заявки из писем регистрируются нормально.
Изменено: ASKarabanov - 20.11.2016 11:53:28
Сегодня утром снова зависло smile:(
А что говорит анализ работы БД?
Цитата
Григорий Ненашев пишет:
А что говорит анализ работы БД?

Оракловый админ говорит, что с базой полный порядок. даже в момент зависания СД. Не верить ему нет причин.
Чудес не бывает, в момент зависания нужно смотреть на открытые транзакции.
Еще вопрос, как часто установлен перезапуск системы?
Какой UP-Time серверов?
Добавлялись ли сторонние индексы на базу?

После чего приблизительно начались проблемы, что обновилось в инфраструктуре или в логике, что ни-будь менялось до подобных зависаний, или это постоянная проблема?
В логах самой системы есть какие ни будь ошибки?
Цитата
Григорий Ненашев пишет:
Чудес не бывает, в момент зависания нужно смотреть на открытые транзакции.

Еще вопрос, как часто установлен перезапуск системы?

Какой UP-Time серверов?

Добавлялись ли сторонние индексы на базу?



После чего приблизительно начались проблемы, что обновилось в инфраструктуре или в логике, что ни-будь менялось до подобных зависаний, или это постоянная проблема?

В логах самой системы есть какие ни будь ошибки?


Прикладной сервер перезагружается раз в неделю.

Индексы в базу не добавлялись точно.

В логах вообще нет следов каких-либо ошибок. Только начало парсинга письма перед каждым зависанием (я там выше скрин прикладывал).

Я не могу чётко сопоставить начало зависаний с какими-то работами. За последние 4 месяца я довольно сильно лопатил СД. Например, открыл регистрацию заявок по мэйлу для всех отправителей, а не только для зарегистрированных в системе. Менял форму окна самой заявки, добавлял новые поля, менял логику имэйл команд, добавлял DB и UI правила. Однако, после всех этих изменений система какое-то время работала нормально (за исключением известной проблемы с генерацией множества сессий после изменений формы заявки).

Но после того, как я переустановил на сервере яву и службу сервера HPOVSD, СД зависло пока только один раз несколько недель назад и с той поры ведёт себя спокойно. Вроде бы.
Цитата
ASKarabanov пишет:
Прикладной сервер перезагружается раз в неделю.

Индексы в базу не добавлялись точно.

В логах вообще нет следов каких-либо ошибок. Только начало парсинга письма перед каждым зависанием (я там выше скрин прикладывал).

Я не могу чётко сопоставить начало зависаний с какими-то работами. За последние 4 месяца я довольно сильно лопатил СД. Например, открыл регистрацию заявок по мэйлу для всех отправителей, а не только для зарегистрированных в системе. Менял форму окна самой заявки, добавлял новые поля, менял логику имэйл команд, добавлял DB и UI правила. Однако, после всех этих изменений система какое-то время работала нормально (за исключением известной проблемы с генерацией множества сессий после изменений формы заявки).

Но после того, как я переустановил на сервере яву и службу сервера HPOVSD, СД зависло пока только один раз несколько недель назад и с той поры ведёт себя спокойно. Вроде бы.


Понятно, у нас это называется отыскать точку изменения, как одно из решений могу посоветовать поставить систему на детализированный визуальный мониторинг.
Если проблема еще остается актуально, контролировать лучше Online, SQL, APP, прикладную архитектуру.
Перезапуск служб системы нужно поставить на ежедневный перезапуск, один раз в сутки. Сам Up-time сервера можно постепенно увеличить, доведя время до одного месяца.

По блоку изменений могу сказать в общем, мы применяем практику внесения изменений через блок «Изменения», каждое изменение архитектуры, правил, форм, вносится точка изменения. Сейчас планируем постепенно прийти к точке пакетных изменений, собирать изменения за неделю и обновлять продуктивный сервер один раз в неделю (пакетом).

Еще в практику мы сделали свой мониторинг системы, берется чистая БД, берется лог файл, из него берем проблемные точки, и записываем их в базу. Далее берем highcharts и стром живой график нагрузки системы или выводим ошибки, блокировки, кол.лицензий. И в момент сбоя смотрим в графиках на все ключевые показатели системы. Тогда выявить проблему становиться гораздо легче, скажем утечка памяти сразу будет видна в графике. Либо иная проблема, в любом случае визуально контролировать сервера проще, т.к. всегда можно отмотать все показатели на проблемное время.
Цитата
Григорий Ненашев пишет:
Цитата
ASKarabanov пишет:

Прикладной сервер перезагружается раз в неделю.



Индексы в базу не добавлялись точно.



В логах вообще нет следов каких-либо ошибок. Только начало парсинга письма перед каждым зависанием (я там выше скрин прикладывал).



Я не могу чётко сопоставить начало зависаний с какими-то работами. За последние 4 месяца я довольно сильно лопатил СД. Например, открыл регистрацию заявок по мэйлу для всех отправителей, а не только для зарегистрированных в системе. Менял форму окна самой заявки, добавлял новые поля, менял логику имэйл команд, добавлял DB и UI правила. Однако, после всех этих изменений система какое-то время работала нормально (за исключением известной проблемы с генерацией множества сессий после изменений формы заявки).



Но после того, как я переустановил на сервере яву и службу сервера HPOVSD, СД зависло пока только один раз несколько недель назад и с той поры ведёт себя спокойно. Вроде бы.




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

Если проблема еще остается актуально, контролировать лучше Online, SQL, APP, прикладную архитектуру.

Перезапуск служб системы нужно поставить на ежедневный перезапуск, один раз в сутки. Сам Up-time сервера можно постепенно увеличить, доведя время до одного месяца.



По блоку изменений могу сказать в общем, мы применяем практику внесения изменений через блок «Изменения», каждое изменение архитектуры, правил, форм, вносится точка изменения. Сейчас планируем постепенно прийти к точке пакетных изменений, собирать изменения за неделю и обновлять продуктивный сервер один раз в неделю (пакетом).



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


Всё очень сложно smile:)
«могу посоветовать поставить систему на детализированный визуальный мониторинг.» — подскажи, пожалуйста, чем лучше мониторить?

А нас снова прокатили с покупкой нового СД, так что остаюсь с HP ещё на год точно.
Изменено: ASKarabanov - 21.12.2016 09:58:16
Страницы: 1 2 След.
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)

Сегодня были (гостей: 44, пользователей: 0, из них скрытых: 0)