Mar 012011
 

Amazon EC2上で動かしているZabbixのテーブルサイズ推移を計測中です。
計測しているデータは

  • MySQLテーブルのサイズ – information_schemaのdata_length値
  • テーブルファイルのサイズ – Per-Tableテーブルスペースでの.idbファイルサイズ

それぞれMuninのmysql table size pluginlog_sizes pluginを使っています。
Zabbixでの取得item数は110項目ほどで、9割方の項目がhistory=7/trends=365/delay=60の設定になっています。

1週間経過してのデータ量推移は以下のようになりました。全テーブル分のデータを取得しているのでグラフが冗長ですが、Zabbixがデータを累積するのはhistory系とtrends系のテーブルですので、そちらに着目していただけるとわかりやすいかと思います。

mysql_table_size推移

mysql_table_size推移


file_sizes推移

file_sizes推移

テーブルサイズ、ファイルサイズともにhistoryとhistory_uintが増加し続け、history保存期限の1週間を経過したところからほぼ横ばいになりました。
ちなみにHousekeepingFrequencyは1です(Ubuntu 10.10パッケージデフォルト)。

正直言うと、レコード追加と削除の繰り返しでテーブルの断片化が進み、テーブルサイズは横ばいだがファイルサイズは増え続けるような状況を予想していたのですが、削除レコードの領域も上手に再利用されているようです。
定期的にALTER TABLE ~ TYPE=InnoDBを実行して断片化解消しなきゃダメなのかな、と思っていたのですが、サイズ傾向だけで見る限りではそんな必要もなさそうです。InnoDBの断片化状況ってどうやったら判断できるんでしょう 😕

まぁ、単にデータ量だけで考えれば、これ以降はtrendsとtrends_uintがじわじわと増えていって、それも1年後に横ばいになるってことなのでしょうね 😉

EC2を1年以上継続利用する予定は今のところないのですが、気が向いたら1ヶ月後ぐらいに再度状況アップするかも知れません。

Sorry, the comment form is closed at this time.