新宿区で働くプロジェクトマネージャーのブログ

新宿区で働くプロジェクトマネージャーのブログ

AmazonWebService実践入門を読んで実践する「その１：I/Oの高速化」続き２

「その１：I/Oの高速化」の結果検証

前回のブログに記載した結果が、検証前仮説と異なる結果になったため、詳細に検証・分析してみたいと思います。

ログの内容を見比べる

  • bw(帯域幅)が、IO1(プロビジョンドIOPS）の場合だけ、1/5ぐらい低い。

f:id:utan1999:20160228221524p:plain

  • 4タイプ（Sequential-Read、Sequential-Writes、Random-Read、Random -Writes）の帯域幅を合計した値で ストレージタイプごとのbw（帯域幅）を見るとよくわかる。

f:id:utan1999:20160228221913p:plain

ボトルネックを解消する

* 帯域幅がボトルネックになっているときは、EBS最適化オプションを使うことを「AmazonWebService実践入門」ではおすすめしていた。

EBS最適化オプションを使う。

  • EBS最適化オプションとは…EC2インスタンスとEBSボリュームはネットワークを介して接続されているが、そのネットワークはEBSへのアクセス以外のアクセスにも利用されている。そのネットワーク帯域を占有して、EBSへのアクセスを最大化するためのオプションがEBS最適化オプションである。

EBS最適化オプションを適用する。

f:id:utan1999:20160228230539p:plain

  • ②次に出てきたモーダルウィンドウでEBS最適化にチェックの入っているインスタンスタイプを選択する。

f:id:utan1999:20160228230604p:plain

※EBS最適化オプションが利用できるインスタンスタイプは限られている。詳細は、こちらへ

※また、EBS最適化オプションを適用する方法は、こちらの公式ページにも掲載されています。

  • ③一応平等を期するため、マグネティック・汎用SSD（GP2）もインスタンスタイプを『m4.large』にし、EBS最適化オプションもオンにしました。

再計測

  • インスタンスの状態を『m4.large』＋「EBS最適化オプションをオン」にして、再計測しました。

  • 結果：まったく変わらず。

  • HDDにおいては、エラーになり、ログ記録が全くされていない。

  • 汎用SSDは、Read、Randreadしか記録されない。という状態。

ORZ

うーん。何がいけないのか。。。もう一度再考が必要。

計測方法の再考

本に書かれているベンチマークの方法と違いを探してみる。
  • １インスタンスにボリュームを複数アタッチしている。
  • ブロックサイズが小さい。
  • directオプションを利用している。
  • numjobsオプションを利用している。
  • runtimeオプションを利用している。
  • group_reportingオプションを利用している。
  • 対象ディレクトリが違う。

ということでこのあたりを教科書通りにして再度チャレンジしてみる。 今日はここまで。

AmazonWebService実践入門を読んで実践する「その１：I/Oの高速化」続き

前編はこちらへ

前回の続きで、 AmazonWebService実践入門の本にあるI/O高速化の方法をベンチマークを使って試してみる。 のですが、まずは、その方法と取りうる選択肢を列挙してみます。

AWSでのI/O高速化の方法

手段 解説 遅い→→→→ →→→→→→→→ →→→→早い
1. EC2のストレージタイプの選択 EBS インスタンスストア
2. EC2のボリュームタイプの選択 マグネティック SSD（汎用） SSD（プロビジョンドIOPS）
3. EBS最適化オプションの選択 EC2とEBSの間のネットワークを占有できるオプション。
ロビジョンドIOPSを使用するときは
ネットワークがボトルネックになる場合が多いので、
このオプションを併用するようにしましょう。
また、EBS最適化オプションは比較的大きなサイズの
インスタンスでないと利用できない。		 なし あり
4. RAID0によるスクレイピング EBSでは１つのボリュームにおける容量や
IOPSには限界があります。
それを超えたパフォーマンスを求める場合、
RAID0でのストライピングが有効です。		 なし あり
5. ボリュームの暖機 EBSボリュームでは、
そのブロックへ初めてアクセスされる前に、
準備処理が行われます。
あらかじめこの準備処理を済ませておくことで、
最初からベストパフォーマンスで
稼働させることができます。		 なし あり

3,4,5はすべてEBSボリュームについてのことであり、特定の条件下で効果を発揮するものの様子なので、 まずは、基本的な1,2のみでの以下の比較をしてみようと思います。

検証パターン

検証する際のその他諸条件

  • インスタンスタイプはすべてのパターンで同じ「t2.micro」にする。
  • ボリュームのサイズはすべてのパターンで同じ「8 GiB」にする。
  • プロビジョンドIOPSのIOPS設定値は、100/3000とする。（100～20000でないといけないため）

jobファイルその1－(/home/ec2-user/fio-scenario1.fio)

[Sequential-Read]
rw=read
directory=/tmp/
size=1G
blocksize=512k
ioengine=libaio
buffered=0

[Sequential-Writes]
rw=write
directory=/tmp/
size=1G
blocksize=512k
ioengine=libaio
buffered=0

[Random-Read]
rw=randread
directory=/tmp/
size=1G
blocksize=512k
ioengine=libaio
buffered=0

[Random -Writes]
rw=randwrite
directory=/tmp/
size=1G
blocksize=512k
ioengine=libaio
buffered=0

jobファイルその２－ioengine=sync(/home/ec2-user/fio-scenario1.fio)

[Sequential-Read]
rw=read
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=0

[Sequential-Writes]
rw=write
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=0

[Random-Read]
rw=randread
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=0

[Random -Writes]
rw=randwrite
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=0

jobファイルその３　buffered=1　－ioengine=sync(/home/ec2-user/fio-scenario3.fio)

[Sequential-Read]
rw=read
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=1

[Sequential-Writes]
rw=write
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=1

[Random-Read]
rw=randread
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=1

[Random -Writes]
rw=randwrite
directory=/tmp/
size=1G
blocksize=512k
ioengine=sync
buffered=1

実行コマンド

fio /home/ec2-user/fio-scenario1.fio > /home/ec2-user/PATTERN1-`date +%Y%m%d_%H-%M-%S`.log
fio /home/ec2-user/fio-scenario2.fio > /home/ec2-user/PATTERN2-`date +%Y%m%d_%H-%M-%S`.log
fio /home/ec2-user/fio-scenario3.fio > /home/ec2-user/PATTERN3-`date +%Y%m%d_%H-%M-%S`.log
  • パターンの番号は別途記載しなおす。

検証前仮説

  • ⑥インスタンスストア＋SSD（プロビジョンドIOPS）が一番早い。
  • ①EBS＋マグネティックが一番遅い。

検証結果

f:id:utan1999:20160222004656p:plain

考察

以下の事象は本来逆の状態になるはず。設定がなにか違っている感じがする。
  • なぜか、SSD（プロビジョンドIOPS）のほうがIOPSが下がっている。
  • シーケンシャルとランダムで差がない。

改めて、設定を見直して検証したいと思います。 続報はまた今度。

AmazonWebService実践入門を読んで実践する「その１：I/Oの高速化」

AmazonWebService実践入門の本にあるI/O高速化の方法をベンチマークを使って試してみる。

方法：I/Oが遅い選択肢から順に早くさせていく。

本で紹介されている高速化の方法

  1. EC2のストレージタイプの選択
  2. EC2のボリュームタイプの選択
  3. EBS最適化オプションの選択
  4. RAID0によるスクレイピング
  5. ボリュームの暖機

まずは、fioを試しに使ってみる

ベンチマークコマンドをインスト―ル。

# rootになる
sudo su

# yumのアップデートする
yum clean all
yum -y update

# fioのインストール
yum install libaio-devel
wget http://pkgs.repoforge.org/fio/fio-2.0.14-1.el5.rf.x86_64.rpm
rpm -Uvh fio-2.0.14-1.el5.rf.x86_64.rpm
rpm -qa | grep fio

# fioインストール確認
which fio

fioの実行結果

[root@ip-172-31-26-155 ec2-user]# fio ./fileio_bench/random-read.fio
random-read: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.0.14
Starting 1 process
random-read: Laying out IO file(s) (1 file(s) / 100MB)

random-read: (groupid=0, jobs=1): err= 0: pid=7160: Thu Feb 11 16:10:52 2016
  read : io=102400KB, bw=2173.1MB/s, iops=556521 , runt=    46msec
    clat (usec): min=0 , max=24 , avg= 1.09, stdev= 0.77
     lat (usec): min=0 , max=24 , avg= 1.21, stdev= 0.79
    clat percentiles (usec):
     |  1.00th=[    0],  5.00th=[    0], 10.00th=[    1], 20.00th=[    1],
     | 30.00th=[    1], 40.00th=[    1], 50.00th=[    1], 60.00th=[    1],
     | 70.00th=[    1], 80.00th=[    1], 90.00th=[    2], 95.00th=[    2],
     | 99.00th=[    3], 99.50th=[    3], 99.90th=[   13], 99.95th=[   14],
     | 99.99th=[   21]
    lat (usec) : 2=88.38%, 4=11.12%, 10=0.34%, 20=0.14%, 50=0.02%
  cpu          : usr=17.78%, sys=71.11%, ctx=7, majf=0, minf=4
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=25600/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=102400KB, aggrb=2173.1MB/s, minb=2173.1MB/s, maxb=2173.1MB/s, mint=46msec, maxt=46msec

Disk stats (read/write):
  xvda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
[root@ip-172-31-26-155 ec2-user]#

おーいろいろ結果が出てるがさっぱり意味がわからん。 fioコマンドのことを学ばねば。。。 ということで↓でまずはfioコマンドをお勉強。

tasuku.hatenablog.jp

fioコマンド

はじめに

AWSのディスクI/0の高速化をテーマにした実践をするために、 まずは、その実践で使うディスクI/Oを計測するベンチマーク測定ツール「fioコマンド」についてお勉強。

fioコマンドとは

由来

flexible I/O tester

FileI/Oの略なんだと思ってたら、 「flexible I/O tester」の略なんだと。

作者・開発元

Jens Axboe

WikiPediaによるとLinuxカーネルのハッカーらしい。今はORACLEに在籍している様子。 1976年生まれ。（近い！同じ世代でこんなもの作っちゃう人。同じ人間に思えない。）

最新バージョン

2.6(記事投稿時点での最新)

Releases · axboe/fio · GitHub によると、記事投稿日から18日前に2.6がリリースされている様子。

概要

  • ディスクI/Oに負荷をかけるためにスレッドやプロレスをうじゃうじゃ起動でき、設定された分のFIOの負荷をかけることができる。
  • linux版だけでなく、windows版もある。http://www.bluestop.org/fio/

コマンド構文

fio [options] [jobfile]...

コマンドオプション

  • --debug
    • Enable some debugging options (see below)
    • デバックモードにする
  • --parse-only
    • Parse options only, don't start any IO
    • 決められたフェーズのみ負荷をかける設定ができる？っぽい。
  • --output
    • Write output to file
    • 結果出力先の指定
  • --runtime
    • Runtime in seconds
    • 実行時間の指定
  • --bandwidth-log
    • Generate per-job bandwidth logs
    • 1ジョブごとに帯域幅を測定する
  • --minimal
    • Minimal (terse) output
    • 最小の簡易出力
  • --output-format=type
    • Output format (terse,json,json+,normal)
    • 出力形式
  • --terse-version=type
    • Terse version output format (default 3, or 2 or 4).
    • 簡単モードで使うバージョン？
  • --version
    • Print version info and exit
    • バージョン情報の出力
  • --help
    • Print this page
    • ヘルプ
  • --cpuclock-test
    • Perform test/validation of CPU clock
    • CPUクロックの確認をする
  • --crctest[=test]
  • --cmdhelp=cmd
    • Print command help, "all" for all of them
    • コマンドのヘルプ。
  • --enghelp=engine
    • Print ioengine help, or list available ioengines
    • エンジンのヘルプを出力する。
  • --enghelp=engine,cmd
    • Print help for an ioengine cmd
    • エンジンのヘルプを出力する？
  • --showcmd
    • Turn a job file into command line options
    • ジョブファイルにコマンドラインオプションの内容を追加する？

  • --eta=when

    • When ETA estimate should be printed　May be "always", "never" or "auto"
    • 終了予定時間を出力する

  • --eta-newline=time Force a new line for every 'time' period passed

  • --status-interval=t Force full status dump every 't' period passed

  • --readonly

    • Turn on safety read-only checks, preventing writes
    • 読み取り処理のみチェック。書き込みを防ぐことができる。
  • --section=name
    • Only run specified section in job file
    • ジョブファイルのしていされたセクションだけ実行する
  • --alloc-size=kb
    • Set smalloc pool to this size in kb (def 1024)
    • 表示されるサイズ？
  • --warnings-fatal
    • Fio parser warnings are fatal
    • warningはfaitalとして扱うか？
  • --max-jobs=nr
    • Maximum number of threads/processes to support
    • 最大のスレッド・プロセス数
  • --server=args
    • Start a backend fio server
    • 処理を開始するサーバ
  • --daemonize=pidfile
    • Background fio server, write pid to file
    • バックグラウンドで実行するか？
  • --client=hostname
    • Talk to remote backend fio server at hostname
    • リモートにあるサーバで実行する場合のホスト名指定
  • --idle-prof=option
    • Report cpu idleness on a system or percpu basis (option=system,percpu) or run unit work calibration only (option=calibrate)
    • ？
  • --inflate-log=log
    • Inflate and output compressed log
    • ログが増えたら圧縮する
  • --trigger-file=file
    • Execute trigger cmd when file exists
    • ファイルで起動する場合のトリガーファイル。（ファイルが存在すれば実行する）
  • --trigger-timeout=t
    • Execute trigger af this time
    • 時間で起動する場合のトリガー時間。
  • --trigger=cmd
    • Set this command as local trigger
    • ？
  • --trigger-remote=cmd 　Set this command as remote trigger 　？
  • --aux-path=path
    • Use this path for fio state generated files
    • ?

ジョブファイルのパラメータ

ここではよく利用しそうなもののみ紹介します。
すべてのパラメータを知りたい場合はこちらへ
ジョブファイル記述例
[random-read]→コメント
rw=randread
size=100m
directory=/home/test/fio/
パラメータ名 設定例 パラメータ説明
rw rw=str fioで読み書きする方法。詳細はこちらへ。
設定できる値は、read,write,randwrite,randread,rw,readwrite,randrw,trimwriteがある
randrepeat randrepeat=bool ランダムアクセスを規則的に行うか？設定できるっぽい。
ランダムアクセスでのベンチマークをするときにはfalseにしたほうがよさそう
randseed randseed=int ここで設定された値をもとに、乱数を発生させて、ランダムアクセスするらしい。
ioengine ioengine=str IOをどう行うか決める。デフォルトはsync(同期I/O)になる。
syncかlibaioを使うことが多い様子。
Nullはデバックやテスト目的で利用。
size size=int この測定で読み書きするファイルサイズ。
Job全体のIOサイズ。
単位はb。, 64{k,M, G, T, P}, 10% など
percentage_random percentage_random=int どのくらいの割合でランダムにするか設定できる。
100%にするとすべてランダム、0％だとすべてシーケンシャルになる。
読み取り、書き込み、トリムそれぞれに値を設定できる。
設定例：読み取りに50％書き込みに100％トリムは0%の場合は　
「percentage_random=50,100,0」。
nrfiles nrfiles=int このジョブで利用するファイル数を設定できる。デフォルトは1。
overwrite overwrite=bool ファイルへの書き込みを上書きとするか、
全削除して新規書き込みとするかの選択。
1=true=上書きする。デフォルトは1（true）
runtime runtime=time 実行最大時間。単位はseconds(秒)
buffered buffered=bool バッファを利用するか否か。デフォルトは1（true）
iomem，mem iomem=str，mem=str バッファとして利用するメモリーのタイプ。
以下が選択できるらしい。
malloc 、shm 、shmhuge 、mmap 、mmaphuge 、mmapshared
verify_only 実際の計測はしないで、確認用のモード。
lockmem lockmem=int 指定された量のメモリを未使用にできるらしい。メモリの少ない状態をシュミレートできるとのこと。
rwmixread rwmixread=int 読み書きの割合。設定例：-rwmixread=70　70％read,　30%write
rwmixwrite rwmixwrite=int rwmixreadと一緒で引数の意味が逆なだけ
nice nice=int このコマンドのCPU優先順位を決定する。
ナイス値は-20～19であり-20がもっとも優先される。
デフォルトは10。
rate rate=int ジョブで使用される帯域幅。数はバイト/秒。
ratemin ratemin=int 最低限維持する帯域幅。
これを下回るとジョブが途中終了し失敗扱いになる。

インストール

fioのインストール

yum install fio
  • ぐぐると、ほかのコンパイルするのに必要なパッケージも入れるように言われてるけど、 EC2の場合（もしくはAmazonLinuxAMIの場合？）はfioを直接インストールできちゃうみたい。

fioのバージョン確認

fio -v

> [ec2-user@ip-172-31-26-155 ~]$ fio -v
> fio-2.1.5

使い方

  1. fioで読み書きするディレクトリを決める。または対象のディレクトリを作成する。
    今回は、「/tmp/fio-test/」にします。
  2. jobファイルを作成して、必要なパラメータを記述する。今回は以下を設定。
[sample]
rw=randread
size=256m
directory=/tmp/fio-test
  1. fioコマンドを実行する。
[ec2-user@ip-172-31-26-155 fio-benchmark]$ fio /home/ec2-user/fio-benchmark/sample.job
  1. 結果を検証する。

結果を見る

実行中ログ
sample: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.5
Starting 1 process
Jobs: 1 (f=1)
Jobs: 1 (f=1): [r] [15.8% done] [14808KB/0KB/0KB /s] [3702/0/0 iops] [eta 00m:16s]
Jobs: 1 (f=1): [r] [22.2% done] [16144KB/0KB/0KB /s] [4036/0/0 iops] [eta 00m:14s]
Jobs: 1 (f=1): [r] [29.4% done] [16920KB/0KB/0KB /s] [4230/0/0 iops] [eta 00m:12s]
Jobs: 1 (f=1): [r] [35.3% done] [16688KB/0KB/0KB /s] [4172/0/0 iops] [eta 00m:11s]
Jobs: 1 (f=1): [r] [41.2% done] [15428KB/0KB/0KB /s] [3857/0/0 iops] [eta 00m:10s]
Jobs: 1 (f=1): [r] [47.1% done] [16232KB/0KB/0KB /s] [4058/0/0 iops] [eta 00m:09s]
Jobs: 1 (f=1): [r] [52.9% done] [16208KB/0KB/0KB /s] [4052/0/0 iops] [eta 00m:08s]
Jobs: 1 (f=1): [r] [58.8% done] [14892KB/0KB/0KB /s] [3723/0/0 iops] [eta 00m:07s]
Jobs: 1 (f=1): [r] [64.7% done] [16392KB/0KB/0KB /s] [4098/0/0 iops] [eta 00m:06s]
Jobs: 1 (f=1): [r] [70.6% done] [16036KB/0KB/0KB /s] [4009/0/0 iops] [eta 00m:05s]
Jobs: 1 (f=1): [r] [76.5% done] [17300KB/0KB/0KB /s] [4325/0/0 iops] [eta 00m:04s]
Jobs: 1 (f=1): [r] [82.4% done] [16436KB/0KB/0KB /s] [4109/0/0 iops] [eta 00m:03s]
Jobs: 1 (f=1): [r] [88.2% done] [14764KB/0KB/0KB /s] [3691/0/0 iops] [eta 00m:02s]
Jobs: 1 (f=1): [r] [94.1% done] [15028KB/0KB/0KB /s] [3757/0/0 iops] [eta 00m:01s]
Jobs: 1 (f=1): [r] [100.0% done] [16340KB/0KB/0KB /s] [4085/0/0 iops] [eta 00m:00s]
実行結果
sample: (groupid=0, jobs=1): err= 0: pid=28707: Sun Feb 21 06:08:29 2016
  read : io=262144KB, bw=15935KB/s, iops=3983, runt= 16451msec
    clat (usec): min=166, max=41865, avg=249.06, stdev=375.48
     lat (usec): min=166, max=41866, avg=249.25, stdev=375.48
    clat percentiles (usec):
     |  1.00th=[  179],  5.00th=[  185], 10.00th=[  187], 20.00th=[  191],
     | 30.00th=[  195], 40.00th=[  199], 50.00th=[  205], 60.00th=[  211],
     | 70.00th=[  219], 80.00th=[  235], 90.00th=[  290], 95.00th=[  422],
     | 99.00th=[  908], 99.50th=[ 1400], 99.90th=[ 3920], 99.95th=[ 5792],
     | 99.99th=[15936]
    bw (KB  /s): min=13600, max=18096, per=100.00%, avg=15957.00, stdev=1212.90
    lat (usec) : 250=84.46%, 500=12.32%, 750=1.75%, 1000=0.61%
    lat (msec) : 2=0.54%, 4=0.22%, 10=0.08%, 20=0.01%, 50=0.01%
  cpu          : usr=0.32%, sys=5.01%, ctx=65576, majf=0, minf=6
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=65536/w=0/d=0, short=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=262144KB, aggrb=15934KB/s, minb=15934KB/s, maxb=15934KB/s, mint=16451msec, maxt=16451msec

Disk stats (read/write):
  xvda: ios=65380/0, merge=0/0, ticks=16068/0, in_queue=16064, util=97.36%
実行結果パラメータの意味
  • ジョブ単位での結果
パラメータ名 原文 解釈
io Number of megabytes io performed 何バイト分ディスク読み書きしたかを表す
bw Average bandwidth rate 平均の帯域幅。
iops Average IOs performed per second ディスクが1秒当たりに処理できるI/Oアクセスの数である。
IOPSが高ければ高いほど，高性能なディスクと言える。
1回のI/O処理にかかる時間は，平均アクセス時間と
データ転送時間を足した数値。
このI/O処理が1秒当たり何回実行できるかがIOPSである
IOPS計算式
runt The runtime of that thread 処理実行時間。
slat Submission latency
(avg being the average, stdev being the standard deviation).
This is the time it took to submit the io.
For sync io, the slat is really the completion latency,
since queue/complete is one operation there.
This value can be in milliseconds or microseconds,
fio will choose the most appropriate base and print that.
In the example above, milliseconds is the best scale.
Note: in --minimal mode latencies are always expressed in microseconds.		 Submission latency。リクエスト送信までの遅延時間
clat Completion latency.
Same names as slat, this denotes
the time from submission to completion of the io pieces.
For sync io, clat will usually be equal (or very close) to 0,
as the time from submit to complete is
basically just CPU time
(io has already been done, see slat explanation).		 completeion latency。リクエスト送信から終了までの遅延時間
bw Bandwidth.
Same names as the xlat stats,
but also includes an approximate
percentage of total aggregate bandwidth
this thread received in this group.
This last value is only really useful
if the threads in this group
are on the same disk,
since they are then competing for disk access.		 帯域幅。
cpu CPU usage.
User and system time,
along with the number of context switches
this thread went through,
usage of system and user time,
and finally the number of major and minor page faults.		 CPU使用率
IO depths The distribution of io depths over the job life time.
The numbers are divided into powers of 2,
so for example
the 16= entries includes depths up to that value
but higher than the previous entry.
In other words, it covers the range from 16 to 31.		 実行時のリクエスト待機状態。submit 以下の行は、IOリクエストまでに要したレイテンシ情報。
IO submit How many pieces of IO were submitting in a single submit call.
Each entry denotes that amount and below,
until the previous entry - eg, 8=100% mean
that we submitted anywhere in between 5-8 ios per submit call.		 ？
IO complete Like the above submit number,
but for completions instead.		 ？
IO issued The number of read/write requests issued,
and how many of them were short.		 ？
IO latencies The distribution of IO completion latencies.
This is the time from when IO leaves fio and when it gets completed.
The numbers follow the same pattern as the IO depths,
meaning that 2=1.6% means that 1.6% of the IO completed
within 2 msecs, 20=12.8% means that 12.8% of the IO
took more than 10 msecs, but less than (or equal to) 20 msecs.		 ？
  • グループ単位（Run status group）での結果
パラメータ名 原文 解釈
io Number of megabytes io performed. 何バイト分ディスク読み書きしたかを表す
aggrb Aggregate bandwidth of threads in this group. 帯域幅のグループ集計
minb The minimum average bandwidth a thread saw. 最小帯域幅
maxb The maximum average bandwidth a thread saw. 最大帯域幅
mint The smallest runtime of the threads in that group. 最小実行時間
maxt The longest runtime of the threads in that group. 最大実行時間
  • ディスク単位（Disk stats (read/write)）での結果
パラメータ名 原文 解釈
ios Number of ios performed by all groups. 何バイト分ディスク読み書きしたかを表す
merge Number of merges io the io scheduler. 解釈
ticks Number of ticks we kept the disk busy. リクエストがキューに入っていた数
io_queue Total time spent in the disk queue. リクエストがキューに入っていた時間
util The disk utilization.
A value of 100% means we kept the disk busy constantly,
50% would be a disk idling half of the time.		 ディスクアイドル時間（数が多いほどよくディスクを利用できていることになる）

Amazon Linux AMIのUpdateお知らせ

Amazon Linux AMIにSSHログインすると

Amazon Linux AMIにSSHログインすると、↓のように、パッケージにupdateがあることを知らせてくれる。

f:id:utan1999:20160221142534p:plain

とても親切ぅ～。

とりあえず、書かれているURLにアクセスしてどんなupdateがあるか見てみる。

Amazon Linux AMI 2015.09 Release Notes

うーん。英語でいろいろ書かれててよくわからない。 まあ、とりあえず、指示されてる通り、”sudo yum update”してみる。

途中、

Total download size: 95 M
Is this ok [y/d/N]:

と聞かれるが、ｙを選択して進める。

最後に、”Complete!”と出てきて完了！

なんて便利なんだろう。 ありがとうアマゾンさん。

ヒヤリハットであるうちに。その１：プロンプト

たくさんのサーバやインスタンスのコンソールを同時に開くことって、 システム屋さんなら頻繁にあると思います。 そんな時に、今どのサーバを操作しているんだったかな？って混乱することありますよね。

本番サーバに対してテストサーバの設定を間違ってしちゃったりしたら、 そりゃーヒヤリハットじゃすまされないです。

大概は、そんな事故の前に何かしらの方法で今いるサーバを確認します。

unameコマンドでホスト名を確認する。

例えば、

uname -a

コマンドを使って、今操作しているサーバの情報を見たりします。

AWSのAmazonLinuxAMIの場合は以下のような結果になります。

[ec2-user@ip-172-31-26-155 ~]$ uname -a
Linux ip-172-31-26-155 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[ec2-user@ip-172-31-26-155 ~]$

うーん、これを見てもどのインスタンスなのかわからない。。。

[ec2-user@ip-172-31-26-155 ~]$ uname -n
ip-172-31-26-155

ホスト名が視覚的に理解できるものでなく、 割り当てられたローカルIPアドレスになっていた。 これはAWSが自動で割り当ててるのかな。

ではでは。ホスト名をわかりやすいものに変更。

[root@ip-172-31-26-155 ec2-user]# hostname TASUKU-PROD-WEB

もう一度、サーバ情報を見てみると、

[root@ip-172-31-26-155 ec2-user]# uname -a
Linux TASUKU-PROD-WEB 4.1.10-17.31.amzn1.x86_64 #1 SMP Sat Oct 24 01:31:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

ホスト名がわかりやすいもので設定されていていい感じ！

[root@ip-172-31-26-155 ec2-user]# uname -n
TASUKU-PROD-WEB

uname -nならホスト名だけなのでもっとわかりやすい。

プロンプトにホスト名を表示させる

いま操作しているコンソールのサーバ情報を毎回コマンドで確認するのはちょっと面倒。 なので、プロンプトに現在操作しているサーバがわかるように設定しよう！と思います。

プロンプトの表示内容が設定されているファイルを開きます。

[ec2-user@ip-172-31-26-155 ~]$ vim ~/.bashrc

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# User specific aliases and functions

上記のユーザホームにある.bashrcファイルでは、 グローバル定義の/etc/bashrcを参照するように記述されている。

/etc/bashrcでは、プロンプトに表示する内容を、PS1という変数で 設定しているので、ユーザホームにあるファイルの末尾に、 へPS1を定義してあげればプロンプトの設定を変更できる。

今回は、 『時間　－　ユーザ＠ホスト名　－　ホームからのディレクトリパス』 といった表記になるように以下を設定。

PS1='[\e[0;37m][ [\e[0;32m]\t - [\e[0;33m]\u@\h - [\e[0;36m]\w [\e[0;37m]]'

結果は、

f:id:utan1999:20160221021946p:plain

とても見やすくて安心して作業できる。 おまけにクライアントのログ機能で記録しておけば、 時間もわかるのでコマンド履歴だけでなく通常のログとして扱える。

事故を未然に防ぐことには、 効率的で生産的な作業にもつながるのだと実感。

fioコマンドのrwオプション

fioコマンドの公式マニュアルから引用

rw=str Type of io pattern. Accepted values are:

      read        Sequential reads
      write       Sequential writes
      randwrite   Random writes
      randread    Random reads
      rw,readwrite    Sequential mixed reads and writes
      randrw      Random mixed reads and writes
      trimwrite   Mixed trims and writes. Blocks will be
              trimmed first, then written to.

  For the mixed io types, the default is to split them 50/50.
  For certain types of io the result may still be skewed a bit,
  since the speed may be different. It is possible to specify
  a number of IO's to do before getting a new offset, this is
  done by appending a ':<nr>' to the end of the string given.
  For a random read, it would look like 'rw=randread:8' for
  passing in an offset modifier with a value of 8. If the
  suffix is used with a sequential IO pattern, then the value
  specified will be added to the generated offset for each IO.
  For instance, using rw=write:4k will skip 4k for every
  write. It turns sequential IO into sequential IO with holes.
  See the 'rw_sequencer' option.

タイプ一覧

type 原文 解釈 設定時注意点
read Sequential reads 連続したブロックの読み取り
write Sequential writes 連続したブロックへの書き込み
randwrite Random writes ランダムなブロック位置の読み取り
randread Random reads ランダムなブロック位置への書き込み
rw,readwrite Sequential mixed reads and writes 連続したブロックへの読み込みと書き込み
randrw Random mixed reads and writes ランダムなブロック位置への読み込みと書き込み rwmixreadやrwmixwriteパラメータと組み合わせて、読み書きの割合を調整する。
trimwrite Mixed trims and writes. Blocks
will be trimmed first, then written to.		 ？？
  • ※１：シーケンシャルとランダムについては、こちらへ