URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID4
Нить номер: 181
[ Назад ]

Исходное сообщение
"Уведомление о недоступности ресурса"

Отправлено Maxim Chirkov , 12-Май-05 13:34 
Из-за аппаратных проблем со SCSI контроллером, сайт opennet.ru был недоступен в c 22 часов 11 мая до 13 часов 12 мая.

В настоящее время работа ресурса полностью восстановлена. При обнаружении любых аномалий (я мог что-то пропустить и не проверить) в работе сайта просба сообщить об этом по адресу mc@tyumen.ru.


Содержание

Сообщения в этом обсуждении
"Уведомление о недоступности ресурса"
Отправлено unk , 17-Май-05 11:02 
Опять контроллер?

"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 17-Май-05 11:51 
>Опять контроллер?

Второй раз за неделю (с 2003 года работало без перебоев) глючит Adaptec 2940 Ultra2 SCSI adapter, на консоль кидает "Dump Card State" и система повисает, пинги есть, TCP соединения не устанавливаются.

Если мягко ребутнуть - пропадает один из 4 дисков, если выключить и
включить - поднимается нормально.

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

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

До этого иногда в логе всплывали "Dump Card State" SCSI контроллера, но
он ресетил себя и продолжал работу в нормальном режиме. Один раз после
мягкого ребута при обновлении системы, машина не загрузилась, встав на
этапе детекта дисков. Передергивание по питанию - помогло.

Ковыряю последний вздох системы:
May 16 21:19:17 opennet /kernel: opennet /kernel: ahc0:A:2: no active SCB for reconnecting target - issuing BUS DEVICE RESET
May 16 21:19:17 opennet /kernel: opennet /kernel: (da1:ahc0:0:2:0): SCB 0x5f - timed out
May 16 21:19:17 opennet /kernel: nread: 0, reqpage: 0, pindex: 31, pcount: 2
May 16 21:19:17 opennet /kernel: vm_fault: pager read error, pid 55507 (cleanup)
May 16 21:19:17 opennet /kernel: pid 55507 (cleanup), uid 0: exited on signal 11
May 16 21:19:17 opennet /kernel: (da1:ahc0:0:2:0): Invalidating pack
May 16 21:19:29 opennet last message repeated 7 times
May 16 21:19:29 opennet /kernel: vm_fault: pager read error, pid 55280 (postgres)
May 16 21:19:30 opennet /kernel: pid 55280 (postgres), uid 1005: exited on signal 11 (core dumped)
May 16 21:19:32 opennet /kernel: (da1:ahc0:0:2:0): Invalidating pack
May 16 21:19:34 opennet /kernel: pid 649 (postgres), uid 1005: exited on signal 6 (core dumped)

Вырисовывается интересная картина: ругается всегда на da1 (раньше тоже на нем вылетало) и идет ругань от VM  (возможно это обусловлено, тем что на da1 база postgresql, поэтому он и вылетает по sig11). Тесты через smarttools на da1 ошибок или проблем не находят.


