Григорий Ненашев (все сообщения)

Цитата

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

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

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

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

Рекомендуется перезапускать службу каждый день.

У меня летело на таких параметрах:
sd_serverservice.exe -install "hp OpenView service desk 4.5 server" DEFAULT -XX:MaxNewSize=64M -XX:NewSize=64M -Xms768M -Xmx1024M -Djava.class.path="%SD_SERVERHOME%lib\classloader.jar" "-Duser.dir=%SD_SERVERHOME%\" -start com.hp.startup.Bootstrap -params com.hp.ifc.bus.AppServer -stop com.hp.startup.Bootstrap -method shutdown -params com.hp.ifc.bus.AppServer -current "%SD_SERVERHOME%\"


Параметры лучше на всех серверах держать одинаковыми.
-XX:MaxNewSize=64M -XX:NewSize=64M -Xms768M -Xmx1024M

Чтобы эти параметры применились, нужно либо в ручную править реестр, либо переустанавливать службу с выбранными параметрами, т.к. простое изменение не меняет их в реестре.

Я давно в линуксе не работал, но помню, что сделать это можно, нужно гуглить как эмулировать windows на unix.

Чисто с технической точки зрения задачу решить почти можно, но не полностью, чтобы разграничить видимость нужно использовать механизм папка.
Далее вешать логику на роль, что только данной роли видна та или иная папка, в шаблон почты и в шаблон регистрации указать данные папки, то есть развести по папкам направления.
Групповой правкой пройтись по всем объектам и покрасить новую папку, потом разделить роли, создать новую и для старой прописать папку, на которую покрасили.
А вот что касается нумерации тут будут одни проблемы, во первых это путаница, даже если постараться эту логику развести. Зависит от того как построена логика, если участвует почта на подтверждение или отклонение, т.к. нумерация одна для всей системы. Делать костыли в данной схеме плохая затея, потом все это не просто будет поддерживать.
Плюс для этого потребуется расширенный парсер почты, которого у вас точно нету. Потом руководители скажут, что должны быть другие шаблоны писем и ходить они должны с другого адреса, для этого тоже нужны костыли. Я бы посоветовал попробовать донести до руководителей, что данную логику сделать с технической точки зрения без вложений не возможно. Это требует анализ текущей логики, только потом думать как можно положить задачу на существующую логику.

Кстати, решение по переходу на IE 9 решается путем установки другого браузера, например хром.

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

Без костылей нет, как-то мы обсуждали это... где то была такая тема...