Amazon EC2上で動かしているZabbixのテーブルサイズ推移を計測中です。
計測しているデータは
- MySQLテーブルのサイズ – information_schemaのdata_length値
- テーブルファイルのサイズ – Per-Tableテーブルスペースでの.idbファイルサイズ
それぞれMuninのmysql table size pluginとlog_sizes pluginを使っています。
Zabbixでの取得item数は110項目ほどで、9割方の項目がhistory=7/trends=365/delay=60の設定になっています。
1週間経過してのデータ量推移は以下のようになりました。全テーブル分のデータを取得しているのでグラフが冗長ですが、Zabbixがデータを累積するのはhistory系とtrends系のテーブルですので、そちらに着目していただけるとわかりやすいかと思います。
テーブルサイズ、ファイルサイズともに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.