en to ja translation catalogue (17 entries)

note: type: Title ==
en: Measuring block device performance
ja: ブロックデバイスのパフォーマンス測定

note: type: Title ===
en: Measuring throughput
ja: スループットの測定

note: type: Plain text
en: When measuring the impact of using DRBD on a system's I/O throughput, the _absolute_ throughput the system is capable of is of little relevance. What is much more interesting is the _relative_ impact DRBD has on I/O performance. Thus it is always necessary to measure I/O throughput both with and without DRBD.
ja: DRBDを使用することによるシステムのI/Oスループットへの影響を測定する際には、スループットの _絶対値_ はほとんど意味がありません。必要なのは、DRBDがI/Oパフォーマンスに及ぼす _相対的_ な影響です。したがって、I/Oスループットを測定する際には、必ずDRBDがある場合とない場合の両方を測定する必要があります。

note: type: Plain text
en: The tests described in this section are intrusive; they overwrite data and bring DRBD devices out of sync. It is thus vital that you perform them only on scratch volumes which can be discarded after testing has completed.
ja: ここで説明するテストは過激なものです。データが上書きされるため、DRBDデバイスの同期が失われます。そのためこのテストは、テストが完了したら破棄できるスクラッチボリュームで行ってください。

note: type: Plain text
en: I/O throughput estimation works by writing significantly large chunks of data to a block device, and measuring the amount of time the system took to complete the write operation. This can be easily done using a fairly ubiquitous utility, `dd`, whose reasonably recent versions include a built-in throughput estimation.
ja: I/Oスループットを見積もるには、比較的大きなデータチャンクをブロックデバイスに書き込み、システムが書き込み操作を完了するまでの時間を測定します。これは一般的なユーティリティである `dd` を使用して簡単に測定できます。比較的新しいバージョンにはスループット見積もり機能が組み込まれています。

note: type: Plain text
en: A simple ``dd``-based throughput benchmark, assuming you have a scratch resource named `test`, which is currently connected and in the secondary role on both nodes, is one like the following:
ja: 簡単な `dd` ベースのスループットベンチマークは、たとえば次のようになります。ここでは、test という名前のスクラッチリソースが現在接続されており、両方のノードでセカンダリロールになっています。

note: type: Plain text
en: This test simply writes 512MiB of data to your DRBD device, and then to its backing device for comparison. Both tests are repeated 5 times each to allow for some statistical averaging. The relevant result is the throughput measurements generated by `dd`.
ja: このテストでは、512MのデータチャンクをDRBDデバイスに書き込み、次に比較のために下位デバイスに書き込みます。両方のテストをそれぞれ5回繰り返し、統計平均を求めます。この結果は `dd` が生成したスループット測定値です。

note: type: Plain text
en: For freshly enabled DRBD devices, it is normal to see slightly reduced performance on the first `dd` run. This is due to the Activity Log being "cold", and is no cause for concern.
ja: 新規に有効にしたDRBDデバイスの場合は、最初の `dd` 実行ではパフォーマンスがかなり低くなりますが、これは正常な状態です。アクティビティログがいわゆる「コールド」な状態のためで、問題はありません。

note: type: Plain text
en: See our <<ch-throughput>> chapter for some performance numbers.
ja: パフォーマンスの参考値については<<ch-throughput>>をご参照ください。

note: type: Title ===
en: Measuring latency
ja: レイテンシの測定

note: type: Plain text
en: Latency measurements have objectives completely different from throughput benchmarks: in I/O latency tests, one writes a very small chunk of data (ideally the smallest chunk of data that the system can deal with), and observes the time it takes to complete that write. The process is usually repeated several times to account for normal statistical fluctuations.
ja: レイテンシ測定はスループット測定とはまったく異なります。I/Oレイテンシテストでは非常に小さいデータチャンク(理想的にはシステムが処理可能な最も小さいデータチャンク)を書き込み、書き込みが完了するまでの時間を測定します。通常はこれを何度か繰り返して、通常の統計変動を相殺します。

note: type: Plain text
en: Just as throughput measurements, I/O latency measurements may be performed using the ubiquitous `dd` utility, albeit with different settings and an entirely different focus of observation.
ja: スループットの測定と同様に、I/O待ち時間の測定にも一般的な `dd` ユーティリティを使用できますが、異なる設定とまったく異なった測定を行います。

note: type: Plain text
en: Provided below is a simple ``dd``-based latency micro-benchmark, assuming you have a scratch resource named `test` which is currently connected and in the secondary role on both nodes:
ja: 以下は簡単な `dd` ベースの待ち時間のマイクロベンチマークです。ここでは、 `test` という名前のスクラッチリソースが現在接続されており、両方のノードでセカンダリロールになっています。

note: type: Plain text
en: This test writes 1,000 chunks with 4kiB each to your DRBD device, and then to its backing device for comparison. 4096 bytes is the smallest block size that a Linux system (on all architectures except s390), modern hard disks, and SSDs, are expected to handle.
ja: このテストでは、４kiBのデータチャンクをDRBDデバイスに1,000回書き込み、次に比較のために下位デバイスにも1000回書き込みます。4096バイトはLinuxシステム(s390以外のすべてのアーキテクチャ)が扱うことができる最小のブロックサイズです。

note: type: Plain text
en: It is important to understand that throughput measurements generated by `dd` are completely irrelevant for this test; what is important is the _time_ elapsed during the completion of said 1,000 writes. Dividing this time by 1,000 gives the average latency of a single block write.
ja: `dd` が生成するスループット測定はこのテストではまったく意味がなく、ここで重要なのは、1,000回の書き込みが完了するまでにかかった時間です。この時間を1,000で割ると、1つのセクタへの書き込みの平均待ち時間を求めることができます。

note: type: Plain text
en: This is the _worst-case_, in that it is single-threaded and does one write strictly after the one before, i.e. runs with an I/O-depth of 1. Please take a look at <<s-latency-iops>>.
ja: これは、シングルスレッドで厳密に１つずつ書き込みをしますので、最悪のケースではあります。つまり、I/O-depthが1の場合などです。<<s-latency-iops>>をご参照ください。

note: type: Plain text
en: Furthermore, see our <<ch-latency>> chapter for some typical performance values.
ja: 参考情報として<<ch-latency>>もご参照ください。
