Nsd Should Always Be Enabled?

[Klido]

DCT рекомендует вместе с "Domino community...", что

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

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

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

 

[ToxaRat]

Klido
лучше как по мне всегда знать причину падения и тем самым её исправлять
а выдать причину может только NSD
так что всё логично как по мне

 

[Klido]

ToxaRat

выдать причину может только NSD

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

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

 

[ToxaRat]

Klido
так он вроде там весь дамп памяти разбирает, и указатели все сканерит
если сервер выжрал 4 гига, и баз у вас открыто порядко 400, и юзеров порядко 200 ему же всё это нужно запомнить, и потом сделать слепок
вот он и тупит
вы попробуйте пустой сервер уронить, там NSD за минуту отшуршит

 

[Klido]

попробуйте пустой сервер уронить

ЗП тоже платить пустую будут? Попробуют и посмотрят как я шуршу?
Нет уж - пусть лучше пользователи шуршат, а не NSD

 

[puks]

Не совсем понятно, о чем спор.

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

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

 

[Klido]

изменили настройки в пользу NSD и дампа памяти

угу, а адинам подняли ЗП за предусмотрительность

puks

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

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

те, кто пару лет назад не хотел ждать окончания создания отчетных файлов

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

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

 

[Мыш]

У меня NSD включен везде, но практически ни разу мне это не помогло найти причину падения (плохое железо? ламеры ос? кривые руки?) ))))

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

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

 

[puks]

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