"Уведомление о недоступности ресурса"
Отправлено lavr , 17-Май-05 12:25 
>>Опять контроллер?
>
>Второй раз за неделю (с 2003 года работало без перебоев) глючит Adaptec
>2940 Ultra2 SCSI adapter, на консоль кидает "Dump Card State" и
>система повисает, пинги есть, TCP соединения не устанавливаются.
>
>Если мягко ребутнуть - пропадает один из 4 дисков, если выключить и
>
>включить - поднимается нормально.
>
>Как показало сегодняшнее зависание - это не случаность, а что-то более
>серьезное. Сейчас попрошу посмотреть на предмет перегрева, запыленности и
>состояния шлейфов.
>
>Интересно, что виснет когда загруженность минимальна, вечером. Такое
>впечатление, что днем перегревается, а когда начинает остывать - падает.
>
>До этого иногда в логе всплывали "Dump Card State" SCSI контроллера, но
>
>он ресетил себя и продолжал работу в нормальном режиме. Один раз после
>
>мягкого ребута при обновлении системы, машина не загрузилась, встав на
>этапе детекта дисков. Передергивание по питанию - помогло.
>
>Ковыряю последний вздох системы:
>May 16 21:19:17 opennet /kernel: opennet /kernel: ahc0:A:2: no active SCB for
>reconnecting target - issuing BUS DEVICE RESET
>May 16 21:19:17 opennet /kernel: opennet /kernel: (da1:ahc0:0:2:0): SCB 0x5f - timed
>out
>May 16 21:19:17 opennet /kernel: nread: 0, reqpage: 0, pindex: 31, pcount:
>2
>May 16 21:19:17 opennet /kernel: vm_fault: pager read error, pid 55507 (cleanup)
>
>May 16 21:19:17 opennet /kernel: pid 55507 (cleanup), uid 0: exited on
>signal 11
>May 16 21:19:17 opennet /kernel: (da1:ahc0:0:2:0): Invalidating pack
>May 16 21:19:29 opennet last message repeated 7 times
>May 16 21:19:29 opennet /kernel: vm_fault: pager read error, pid 55280 (postgres)
>
>May 16 21:19:30 opennet /kernel: pid 55280 (postgres), uid 1005: exited on
>signal 11 (core dumped)
>May 16 21:19:32 opennet /kernel: (da1:ahc0:0:2:0): Invalidating pack
>May 16 21:19:34 opennet /kernel: pid 649 (postgres), uid 1005: exited on
>signal 6 (core dumped)
>
>Вырисовывается интересная картина: ругается всегда на da1 (раньше тоже на нем вылетало)
>и идет ругань от VM  (возможно это обусловлено, тем что
>на da1 база postgresql, поэтому он и вылетает по sig11). Тесты
>через smarttools на da1 ошибок или проблем не находят.

н-да..., в дополнение к переписке:

- проблема в винте da1 (хотя ты бы в логах ошибки увидел...)
- если проблема с винтом, тогда если swap на da1 то ошибки VM объясними
- ну про то что signal11 частенько память грешит ты и сам знаешь

Тут надо бы послушать есть звуки от диска, да... по хорошему взять бы память и диск на замену и после замены посмотреть РЕЗУЛЬТАТ, если
все повторятся - ВСЕ это можно отсечь и думать дальше...

Я тут интересные мысли вычитал Скота Лонга, он писал что такое бывает
в сочетании определенных старых firmware Adaptec'ов и firmware Seagate дисков. Но это сразу бы вылезло, а у тебя уже давно работает


"Уведомление о недоступности ресурса"
Отправлено unk , 17-Май-05 12:28 
>Я тут интересные мысли вычитал Скота Лонга, он писал что такое бывает
>
>в сочетании определенных старых firmware Adaptec'ов и firmware Seagate дисков. Но это
>сразу бы вылезло, а у тебя уже давно работает
Ссылку не дадите - я что-то позже 2002 не нашел ничего на эту тему...


"Уведомление о недоступности ресурса"
Отправлено lavr , 17-Май-05 17:36 
>>Я тут интересные мысли вычитал Скота Лонга, он писал что такое бывает
>>
>>в сочетании определенных старых firmware Adaptec'ов и firmware Seagate дисков. Но это
>>сразу бы вылезло, а у тебя уже давно работает
>Ссылку не дадите - я что-то позже 2002 не нашел ничего на
>эту тему...

не сохранял, мельком пролистывал, использовал расширенный поиск в группах:

http://groups.google.com/advanced_group_search?hl=ru

стогая строка: Dump Card State поиск в группе *freebsd*


"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 17-Май-05 13:43 
> -  проблема в винте da1 (хотя ты бы в логах ошибки увидел...)
>- если проблема с винтом, тогда если swap на da1 то ошибки
>VM объясними

Нет, swap на другом разделе.

>- ну про то что signal11 частенько память грешит ты и сам
>знаешь

По sig11 падают процессы интенсивно использующие отвалившийся da1 диск, одновременно пишется "vm_fault I/O read failure...I/O read failure". Думаю это следствие проблемы с da1, а не из-за памяти.

