Проблема с FreeBsd - виснет...

Ну естествено я этот вопрос поставил перед ними. Разбираться в железе и искать чего там не так - они не стали, а просто предложили перейти на новое железо. На новый сервак с той же конфигурацией. Я согласился. Они вынули диски (у меня их 2 штуки, RAID 1) со старого сервака и перенесли на новый. После этого, через 3 дня после пререноса - уже 1 раз система зависла. После этого зависания я проделал вышеописанные манипуляции с MySQL и распределением памяти в системе. С тех пор пока, тьфу-тьфу, работает...

На мой взгляд, теоретически неправильно работающий сервис, например MySQL или какой-то другой - не должен влиять на стабильность системы. В случае-чего должен застопориться или зависнуть или упасть сервис, а система по идее должна работать. На практике, не знаю... Может неправильно сконфигурированный или перегруженый сервис стать причиной зависания системы?

Давайте сперва определимся, что считать зависанием. Если речь о потере связи с сервером, то это не обязательно значит зависание. Могла просто лечь сетевая подсистема, а завалить ее сервисы вполне могут. Но в этом случае, серв должен перегружаться с физической консоли, да и в логах это будет ярко светиться. Прибить же ядро сервис теоретически может, но на практике я такого никогда не встречал - для этого надо хорошо потрудиться. :)

Поэтому я и считаю первостепенно важным почитать сообщение системной консоли.

Вот здесь уточните пожалуйста, что вы имели ввиду:

1. "Правильно, так и будет" - Нормально сконфигурированная FreeBsd так и должна загружаться с руганью по кнопке Power (и в этом нет ничего странного)

2. "Правильно, так и будет" - у системы имеются проблемы и то что она ругается - это ее нормальное правильное поведение в данной ситуации (загрузка по кнопке Power). Нормально сконфигурированная система не должна ругаться.

Тут очевидно вас можно понять так: если система нормально перезагружается мягким способом (как я описал), то очевидно у нее причина не в ядре? С ядром похоже все нормально... Вы примерно так хотели, сказать?

Насчет зависания... В моем случае это:

а) Сервак не виден с браузера, к нему нет доступа по http

б) Не работает FTP, не работает почта

Насчет сообщений системной консоли... Вы несомненно правы, спасибо еще раз за этот совет. Впредь (если что), буду непременно требовать от дата-центра сообщения. Кстати, а в случае с Kernel Panic - это тоже может отразиться в консоли или нет?

Это все внешние сервисы. А вот есть ли пинг?

В случае паники - отразится обязательно.

Каюсь - не проверял, не пинговал ни разу. На будущее учту этот момент. Спасибо за дельный совет.

Спасибо, понятно.

crash туда пишет в незакрытые записи wtmp при след буте... а на wtmp вроде fsync делается и стартовая запись потеряться не может... но т.к. там в консоли никого не было, то и записей нет...

Откуда в стоечном дедике открытые консоли? Разве что случайно. :)

Сильно захотелось эксперимента. Можете описать воспроизводимые условия, для подтверждения полезности этого лога в случае крэша? Готов завалить пару сервов для подробного изучения вопроса. Как раз под рукой есть с 6.1. :)

а sshный ttyp уже консолью не считается?

ssh пользователь работал в консоли и своими действиями вызвал подвисание сервера

Такое зависание бывает когда сервер уходит в своп. Пусть когда сервер зависнет - поддержка глянет нет ли там чего-то подобного.