
私は VPS (VMware) 上で FreeBSD 10.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
ご意見、ヒント、アイデアなどありましたら、本当に本当に感謝いたします。
ありがとう!
答え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 に増やすことを試みます。