Помогите разобраться с проблемой!!!

[skoltogyan]

получается что-вы в аварийной ситуации ребутили только server7 ?
(у него uptime 12 дней )
а server6 в UP 221 день(его давно не ребутили)
так ?

[skoltogyan]

У вас сервисы, запущенные на server6 и server7 -одинаковые или разные .?
если одинаковые и примерно одинаково используются, тогда есть вариант причины :
*** server7 он в UP time 221 день и при этом в свопе
4989348
а общий размер свопа:
12590072
Иными словами в server7 использовано 39,6% свапа.
откуда-почему вопрос:

*** server6 он в UP time 12 дней и при этом в свопе
220672
а общий размер свопа:
2103292
Иными словами в server6 использовано 10% свапа
Если server6 ведет себя так-же, как server7(одинаковые сервисы работают и одинаково загружены), то есть шанс, шо у него использование свапа может стремится к цифре, как и у server7
4989348 ( и это при МАКСИМАЛЬНОМ РАЗМЕРЕ СВАПА 2103292 !!! в server6 !!! )
2103292 - специально написал в столбик.
Вот, возможно, отсюда и время от времени вы ребутите server6 (он перестает отвечать),
Как нечто в server6 пытается уйти в своп. своп запполняется под завязку(доступный размер свопа мпеньше чем на server7)
А вот на server7 место под своп большое и система там живет, позволяе себе сбросить в своп, как ей надо..

[BDmV]

на server7 (swap 220k, up 12) свопа. На нём у меня:
1. master реплика eDir
2. cifs
3. Файловая помойка
4. iManager

а server6 (swap 4989348, up 221)
1. DNS
2. GroupWise
3. MariaDB
4. Файловая урна

[skoltogyan]

IMHO - последить за тем как изменяется размер используемого свопа и не подходит-ли он к максимально выделеномму месту.

[Иван Левшин aka Ivan L.]

skoltogyan: размер свопа давно не является показателем каких-то проблем с сервером, современные ядра (боюсь соврать, но, по моему, с 3.х начиная) всегда используют своп для оптимизации использования ОЗУ. Сбрасывают туда неактивные страницы и все такое, т.е. наличие чего бы то ни было в свопе, равно как и его размер, сами по себе не являются показателем наличия проблемы.

Код: Выделить всё

There are two principle reasons that the existence of swap space is desirable. First, it expands the amount of memory a process may use. Virtual memory and swap space allows a large process to run even if the process is only partially resident. As “old” pages may be swapped out, the amount of memory addressed may easily exceed RAM as demand paging will ensure the pages are reloaded if necessary.

The casual reader1 may think that with a sufficient amount of memory, swap is unnecessary but this brings us to the second reason. A significant number of the pages referenced by a process early in its life may only be used for initialisation and then never used again. It is better to swap out those pages and create more disk buffers than leave them resident and unused.

Отсюда

Load average на серверах - крошечный, нагрузки там, почитай, что нет. Если проблема в свопировании, вероятнее всего и Load average будет сильно выше, чем то, что мы видим сейчас. Плюс чисто внешние атрибуты в виде жалоб пользователей на недоступность сервисов и всякое такое прочее.

Мои любимые запросы от заказчиков: "ой, у меня своп отличен от нуля!", "ой, у меня утилизация 100%!"

Отстаньте от свопа, в общем, не виноватый он ) И free -h - тоже сам по себе не показатель, а только один из источников информации при анализе проблемы. Нужен кусок /var/log/messages за момент, когда с eDirectory были проблемы, точнее и за этот момент, и за некоторое время до него - чтобы понять, что случилось и как оно развивалось. Я потому и посоветовал ndsrepair -E время от времени.

[skoltogyan]

Хорошо-бы еще смотреть, шо пишет tomcat в своем логе catalina.log