プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

kzk benchの追試 このエントリーをはてなブックマークに追加

http://d.hatena.ne.jp/kzk/20060513

むかーし、極一部で話題になっていたkzk bench(CP速度対決ベンチ)について、時間の余裕ができたので追試した

なお、キャッシュを追い出さないと2番手以降が最初からキャッシュに乗っていて有利すぎるので、テスト用のシェルスクリプトはちょっと変えた(以下参照)

#!/bin/zsh -x

SRC=testfile1G
DST=testfile1G2
TIMEX=time
PREPARE='rm $DST;sync;sync;sync;sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"'
REPEAT=1

eval $PREPARE
(repeat $REPEAT $TIMEX ./rw_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./rw_fadv_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_sync_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_mun_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_sync_madv_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_mun_madv_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mw_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mw_madv_cp ${SRC} ${DST})



んで、結果は以下


+./test.sh:10> time ./rw_cp testfile1G testfile1G2
0.06user 2.17system 0:58.52elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+107minor)pagefaults 0swaps

+./test.sh:12> time ./rw_fadv_cp testfile1G testfile1G2
0.06user 2.38system 0:54.98elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+107minor)pagefaults 0swaps

+./test.sh:14> time ./mm_sync_cp testfile1G testfile1G2
0.11user 2.48system 1:43.94elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (35151major+489276minor)pagefaults 0swaps

+./test.sh:16> time ./mm_mun_cp testfile1G testfile1G2
0.10user 2.50system 1:42.32elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (35037major+489391minor)pagefaults 0swaps

+./test.sh:18> time ./mm_sync_madv_cp testfile1G testfile1G2
0.43user 3.52system 2:03.72elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8605major+515805minor)pagefaults 0swaps

+./test.sh:20> time ./mm_mun_madv_cp testfile1G testfile1G2
0.31user 3.36system 1:41.93elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8542major+515869minor)pagefaults 0swaps

+./test.sh:22> time ./mw_cp testfile1G testfile1G2
0.00user 2.27system 1:25.39elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (18497major+243773minor)pagefaults 0swaps

+./test.sh:24> time ./mw_madv_cp testfile1G testfile1G2
0.00user 2.94system 1:09.59elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8490major+253760minor)pagefaults 0swaps



以下、ここから分かる考察
・syncするとまじ遅い。(が、それはあたりまえなので気にしない)
・rw_cpはぜんぜんページフォルトしてない。これが速度の秘密っぽい
・mmap-mmapコピーはまじで性能悪い。びっくり
・madviceするとページフォルト減る。これが速度向上の理由っぽげ

と、いうわけで、最速のrw_cpと最遅のmm_mun_cp(あ、syncいれてるのは遅くてあたりまえだから除いた)で動作中のiostatとvmstatをじーーーと見てみる。

まず、rw_cp


[kosaki@sc420 ~]$ iostat /dev/sda 10 -m
Linux 2.6.18-53.el5xen (sc420) 2008年01月01日

avg-cpu: %user %nice %system %iowait %steal %idle
1.55 0.00 2.15 67.48 0.00 28.82

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 356.94 13.01 23.08 130 231

avg-cpu: %user %nice %system %iowait %steal %idle
1.75 0.00 3.20 68.87 0.05 26.13

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 360.50 18.93 19.40 189 194

avg-cpu: %user %nice %system %iowait %steal %idle
1.45 0.00 3.50 60.83 0.00 34.22

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 339.90 19.38 15.58 193 155




procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 5 266 3 0 377 0 0 6262 6791 533 563 1 2 10 88 0
0 2 266 4 0 374 0 0 11797 14728 650 863 1 7 35 58 0
0 2 266 4 0 383 0 0 9810 8648 598 732 2 4 34 61 0
0 2 266 4 0 383 0 0 11689 12560 595 795 1 6 41 52 0
0 3 266 3 0 382 0 0 10872 10546 597 779 1 5 40 54 0
1 2 266 2 0 383 0 0 10807 9652 583 779 1 4 36 58 0
1 3 266 3 0 381 0 0 10392 10254 590 786 2 5 39 55 0
0 0 266 4 0 381 0 0 5988 5431 407 559 1 3 61 35 0
0


procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free inact active si so bi bo in cs us sy id wa st
0 2 266 3 368 30 0 0 15119 11773 591 658 1 2 48 49 0
0 7 266 3 373 25 0 0 14971 21259 615 711 1 2 10 86 0
0 4 266 3 372 26 0 0 18725 19391 672 761 2 3 19 77 0
1 5 266 3 371 26 0 0 18352 19450 628 742 2 3 25 71 0
0 5 266 3 371 26 0 0 19425 18876 603 748 2 3 14 81 0
0 0 266 9 369 26 0 0 7363 13603 406 540 1 2 62 34 0
0


次はmm_mun_cp

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 378.59 11.45 12.67 114 127

avg-cpu: %user %nice %system %iowait %steal %idle
0.95 0.00 4.55 60.33 0.00 34.17

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 329.40 10.03 10.49 100 104

avg-cpu: %user %nice %system %iowait %steal %idle
1.75 0.00 4.36 54.78 0.00 39.11

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 319.60 10.41 9.51 104 95

avg-cpu: %user %nice %system %iowait %steal %idle
1.05 0.00 4.79 55.31 0.05 38.80

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 323.52 10.06 10.27 100 102


[kosaki@sc420 ~]$ vmstat 10 -S M
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 3 266 237 0 127 0 0 792 757 125 258 2 1 89 8 0
0 9 266 66 0 302 0 0 12087 15989 841 854 1 7 26 66 0
2 3 266 16 0 362 0 0 7506 6304 608 617 1 2 46 51 0
9 6 267 3 0 378 0 0 11665 12942 669 829 1 5 29 65 0
0 5 267 3 0 381 0 0 10360 9941 595 794 1 5 38 55 0
0



[kosaki@sc420 ~]$ vmstat 10 -S M -a
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free inact active si so bi bo in cs us sy id wa st
0 4 266 166 189 52 0 0 793 757 125 258 2 1 89 8 0
0 11 266 65 202 138 0 0 8628 15499 708 668 1 7 22 69 0
0 4 266 13 335 56 0 0 7524 6934 609 618 1 2 45 52 0
2 4 267 9 229 165 0 0 11502 12703 661 821 1 6 30 63 0
0 3 267 3 258 142 0 0 10362 9550 593 794 1 4 39 56 0
0


一見して分かるのはiostatのIO転送速度がバッチリ違うところであるが、これは結果であって原因ではない。
なので、vmstatのほうをじーーーーとみる。
すると面白いことが分かった。rw_cpのほうはキャッシュがほぼすべてinactiveリストに載っているが、mm_mun_cpのほうは1/3ぐらいがactiveリストに残っているのだ。

すると仮説としては、
・Linuxのくそ重いページ回収まわりが遅いのが原因である
・が、rw_cpは幸運なことに、read aheadによってキャッシュに乗ったことが原因で最初から
inactive listにのった。
 よって、たまたま、遅いルートに乗らなかった。

という仮説がうかぶ。
今度、シーケンシャルアクセスはactive listにのせないパッチを書いて試してみよう
関連記事


linux | 【2008-01-01(Tue) 22:23:27】 | Trackback:(1) | Comments:(0)
欝展開というやつですね。 改造しやすいようにと、最新カーネルビルドして再テストしたらめっさ速いんでやんの。 やる気なくすわー 2.6.24-rc6での結果は以下 [kosaki@sc420 copy]$ ./test...
【2008-01-02 Wed 01:55:27】 | 革命の日々!
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。