Nsd Should Always Be Enabled?

  • Автор темы Klido
  • Дата начала
K

Klido

#1
DCT рекомендует вместе с "Domino community...", что
http://www-10.lotus.com/ldd/dominowiki.nsf...ways-be-enabled

Однако из всего предыдущего опыта, в частности, моего, как раз наоборот - до 7.0.3 включительно наблюдались капитальные тормоза при падении сервера и формировании отчетного файла. Это могло занимать даже не на нагруженных серверах более получаса и nsd приходилось убивать.
В связи с чем оптимальным кажется поставить авторестарт даже по-умолчанию раз 5 минуты за 3 и если сам поднимется - разбирать проблему, если нет - уже решать жестко. Однажды даже пришлось поставить бесконечный цикл, когда падал роутер и сервер на неизвестном письме в их большой куче - по крайней мере почта понемного разгр*цензура*ась и пользователям не ругалось про сервер постоянно.

Так что же лучше? :discard:
 

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 231
17
#2
Klido
лучше как по мне всегда знать причину падения и тем самым её исправлять
а выдать причину может только NSD
так что всё логично как по мне ;)
 
K

Klido

#3
ToxaRat
выдать причину может только NSD
шо за новость?? ;) мне за 15 лет в nsd 1 раз пришлось залезть и то в чисто познавательных целях. Может так совпало (хорошее железо, админы ос, прямые руки ;)), но ждать 30-90 минут завершения формирования nsd в условиях критичности простоя в 5 минут - явно не моё....

я к тому, что возможно nsd делает ещё что-то неявное но очень полезное (потому и неявное :)), что всё-таки надо его держать?
 

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 231
17
#4
Klido
так он вроде там весь дамп памяти разбирает, и указатели все сканерит
если сервер выжрал 4 гига, и баз у вас открыто порядко 400, и юзеров порядко 200 ему же всё это нужно запомнить, и потом сделать слепок
вот он и тупит
вы попробуйте пустой сервер уронить, там NSD за минуту отшуршит ;)
 

puks

Lotus team
03.02.2007
1 971
8
#6
Не совсем понятно, о чем спор.

Если вы внимательно читали о NSD, то должны были бы заметить, что данный товарищ имеет конфигурационный файл, где и указывается, что он будет делать и в каких случаях. Основную часть времени занимает создание дампа памяти. Однозначно, NSD должен быть включен, так как это единственный способ понять, почему сервер рухнул. В отчетном файле куча интересной и полезной информации. Иногда бывают ситуации, когда без дампа памяти не обойтись. Но NSD не единственное средство для его создания. Можно еще и userdump использовать, например. Просто удобно, когда все создается за один проход. Кроме того, nsd можно запускать и в ручную. К сожалению, IBM не публикует достаточно подробной информации об анализе NSD, которая есть только для внутреннего использования.

По поводу простоя сервера можно сказать следующее. Думаю, что у меня будет опыта побольше вашего общения с ОЧЕНЬ крупными забугорными компаниями. Так вот, те, кто пару лет назад не хотел ждать окончания создания отчетных файлов, после нескольких падений сервера и невозможности найти причину из-за неполноты данных, изменили настройки в пользу NSD и дампа памяти.
 
K

Klido

#7
изменили настройки в пользу NSD и дампа памяти
угу, а адинам подняли ЗП за предусмотрительность ;)

puks
так как это единственный способ понять, почему сервер рухнул
2-й раз повторяют это... ну все же в курсе, что 99% причин очевидны и без nsd... КМК единственно обоснованный случай (как раз тут верно - ручками сделать когда надо) - какое-то крутое приложение с внешними примочками...

те, кто пару лет назад не хотел ждать окончания создания отчетных файлов
неверный оттенок - не "не хотел", а "не могли позволить" ждать окончания отработки NSD. Надо админам разбираться - пусть разбираются, но не в ущерб остальным (бизнесу). Для этого и строятся запасные ветки, кластера и пр. А сейчас, наверное, кризис - могут и позволить подождать работу NSD :)

Я заострил внимание не о полезности NSD для диагностики, а о его "must be" включенным всегда ;)
 

Мыш

Премиум
12.02.2008
1 092
10
#8
У меня NSD включен везде, но практически ни разу мне это не помогло найти причину падения (плохое железо? ламеры ос? кривые руки?) :)))))

ЗЫ. Пару раз NSD пригодился , когда падал агент, вызывающий кривую DLL, написанную местными девелоперами... Но там по логам агента было, в общем-то, понятно, что это он. NSD просто подтвердил.

В принципе, полагаю, что NSD - как и DEBUG-параметры - юзать необязательно, если сервер стабилен, и начальство не возражает, что в случае чего не будет дампов. Вопрос политики, на самом деле.
 

puks

Lotus team
03.02.2007
1 971
8
#9
Не будем спорить на религиозные темы. Не надо обобщать свой локальный опыт крашей на другие компании. Для этого и существуют Best Practice. Я просто довожу до вашего сведения мой опыт анализа крешей в комплексных конфигурациях для разных забугорных контор. Я понимаю, что везде разная специфика. Практически все компании, с которыми приходится работать, в обязательном (!) порядке открывают case с IBM, чтобы узнать причину. При рухнувшем сервере и отсутствующем NSD любая попытка обратиться к IBM за помощью будет отфутболена. Совершенно не всегда причину крэша можно определить без NSD. Очень часто даже без дампа нельзя однозначно ее определить. Иногда приходится вручную делать несколько NSD и дампов памяти за день, если речь идет об утечке памяти.