Статус FreeBSD VMware и CAM: Ошибка статуса SCSI

Статус FreeBSD VMware и CAM: Ошибка статуса SCSI

Я использую FreeBSD 10.1-RELEASE-p19 на VPS (VMware).

У моего интернет-провайдера наблюдается быстрый рост объема данных, и эти сообщения начали спонтанно появляться в наших журналах неделю назад.

Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): SCSI status: Busy
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): Retrying command
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 00 03 f9 6c 22 00 00 40 00
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error

Иногда сервер полностью теряет связь с хранилищем, а затем паникует и перезапускается. Это часто происходит каждый четный час, предположительно из-за рутинной работы (миграция/резервное копирование).

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

Я нашел это, но не уверен, как исправить/использовать эту информацию: https://svnweb.freebsd.org/base?view=revision&revision=278111

Я также нашел это ( vfs.unmapped_buf_allowed=0), но не уверен, связано ли это как-то? https://www.freebsd.org/releases/10.1R/errata.html#open-issues

camcontrol tags da0 -v

(pass1:mpt0:0:0:0): dev_openings  127
(pass1:mpt0:0:0:0): dev_active    0
(pass1:mpt0:0:0:0): devq_openings 127
(pass1:mpt0:0:0:0): devq_queued   0
(pass1:mpt0:0:0:0): held          -1
(pass1:mpt0:0:0:0): mintags       2
(pass1:mpt0:0:0:0): maxtags       255

gstatинформация при возникновении ошибок: введите описание изображения здесь

Любые мысли, подсказки, идеи будут очень, очень, очень признательны.

Спасибо!

решение1

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

В противном случае я предлагаю вам поиграться с camcontrol tags, увеличивая или уменьшая длину очереди.

Если вы решите повторно подготовить диски с помощью другого драйвера, обратите внимание, что смена контроллера SAS на SATA может привести к изменению имени устройства, которое, скорее всего, /dev/daXстанет /dev/adaX, поэтому, если вы не используете zfs или не монтируете диски с помощью меток дисков, вам придется отредактировать /etc/fstab.

Что касается вашего gstatвывода - с ним явно что-то не так, возможно, в природе поддержки виртуальной среды во FreeBSD. Загрузка в 600% - это ерунда. Предлагаю вам сообщить об этом в FreeBSD Bugzilla.

PS Совет поменять тип контроллера подготовки диска все еще в силе. PPS Или. Или я бы попробовал уменьшить длину очереди mpt(4) до 128 или даже 64.

Связанный контент