web-dev-qa-db-ja.com

iostat-dm-0デバイスはsdXよりもはるかに高いレイテンシを示します

Vmware vsphere 5.5上でLinux（Centos 5.x）VMを実行しています。 iostat、特にawait列を使用してディスクの待ち時間を監視していますが、デバイスマッパー/ LVMとLVMをサポートする「物理」ディスクの奇妙な結果に気づいています。

以下は、かなりアクティブなVMの1つでのiostat -x5からの出力の1セットです。問題のVMには2つのディスクがあります。1つのパーティションが/ bootであるsdaと、sdb2に/があるメインディスクとしてのsdbです。 iostatはsdb2デバイス（私のvolgroup/dm-0をサポートする唯一のデバイス/パーティション）の待機に約20〜40ミリ秒の遅延を示しますが、dm-0のiostatは100+ミリ秒の待機を示します。

私の質問は、システムが実際に見ている待ち時間に関して、ここで「正しい」統計はどれかということです。 「物理」ディスクsdbで約20ミリ秒が表示されているのでしょうか、それとも、LVMが関与するときに発生するアライメントなどの問題が原因で、実際にdm-0から100ミリ秒以上が表示されているのでしょうか。統計がかなり一致する場合もあれば、かなり離れている場合もあるため、奇妙です。たとえば、以下のiostat出力のブロックでは、sdb2は419書き込みIOPSを示し、dm-0は39k書き込みIOPSを示します。

avg-cpu:  %user   %Nice %system %iowait  %steal   %idle
           5.78    0.00    8.42   39.07    0.00   46.73

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb              15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2             15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
dm-0              0.00     0.00 761.33 39720.67 64120.00 317765.33     9.43  4933.92  121.88   0.02 100.07

更新：以下のGeneの回答のリンクを含め、さらに読みました。多くの変数（仮想化、ブロックファイルシステムなど）が関係していることは知っていますが、ベンダーとVMwareのベストプラクティスに従って、その部分はソートされているように見え、パフォーマンスは実際には非常に優れています。ここでは、「VM内」の観点からこれを実際に見ています。

その点で、パーティションとLVMの配置に問題があると思います。

GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 2147483647s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End          Size         Type     File system  Flags
 1      63s       4192964s     4192902s     primary  linux-swap   boot
 2      4192965s  2097151999s  2092959035s  primary               lvm

~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sdb2
  VG Name               VolGroup00
  PV Size               998.00 GB / not usable 477.50 KB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              31936
  Free PE               0
  Allocated PE          31936
  PV UUID               tk873g-uSZA-JaWV-R8yD-swXg-lPvM-dgwPQv

アラインメントを読むと、開始セクターは8で割り切れるはずなので、標準の512bセクターサイズで4kbの境界にアラインメントします。 LVMをディスク全体に適用すると、LVMは自動的に整列できるように見えますが、最初にディスクを分割してから、つまり/ dev/sdb2パーティションをLVMが使用する物理デバイスにするため、私はその場合、オフセットを計算できるかどうかはわかりません。 http://linux.die.net/man/5/lvm.conf ごとに、パラメーターdata_alignment_offset_detection： "1に設定され、カーネルが物理ボリュームのsysfsでトポロジー情報を提供する場合、物理ボリュームの整列されたデータ領域の開始は、sysfsで公開されているalignment_offsetによってシフトされます。」これはCentos5であり、sysfsで公開されている情報はなく、Centos6以降のVMでのみ表示されるため、物理ボリューム上で正しく整列できない可能性があります。

このネットアップのホワイトペーパーはVMパーティションの配置 http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3747.pdf&cc= us 具体的には、29ページのセクション4.5に、LVMとの適切な位置合わせのためにVM）を適切に分割することについての良い情報があります。

これはこの動作を引き起こす可能性があるようですが、より多くの知識/経験を持つ人はそれを確認できますか？

linuxperformancemonitoring
3
Steve R.

仮想化が関係しているため、簡単な答えはありません。 LVMにブロックデバイスを提示する独自のドライバーを持つ仮想ゲストに提示されるブロックデバイスの上にあるファイルシステムの上に仮想ディスクがあります。それが必ずしもそのような大きな違いを引き起こすかどうかはわかりませんが、それは可能かもしれません。

それ以上...

LVMはオーバーヘッドを追加するため、違いがあります。 LVMとブロックデバイスが適切に調整されていない場合、それも要因となる可能性があります。

アラインメントは、このような設定でカバーできる単純な主題ではありません。私ができる最善のことは、いくつかのドキュメントを参照することです。おそらく、それらのドキュメントでさらに多くの回答が見つかるでしょう。

3
Gene