Меня больше беспокоит, что виснет во время относительно низкой нагрузки на систему, никаких пиков близко ко времени краха нет, запросы к da1 идут в очень щедящем режиме, по сравнению с дневным трафиком. Без этого очень хорошо вписывается предположение о перегреве, скорее всего da1 воткнут между da0 и da2 - на первом ftp, на втором контент сайта. Т.е. они da1 сверху и снизу поджаривают :-)


"Уведомление о недоступности ресурса"
Отправлено lavr , 17-Май-05 16:24 
>> -  проблема в винте da1 (хотя ты бы в логах ошибки увидел...)
>>- если проблема с винтом, тогда если swap на da1 то ошибки
>>VM объясними
>
> Нет, swap на другом разделе.
>
> >- ну про то что signal11 частенько память грешит ты и сам
> >знаешь
>
> По sig11 падают процессы интенсивно использующие отвалившийся da1 диск, одновременно пишется
>"vm_fault I/O read failure...I/O read failure". Думаю это следствие проблемы с
>da1, а не из-за памяти.

если отлетает, то да.

> Меня больше беспокоит, что виснет во время относительно низкой нагрузки на
>систему, никаких пиков близко ко времени краха нет, запросы к da1
>идут в очень щедящем режиме, по сравнению с дневным трафиком. Без
>этого очень хорошо вписывается предположение о перегреве, скорее всего da1 воткнут
>между da0 и da2 - на первом ftp, на втором контент
>сайта. Т.е. они da1 сверху и снизу поджаривают :-)

запросто. А adaptec одно или двух канальный?
Вобщем только смена диска может подсказать дальнейшее направление поиска
проблемы.


"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 18-Май-05 09:03 
>>"vm_fault I/O read failure...I/O read failure". Думаю это следствие проблемы с
>>da1, а не из-за памяти.
>
>если отлетает, то да.

Вчера вечером опять посыпалась в лог ругань на da1, сразу запустил smartools - температура 37%. В это время был пик запросов к postgresql, вынес базу на другой диск. Ночью опять ругань в лог, как раз во время перестроения индексов поисковой системы, которые на da1 хранятся.


>запросто. А adaptec одно или двух канальный?

Судя по логам - одно.


"Уведомление о недоступности ресурса"
Отправлено unk , 17-Май-05 12:26 
>Как показало сегодняшнее зависание - это не случаность, а что-то более
>серьезное. Сейчас попрошу посмотреть на предмет перегрева, запыленности и
>состояния шлейфов.
Скорее всего это оно. А с контроллером засада: посмотрел на pricr.ru нет таких уже...

"Уведомление о недоступности ресурса"
Отправлено surfer , 19-Май-05 16:28 
>До этого иногда в логе всплывали "Dump Card State" SCSI контроллера, но
>он ресетил себя и продолжал работу в нормальном режиме. Один раз после
>мягкого ребута при обновлении системы, машина не загрузилась, встав на
>этапе детекта дисков. Передергивание по питанию - помогло.

Скорее всего нужно менять диски. Попробуйте их проверить утилитой от Seagate:
http://www.seagate.com/support/seatools/seatoold_reg.html
Там есть версия в виде бутабельного ISO имиджа.


"Уведомление о недоступности ресурса"
Отправлено dimz , 17-Май-05 12:50 
>Из-за аппаратных проблем со SCSI контроллером, сайт opennet.ru был недоступен в c
>22 часов 11 мая до 13 часов 12 мая.
>
>В настоящее время работа ресурса полностью восстановлена. При обнаружении любых аномалий (я
>мог что-то пропустить и не проверить) в работе сайта просба сообщить
>об этом по адресу mc@tyumen.ru.


