iHead

iHead
Рейтинг
137
Регистрация
25.04.2008
Интересы
Hosting (PHP, Bitrix), domains

обычно его отключают.

myhand:
Но Вы же писали, что пробовали? Или Вы имели в виду, что смотрели то же самое на фре с другим типом диска?
Ну а говорите, что с диском не связано...

Ну, во-первых, по той ссылке, что давали, про ERC люди уже писали, что во фре получают странный результат при чтении текущих значений. Во-вторых, по той же ссылке в тестах упоминались WD RE3, RE4.

В третьих вот вывод с еще с одной машины (там Seagate ST3250318AS)

smartctl 5.41 2011-06-09 r3365 [FreeBSD 7.4-RELEASE i386] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

SCT Error Recovery Control:
Read: 57345 (5734.5 seconds)
Write: 57345 (5734.5 seconds)
myhand:
Любопытно, а что показывает линуксячий вариант? Может там OFF и если включить эту штуку - ситуация и в BSD изменится?

А как еще Вы собираетесь получать уведомления от своего "мониторинга"? Если Вы не у офисе у компьютера.

Получать в этом случае весь спам от скриптов - Вы явно не захотите. Я гарантирую это.

к сожалению, нет ни возможности ни желания пробовать "линуксячий вариант".

все диски WD RE3 и RE4.

далее предлагаю не офтопить, ТС я посоветовал добавить 1 строчку в конфиг, ему, скорее всего, этого будет достаточно.

myhand:
smarttools самые свежие?
Будете тянуть себе все письма по GPRS только чтобы фильтровать по контенту?

Все это поможет, конечно. Покуда у Вас один сервер, а не несколько сотен или даже десятков. Если серверов несколько - подобные "счастливые отчеты" люди начинаю не замечать.
Я и не спорю. Просто - это крайне неудачный способ. Нормальная система оповещения - молчит, если все в порядке.

Ну, вот для примера

smartctl -l scterc /dev/ad10
smartctl 5.41 2011-06-09 r3365 [FreeBSD 7.2-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

SCT Error Recovery Control:
Read: 57345 (5734.5 seconds)
Write: 57345 (5734.5 seconds)

GPRS не пользуюсь.

myhand:

А нет возможности убедиться, что дело в "фряхе", а не в конкретной модели диска?

возможность есть. проверено. дело не в модели диска.

myhand:

Это не "мониторинг", а просто спам в почтовом ящике. По крайней мере, когда я последний раз смотрел на это чудо - оно отсылало репорты "усе в порядке" - ежедневно.

Вы приучитесь игнорировать такой "мониторинг" - вот и все. Subject - один и тот-же. Чтобы заметить проблему - нужно посмотреть письмо.

если взять за систему просматривать эти письма ежедневно (благо фильтровать в почтовом клиенте можно по-разному), то никакой проблемы нет. письмо содержит вывод команды gmirror status. этого вполне достаточно.

Bartz3:
Спасибо за ссылку, а за последние 3 страницы "срача" понял еще, что рейд нужно делать с мониторингом☝. Спасибо еще раз всем кто помог решыть вопрос, тема себя исчерпала.


спамьте на здоровье я ухожу:).

добавите в /etc/periodic.conf

строчку

daily_status_gmirror_enable="YES"

и будет у вас мониторинг ежедневный

netwind:
там же написано как. может тебе smartctl обновить?

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

SCT Error Recovery Control:
Read: 57345 (5734.5 seconds)
Write: 57345 (5734.5 seconds)
myhand:

Вы все слова в собственном-то посте поняли? В одном случае - имеем кучу отказов в обработке запросов. В другом - нет. Клиенты вообще такого рестарта не заметят, если MPM апача верно сконфигурирован.
myhand ничего подобного не утверждал. На время рестарта HUP или USR1 никак не влияет - и там и там перечитывается конфигурация полностью. Именно она определяет время рестарта.

Вам указывали на другое существенное различие.

PS: "myhand утверждал", что iHead читать не умеет. Теперь он сильно подозревает, что это неустранимый дефект изделия...

вот тут вы сказали:

Скажем так... На большом хостинге апачи рестартятся подольше: на порядок, а то и до минуты может дойти Вы просто таких еще пока не видели - маленький ишшо.

далее я устраняюсь из темы, ибо говорить больше не о чем.

Romka_Kharkov:
Я вот ссылку вашу почитал, что-то не пойму, вы это говорите потому что чилды поумирают? Это вся разница?

все чайлды все равно поумирают. что при HUP, что при USR1.

отличие ли в том, что при USR1 чайлды обработают свои последние запросы.

принципиальной разницы как рестартовать апач после ротации логов нет.

myhand утверждает, что в случае с HUP это может занимать до минуты. в чем я лично сомневаюсь.

Всего: 870