元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2012/07/30

crontabでの「%」の扱い


昔、遭遇した気もするが、また忘れていたのでメモ。多分、常識の範疇w


crontabにこんな感じで設定を仕込もうとしたんですね。

*/5 * * * * /usr/bin/iotop -b -k -t -n 2 -o >> /var/log/iotop/"`hostname`_`date '+%F_%H'`"

すると、「メールが /var/spool/mail/root にあります」とメールが届きまして、、、

/bin/sh: -c: line 0: unexpected EOF while looking for matching ``'
/bin/sh: -c: line 1: syntax error: unexpected end of file

こんな感じで怒られたわけです。


あんれー?と思って、"/var/log/cron"を確認すると、

CROND[17743]: (root) CMD (/usr/bin/iotop -b -k -t -n 1 -o >> /var/log/iotop/"`hostname`_`date '+)

と表示されていて、あんれーーー!「%」以降がどっかいっちゃってるー、と気付きました。


んで、まぁ定番の"man 5 crontab"とかすると、ちゃんと答えが書いてあるわけです。。。

「第 6」フィールド (行の残りの部分) には実行されるコマンドを指定する。 その行のコマンド部 (改行文字または % 文字まで) が /bin/sh (またはその crontab ファイルの SHELL 環境変数で指定されたシェル) によって実行される。 コマンド中にパーセント記号 (%) が バックスラッシュ (\) によってエスケープされずに置かれていると、 改行文字に置き換えられ、最初に現れた % 以降の全てのデータは 標準入力としてコマンドに送られる。

Man page of CRONTAB

・・・ということで、

*/5 * * * * /usr/bin/iotop -b -k -t -n 2 -o >> /var/log/iotop/"`hostname`_`date '+\%F_\%H'`"

こんな感じで、crontabでの「%」記述は必要に応じてエスケープしましょうというログでした・・・。

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


プロのための Linuxシステム・10年効く技術 (Software Design plus)

プロのための Linuxシステム・10年効く技術 (Software Design plus)

2012/07/27

High I/O Instance ベンチマーク

噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた


先日、Amazon EC2で使える、2TB分のSSDを積んだ新しいインスタンスタイプ(High I/O Instances / High I/O Quadruple Extra Large Instance)が発表されました。

ディスクI/O性能が高速なインスタンスは初登場なので、I/Oがシビアに要求されるデータベース等の利用においては、期待を寄せちゃいますよねー。


というわけで、このSSDのディスクI/Oパフォーマンスがどのくらい速いのかを試してみちゃいました。厳密なベンチマークではないですが、参考になれば幸いです。


・・・ちなみに、過去のベンチマークエントリもあわせてどうぞ。


ベンチマーク対象

ベンチマークをかける対象は、もちろん発表されたばかりの「High I/O Quadruple Extra Large Instance (hi1.4xlarge)」のEC2インスタンスです。

発表されているスペックは以下の通り。

High I/O Quadruple Extra Large Instance

60.5 GB of memory
35 EC2 Compute Units (16 virtual cores*)
2 SSD-based volumes each with 1024 GB of instance storage
64-bit platform
I/O Performance: Very High (10 Gigabit Ethernet)
Storage I/O Performance: Very High**
API name: hi1.4xlarge

*8 cores + 8 hyperthreads for 16 virtual cores 

そのインスタンスで起動させるAMIは、「Amazon Linux AMI 2012.03」の64bitにしてみました。

f:id:rx7:20120726212210p:image:w480


さて、肝心のディスク(ストレージ)ですが、エフェメラルディスクであっても、最近はAWS Management Consoleからアタッチとかできたりします。便利になりましたね。


というわけで、以下のような感じのディスク構成にしてみました。


f:id:rx7:20120726235131p:image

SSDのデバイス2つに加えて、比較対象として、(小さいですが)10GBのEBSのデバイスも2つほどアタッチして、インスタンスを起動させます。


利用ツール(fio)のインストール/実行


EC2インスタンスが起動したら、次はベンチマークをかける環境を作ります。

と、その前に、起動したインスタンスで、デバイスが↑で設定した通りに認識しているかを確認します。


# ll /dev/sd*
lrwxrwxrwx 1 root root 5 Jul 25 12:44 /dev/sda1 -> xvda1
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdf -> xvdf
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdg -> xvdg
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdh -> xvdh
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdi -> xvdi

OK。認識できていますねー。


ちなみにCPUはIntel Xeon E5620が積まれていました。8core x2 (HT)で見えたので、CPU2つ分かな。


さて、閑話休題。

今回、ディスクI/Oを計測するツールは「fio」で測ってみることにしたので、そのツールを以下の要領でインストールします。

# wget http://pkgs.repoforge.org/fio/fio-2.0.7-1.rf.src.rpm

src.rpmをダウンロードして、、、


# yum -y install rpm-build libaio-devel gcc make

ビルドに必要になる関連パッケージをyumでインストール。


# rpmbuild --rebuild fio-2.0.7-1.rf.src.rpm

からのrpmbuildでRPMを作りーの、、、


# rpm -Uvh rpmbuild/RPMS/x86_64/fio-2.0.7-1.amzn1.x86_64.rpm

RPMをインストール。


# fio -v
fio 2.0.7

はい、ベンチマークできる環境が整いました。


ちなみに今回ベンチマークを取るのに使ったコマンドは以下の6つです。

まず、上から4つは、それぞれシーケンシャルリード/ライトランダムリード/ライト、ブロックサイズは4kで設定しています。IOPSのチェックが主目的です。

# fio -filename=/data/test2g -direct=1 -rw=read -bs=4k -size=2G -numjobs=64 -runtime=10 -group_reporting -name=file1
# fio -filename=/data/test2g -direct=1 -rw=write -bs=4k -size=2G -numjobs=64 -runtime=10 -group_reporting -name=file1
# fio -filename=/data/test2g -direct=1 -rw=randread -bs=4k -size=2G -numjobs=64 -runtime=10 -group_reporting -name=file1
# fio -filename=/data/test2g -direct=1 -rw=randwrite -bs=4k -size=2G -numjobs=64 -runtime=10 -group_reporting -name=file1

あとの2つは、ブロックサイズを大きくして、主にbandwidth(転送レート)をチェックしています。

# fio -filename=/data/test2g -direct=1 -rw=read -bs=32m -size=2G -numjobs=16 -runtime=10 -group_reporting -name=file1
# fio -filename=/data/test2g -direct=1 -rw=write -bs=32m -size=2G -numjobs=16 -runtime=10 -group_reporting -name=file1

SSDディスク単体のパフォーマンス

High I/O Quadruple Extra Large Instance では、1TBのSSDが2本積まれていますので、まずは1本単体の性能チェックをしてみます。


# fdisk /dev/sdf

まずは、パーティションを切って"/dev/sdf1"を作ります。(fdiskの使い方はググってちょ)

今回は、xfsファイルシステムで統一してベンチマークを取ってみたいので、、、


# yum -y install xfsprogs

安定のyumでxfs関連のパッケージをインスコ。


# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/sdf1

とりあえず、こんな感じで"/dev/sdf1"にxfsファイルシステムを作成すべくmkfsします。


# mkdir /data
# mount -t xfs -o noatime,logbufs=8 /dev/sdf1 /data

で、こんな感じのパラメータでマウントします。


ここで、先ほど書いた6つのfioコマンドを流して計測した結果が以下です。


Benchmark TypeBandwidthIOPS
4k, sequential read270.1MB/s67536
4k, sequential write82.8MB/s20696
4k, randam read339.8MB/s84945
4k, randam write86.4MB/s21608
32m, sequential read623.5MB/s19
32m, sequential write564.7MB/s17

なかなか優秀です。さすがSSD・・・。


SSD2つでRAID0(ストライピング)でのパフォーマンス

このインスタンスは、せっかくSSDデバイスが2つ付いているので、それならRAID0で束ねなきゃね、って発想は誰もが思うはずなので、こちらもベンチマークをとってみます。

というわけで、さっきの↑と同じ感じで準備します。

(当然、さっき使ったデータが残っていたりする場合は、umountして、パーティション情報を削除して、、、みたいなことをしましょう。)


# /sbin/mdadm --create /dev/md0 --chunk=256 --level=0 --raid-devices=2 /dev/sdf /dev/sdg
# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/md0
# mount -t xfs -o noatime,logbufs=8 /dev/md0 /data

こんな感じで、ソフトウェアRAID0で"/dev/md0"を作成、xfsファイルシステムを作成&マウントって感じです。

で、、、先ほど同様に6コマンドを実行した結果は以下の通り。


Benchmark TypeBandwidthIOPS
4k, sequential read442.4MB/s110611
4k, sequential write85.4MB/s21345
4k, randam read471.4MB/s117840
4k, randam write74.9MB/s18719
32m, sequential read1268.7MB/s39
32m, sequential write1129.5MB/s35

なぜかライトは伸びていませんが、リードは4kでシーケンシャル/ランダムアクセスともに100,000IOPSを超えています!BSが4kで100,000IOPS超えはなかなか優秀じゃないでしょうか。素晴らしい・・・!


EBSボリューム2つでRAID0(ストライピング)でのパフォーマンス

せっかく比較対象で、EBSボリュームを2つアタッチしているので、こちらでもRAID0(ストライピング)を組んでベンチマークをとってみます。


# /sbin/mdadm --create /dev/md1 --chunk=256 --level=0 --raid-devices=2 /dev/sdh /dev/sdi
# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/md1
# mount -t xfs -o noatime,logbufs=8 /dev/md1 /data

さっき同様に準備。

からの6コマンドを実行した結果が以下。


Benchmark TypeBandwidthIOPS
4k, sequential read100.0MB/s24993
4k, sequential write12.5MB/s3113
4k, randam read83.2MB/s20803
4k, randam write14.5MB/s3614
32m, sequential read198.9MB/s6
32m, sequential write69.1MB/s2

意外とIOPSが出ております。ランダムリードでも20,000IOPSを超えている。

EBSボリュームって普通のハードディスクとかではなさそうな感じですね。SSDキャッシュとかがついてるのかしら?


通常のエフェメラルディスク2つでRAID0(ストライピング)でのパフォーマンス

せっかくなので、さらに同様な感じで、通常のエフェメラルディスク(これまでAWSで使えたもの)についても、同様にディスク2本でRAID0を組んでベンチマークを取ってみました。

使用したインスタンスタイプは、↑で使ったものに近いスペックであるHigh-Memory Quadruple Extra Large Instance(スペックは以下)を使用し、AMIは↑と同じものを使っています。

High-Memory Quadruple Extra Large Instance

68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.4xlarge

f:id:rx7:20120726235132p:image

ちなみにストレージ構成はこんな感じで、↑のインスタンスで使えるエフェメラルディスクをフルに使います。

OSが起動したら、早速RAID0なボリュームを作るべく準備します。

# /sbin/mdadm --create /dev/md0 --chunk=256 --level=0 --raid-devices=2 /dev/sdf /dev/sdg
# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/md0

# mkdir /data
# mount -t xfs -o noatime,logbufs=8 /dev/md0 /data

とはいっても、先ほどと同じ要領・パラメータです。

そして、6コマンドを実行した結果が以下となります。


Benchmark TypeBandwidthIOPS
4k, sequential read32.8MB/s8189
4k, sequential write6.3MB/s1590
4k, randam read2.9MB/s722
4k, randam write3.2MB/s796
32m, sequential read185.1MB/s5
32m, sequential write85.1MB/s2

こちらはシーケンシャルアクセスに関してはそこそこですが、ランダムアクセスとなると700〜800IOPSとなっているので、通常のディスクに近い感覚ですね。


ベンチマークのまとめ

というわけで、ベンチマーク結果をまとめたグラフがこちらになります。

IOPS

f:id:rx7:20120726235133p:image

※ 単位はIOPS、ブロックサイズ4k


Bandwidth

f:id:rx7:20120726235134p:image

※ 単位はMB/s


結論

そこそこのI/Oリソースが要求されるケースでも、これだけのシーケンシャル/ランダムアクセス性能があれば、ある程度は、このインスタンスで十分こなせるのではないでしょうか。IOPSで100,000以上、帯域幅は1GB/sを超えていますので。

今までのエフェメラルディスクで使えるディスクのI/Oパフォーマンスを比較しても、特にランダムアクセスに関してはかなり優秀な結果となっています。というわけで当然の結果ではありますが、、、

EC2で使えるSSDは速かった!


それでは!それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考



まとめ


2012/07/23

crontabの"-i"オプションで"-r"のうっかりミスを防止する


今、お風呂からあがって、TwitterのTLを見てたら「crontab -e は「絶対に」使ってはいけない - ろば電子が詰まっている」のエントリを読んで、その勢いで書く。


crontabコマンドにはrオプション(Remove)があり、これを実行すると何の警告もなく全てが消え失せる。

crontab -e は「絶対に」使ってはいけない - ろば電子が詰まっている

確かに、(僕も含めて) 誰もが一度くらいは怖い/ドキドキするような思いをするのかもしれないですが、crontabコマンドには"-i"オプションという、削除時に確認のプロンプトを出してくれるオプションが存在します。

つまり、aliasでこのオプションをつけておけば良いわけですな。


$ crontab -e
crontab: installing new crontab
$ crontab -r
$ crontab -l
no crontab for nami

何もしてないと、上のように"-e"オプションで編集・保存をした後に、うっかり"-r"オプションをつけちゃうと、設定したcronが消えてしまう・・・!


$ alias crontab="crontab -i"
$ crontab -e
crontab: installing new crontab
$ crontab -r
crontab: really delete nami's crontab? (y/n) 

そこで、profileなどで「alias crontab="crontab -i"」な感じで定義しておけば、↑のように"-r"オプションをつけても、一応消して良いかの確認プロンプトが出ます。

manにも↓のように記載がありますね。

The -i option modifies the -r option to prompt the user for a 'y/Y' response before actually removing the crontab.


もちろんバックアップ等は別途必要なわけですが、↑のaliasを入れておいても悪くないと思いまする。

※ 一応、マジレスしておくと、うちはcrontabの設定は全て"Chef"で管理/流している。

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

2012/07/13

xfsが壊れたので修復...


久しぶりにxfsを壊した。

DRBDを入れている環境で、ちょっと無茶な検証テストをしたら、HeartbeatでPrimaryに昇格(切り替わり)できなくなって、ちょっと調べてみたらマウントできなくなっていた。久しぶりにやったのでメモ。


# mount /dev/drbd0 /data
mount: 構造体を内容消去する必要があります

こんな感じで。壊れた・・・。


mount: Structure needs cleaning

英語だと、こんな感じのメッセージじゃろ。


# xfs_check /dev/drbd0
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

お約束のチェック。で、エラー。アンマウントしろとのことだが、そもそもマウントはできていないので、その場合は "xfs_repair -L" を実行せよと言っている。ただしデータが破損してしまうかもしれない可能性があると警告で出ているので、必要に応じてバックアップしておいた方が良いと思う。(ddとかで)

今回は検証環境だったので、遠慮なくリペアしてみる。


# xfs_repair -L /dev/drbd0
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
        - scan filesystem freespace and inode maps...
sb_ifree 61, counted 59
sb_fdblocks 156227448, counted 156227447
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 3
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 22
        - agno = 1
        - agno = 4
        - agno = 21
        - agno = 5
        - agno = 7
        - agno = 6
        - agno = 2
        - agno = 8
        - agno = 14
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - agno = 26
        - agno = 20
        - agno = 23
        - agno = 24
        - agno = 13
        - agno = 25
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

無事終了。


# mount /dev/drbd0 /data
#

からの無事マウントできた。中を見る限り、データの異常は確認できなかった。

めでたしめでたし。=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́



オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)