Вчера, 16 мая около восьми-девяти утра по киевскому и сегодня в то-же время www.opennet.ru снова не отвечал. Попытался послать письмо по адресу, указанному в постинге-не получилось :-( Почтовик выдал такую бяку:

<mc@tyumen.ru>: host mail.tyumen.ru[217.195.208.34] said: 550 Service
    unavailable; Client host [213.179.230.109] blocked using rbl.tyumen.ru;
    Network blocked by spam_auto_checker (in reply to RCPT TO command)>

Что это еще за фокус? Приходится общаться через форум.


"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 17-Май-05 13:58 
>    Network blocked by spam_auto_checker (in reply to RCPT TO command)>
> Что это еще за фокус?

У вас давно эта сетка ? Она у нас в черном списке сеток с особо высокой активностью спама. При занесении, робот по RIPE базе пропускает IP стран СНГ, похоже, что сетка в черный список попала из-за того, что раньше на ней dialup висел.



"Уведомление о недоступности ресурса"
Отправлено dimz , 17-Май-05 14:17 
>У вас давно эта сетка ? Она у нас в черном списке
>сеток с особо высокой активностью спама. При занесении, робот по RIPE
>базе пропускает IP стран СНГ, похоже, что сетка в черный список
>попала из-за того, что раньше на ней dialup висел.

У меня она с июля 2003 года. Насколько помню, этот сегмент раньше висел за какой-то буржуйской конторой. Потом его отдали в руки Укртелекома. Но мой ip нигде не светился со спамом-я сам спамеров постоянно баню :-) Тем более, у меня выделенка.


"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 17-Май-05 14:27 
>У меня она с июля 2003 года. Насколько помню, этот сегмент раньше
>висел за какой-то буржуйской конторой. Потом его отдали в руки Укртелекома.

Вот-вот, буржуи и залетели в блэклист. Не вы первые, незнаю почему, но "грязные" БУ сетки почему-то часто сплавляют на Украину.


"Уведомление о недоступности ресурса"
Отправлено dimz , 17-Май-05 14:40 
>Не вы первые, незнаю почему, но
>"грязные" БУ сетки почему-то часто сплавляют на Украину.


Мда, как говорится, все хорошее-детям! :-) И теперь мой ip там пожизненно будет висеть?


"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 17-Май-05 14:41 
>Мда, как говорится, все хорошее-детям! :-) И теперь мой ip там пожизненно
>будет висеть?

Нет конечно, сразу убрал его из блэклиста.


"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 19-Май-05 16:32 
Поменяли диск. В нем ли была проблема покажет время.

"Уведомление о недоступности ресурса"
Отправлено Maxim Chirkov , 23-Май-05 12:38 
>Поменяли диск. В нем ли была проблема покажет время.

Время показало - второй претендент на замену SCSI контроллер :-(

May 21 08:34:19 opennet /kernel: swap_pager: indefinite wait buffer: device: #da/0x20001, blkno: 352, size: 4096
May 21 08:35:34 opennet /kernel: SCB_LUN[0x0] SCB_TAG[0xff]
May 21 08:35:34 opennet /kernel: 21 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0xc7]:(TWIN_CHNLB)
May 21 08:35:34 opennet /kernel: SCB_LUN[0x0] SCB_TAG[0xff]
May 21 08:35:34 opennet /kernel: 22 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0xc7]:(TWIN_CHNLB)
May 21 08:35:34 opennet /kernel: SCB_LUN[0x0] SCB_TAG[0xff]
May 21 08:35:34 opennet /kernel: 23 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0xc7]:(TWIN_CHNLB)
May 21 08:35:34 opennet /kernel: SCB_LUN[0x0] SCB_TAG[0x25]
May 21 08:35:34 opennet /kernel: 24 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0xc7]:(TWIN_CHNLB)
.........
May 21 08:35:35 opennet /kernel: Pending list:
May 21 08:35:35 opennet /kernel: 27 SCB_CONTROL[0x62]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] SCB_LUN[0x0]
May 21 08:35:35 opennet /kernel: 127 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] SCB_LUN[0x0]
May 21 08:35:35 opennet /kernel: 18 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] SCB_LUN[0x0]
May 21 08:35:35 opennet /kernel: 15 SCB_CONTROL[0x62]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] SCB_LUN[0x0]

Насколько я понимаю, SCSIID 7 - это сам контроллер.