web-dev-qa-db-ja.com

FreeBSD VMwareおよびCAMステータス:SCSIステータスエラー

私はVPS(VMware)でFreeBSD10.1-RELEASE-p19を実行しています。

私のISPは急速なデータ増加を経験しており、これらのメッセージは1週間前にログに自然に表示され始めました。

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

サーバーがストレージとの接続を完全に失い、パニックに陥って再起動することがあります。これは、おそらく通常のジョブ(移行/バックアップ)によって、偶数時間ごとに発生することがよくあります。

ISPがストレージシステムを追加してストレージの負荷を軽減するまで、私は本当に何かを試してみたいと思っています。

私はこれを見つけましたが、情報にパッチを当てる/使用する方法がわかりません: 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エラー発生時の情報: enter image description here

どんな考え、ヒント、アイデアも本当に本当に本当にありがたいです。

ありがとう!

2
Alldo

VMWareを使用している場合、つまりmpt(4)は純粋に仮想である場合は、ICH10などのより単純なものに変更することをお勧めします。

それ以外の場合は、キューの長さを増減して、camcontrol tagsで遊ぶことをお勧めします。

別のドライバーを使用してディスクを再プロビジョニングすることを選択した場合は、SAS-> SATAコントローラーの変更により、デバイスの名前が変更される可能性があることに注意してください。おそらく/dev/daX/dev/adaXになります。したがって、zfsを使用しているか、ディスクラベルを介してディスクをマウントしていない限り、/etc/fstabを編集する必要があります。

gstatの出力については、おそらくFreeBSDでの仮想環境サポートの性質上、明らかに何か問題があります。 600%の負荷は意味がありません。これをFreeBSDBugzillaに報告することをお勧めします。

P.S.ディスクプロビジョニングコントローラのタイプを変更するためのアドバイスはまだ有効です。 P.P.S.または。または、mpt(4)のキューの長さを128または64にまで広げようとします。

1
drookie