私は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
どんな考え、ヒント、アイデアも本当に本当に本当にありがたいです。
ありがとう!
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にまで広げようとします。