読者です 読者をやめる 読者になる 読者になる

EC2でMyISAMを検証してみた

MySQL

検証環境は以下の通り。

  • サーバ
  • クライアント
    • c1.xlarge(8コア/7GB)
    • CentOS 5.4
    • mysqlslap 1.0

始めにサーバをm1.large(2コア/7.5GB)にしてconcurrency=8、load-type=updateでmysqlslapを実行してみたら8,000qpsぐらいになった。


mysqlslap --no-defaults --auto-generate-sql --auto-generate-sql-add-autoincrement --engine=MyISAM --number-int-cols=3 --number-char-cols=8 --concurrency=8 --auto-generate-sql-execute-number=10000 --auto-generate-sql-load-type=update -h ip-XXX-XXX-XXX-XXX -u scott -ptiger --auto-generate-sql-write-number=10000

「qpsが高すぎないか?」と言われ、原因を推測してみる。
初期データが少すぎるのかと思ってauto-generate-sql-write-number=1000000にしてみたら、400qpsぐらいまで下がった。データファイルのサイズはおよそ1GBほど。


で、ファイルがメモリにさえ載ってればMyISAMで並列にUPDATEを走らせても8,000qpsぐらいになるのだろうかと思って、m2.4xlarge(8コア/64GB)使ったら、上限が12,000qpsぐらいまで上がった。


さらに、UPDATEとSELECTを並列で走らせたら結果が変わるかもと思い、試してみることに。mysqlslapでload-typeをmixedにするとSELECTとINSERTが半分ずつ走るので、ちょっと修正。

--- mysqlslap.c.orig    2010-06-04 00:50:21.000000000 +0900
+++ mysqlslap.c 2010-07-21 23:27:15.000000000 +0900
@@ -1323,7 +1323,8 @@
     {
       int coin= 0;

-      query_statements= build_insert_string();
+      //query_statements= build_insert_string();
+       query_statements= build_update_string();
       /*
         This logic should be extended to do a more mixed load,
         at the moment it results in "every other".
@@ -1334,7 +1335,8 @@
       {
         if (coin)
         {
-          ptr_statement->next= build_insert_string();
+          //ptr_statement->next= build_insert_string();
+          ptr_statement->next= build_update_string();
           coin= 0;e times against the server.
         }
         elselap [OPTIONS]

mysqlslapは融通の利かないとこもあるけど(複数クライアントからのauto-generate-sqlでの実行とか)、コードがいじりやすいのは良い。


以下のコマンドを3回ほど実行。


./mysqlslap --no-defaults --auto-generate-sql --auto-generate-sql-add-autoincrement --engine=MyISAM --number-int-cols=3 --number-char-cols=8 --concurrency=8 --auto-generate-sql-execute-number=10000 --auto-generate-sql-load-type=mixed -h ip-XXX-XXX-XXX-XXX -u scott -ptiger --auto-generate-sql-write-number=1000000

結果。

1回目 7645.3 qps
2回目 4197.5 qps
3回目 11776.8 qps

結果にムラはあるけどそれなりに高いスループット


所感。

  • ファイルがメモリに載っているのかどうかきちんと確認してない
  • 単にPKを使った使った参照/更新が速いのかも
    • 1クエリあたり8msecか。。。
  • instance storeを使ったんだけど、EBSだとまた結果が違ったかも
  • SuperSmackでも試してみたいところ
  • お財布が痛いです