ZABBIX-JP 1.4.6でのイベント表示に関して
FORUMにはいつもお世話になっております。
以前、「ZABBIXの設定について / 監視データ＞イベントの表示で負荷が大きく表示できません」にて、データが多い場合にイベントが表示が出来ないのは1.4.6で改善される、との回答をいただきました。
ZABBIX-JP版1.4.6がリリースされたので、rpm -Uvh でインストールしました。
しかし、イベント表示を行おうとすると1.4.5と同様にmysqlの負荷が急激に上昇したまま表示が行われません。
/usr/share/zabbix無いのevents.phpなどのファイルは、2008/07/23に更新されているのは確認しています。
バージョンアップ時には何か作業が必要なのでしょうか？
何か情報がありましたら、教えていただけますか。
kodai - 投稿数: 1341
こんにちは。
そうですか...。
/usr/share/zabbix/tr_events.phpのファイルは更新されているでしょうか？
また、<a href="http://www.zabbix.jp/modules/newbb/viewtopic.php?topic_id=127&forum=2">こちら</a>のalter tableは試されているでしょうか。
miko - 投稿数: 113
御回答いただき、有難うございます。
/usr/share/zabbixを確認したところ、tr_events.phpは 8月 18 03:36 でした。このためZABBIX-JP版と判断できます。
本番システムから検証システムにmysqldumpを使ったデータ移行を行ったため、optimizeやalter tableは行っていませんでした。
ただし、検証システム上のDBからテーブルを削除せずに登録したため、optimize table を行いましたが現象は変りませんでした。
また、drop table をしてから再度データをインポートしましたが、状況は変りませんでした。
全てのホストを無効にして、ZABBIXサーバーのみ有効の場合は問題なく表示されます。
また、イベント画面でホストをZABBIXサーバー選択状態にしておき、全てのホストを有効してからイベント画面を開くと、単一のホストのため、どのホストを選択しても問題なく表示されます。
大量のホストが対象となる場合に表示が遅くなるため、mysqlのJOINやソートのメモリ設定を変更すると早くなるのでしょうか。
または、ZABBIXが発行するクエリやインデックスなどを調整する必要があるのでしょうか
kodai - 投稿数: 1341
返信が遅くなりすいません。
データベースの負荷自体が高いのかもしれません。データベースが動作しているOSのロードアベレージやCPUのiowait値は高くなっていないでしょうか？定常的に高いようであれば、MySQLに割り当てるメモリ(innodb_buffer_pool_sizeやinnodb_log_file_size)を増やすと効果があると思います。
また、アイテムの数と監視間隔の設定はどのようになっているでしょうか？有効になっているアイテムの数はメニューから[レポート]->[ZABBIXサーバの状態]で確認できます。
miko - 投稿数: 113
御回答いただき、有難うございます。
データ量は次のとおりです。
ホスト数：447
アイテム数：1723
トリガー数：2139
イベント数 20661
アラート数 9342
更新間隔は30秒です。
検証サーバーではSNMPデータが取得できないため、sqlの負荷は10%以下で動いています。
/etc/my.cnfには、下記を設定しています。
innodb_buffer_pool_size = 256M
innodb_log_buffer_size = 16777216
innodb_log_file_size = 134217728
PHPを勉強していないのですがevents.phpとtr_events.phpを覗いたところ、DBからデータを抽出していると思われるselect文がありました。
where句を見たところ、itemidやtriggeridは有りますが時刻に関するものが見つけえられませんでした。
order by句にはclockがあるので時刻でのソートを行っているようです。
これからすると、全ての期間のデータを読み込んでいるため、処理が重くなっていると思われます。
where句にclockによる絞込みを追加することで、データ量が少なくなり処理が早くなるのではと考えたのですが、いかがでしょうか？
宜しく御願致します。
kodai - 投稿数: 1341
アイテムの数もそれほど多くないようですし、通常時のデータベースの負荷もそれほど高くないとなると、やはりWebインターフェースの処理の問題の可能性が高そうですね。
1.4.6-1でtr_events.phpのデータベースアクセス処理を「すべて読み込んで表示する」から「行ごとに読み込んで表示する」ように修正は入れているのですが、他にも同じような処理があるのかもしれません。
こちらでも大量のイベントが保存されている環境で試してみます。
ちなみに、根本的な解説策にはならないのですが、1.6ではイベント表示画面が大幅に変わって期間ごとに指定できるようになっているため、表示速度は改善されています。
miko - 投稿数: 113
御回答いただき、有難うございます。
検証宜しくお願いします。
とりあえずは、URLに events.php?groupid=0&hostid=10056 などのようにホストIDをつけることで、一つのデバイスを開くことができました。
あとは全てのデバイスを表示しないようにして、表示しておくようにしました。
1.6への移行に関しては、ZABBIX-JPがリリースされてからと考えているところです。
宜しくお願いします。
miko - 投稿数: 113
ZABBIX-JPから1.4.6-2がリリースされましたので、バージョンアップしてみました。
イベント表示で全てのグループ・全てのホストを対象とした場合、1.4.6-1と同様に表示できませんでした。
ファイルのタイムスタンプを確認したところ、下記のようにtr_events.phpが更新されていました。
events.php：7月 23 2008
tr_events.php：9月 27 16:39
宜しく御願致します。
kodai - 投稿数: 1341
こんにちは。遅くなってしまいました。
こちらにある環境(イベント数706343)で試してみましたが、やはり遅いですね。可能ならばMySQLの設定に以下のスロークエリログの設定を行って、時間のかかっているクエリのログを教えていただけませんか？
[coce]log-slow-queries
long-query-time=2
log-long-format<code>
ログは標準なら/var/lib/mysql/<データベース名>-slow.logに出力されると思います。
miko - 投稿数: 113
御回答有難うございます。
検証が遅くなってしまいましたが、次のようになりました。
/etc/my.cnfの[mysqld]に、下記を追加しました。logファイルのパスを書かないと、ファイルが作成されませんでした。
log-slow-queries = /var/lib/mysql/mysql-slow.log
long-query-time=2
log-long-format
ログファイルの結果は、下記のとおりです。
SELECT DISTINCT t.triggerid,t.priority,t.description,t.expression,h.host FROM triggers t, functions f, items i, hosts h , hosts_groups hg WHERE (t.triggerid div 100000000000000) in (0) AND t.triggerid=f.triggerid and f.itemid=i.itemid AND i.hostid=h.hostid and h.hostid in ( [i]全てのホストIDが列挙[/i] ) AND h.status=0;
宜しくお願いします。
miko - 投稿数: 113
ログファイルの頭部分を記載していませんでしたので、追記します。
# Time: 091013 13:18:33
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 583 Lock_time: 0 Rows_sent: 10056 Rows_examined: 41679
use zabbix;
宜しくお願いします。
KAZ - 投稿数: 1085
mikoさん
横から失礼します。
かなり遅いですね…
my.cnfの内容とdatadir配下とzabbixで使用しているディレクトリのファイル情報をお教え願えませんか？
miko - 投稿数: 113
御回答頂き有難うございます。
datadirとzabbixのディレクトリのファイル情報ですが、/var/lib/mysqlと/usr/share/zabbixのファイル名一覧でよいでしょうか？
タイムスタンプなどを含む ls -l の結果のほうが良いでしょうか？
本番環境でなくテスト環境で検証していますが、VMwareServer2.01上でCentOS5.3をメモリ1Gで動かしています。
メモリ割当を2Gにしましたが、同じような状況でした。
# Time: 091013 15:12:12
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 578 Lock_time: 0 Rows_sent: 10056 Rows_examined: 41679
他の画面でもslow-queryが発生していましたので、記載します。
# Time: 091013 14:48:03
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 3 Lock_time: 0 Rows_sent: 10075 Rows_examined: 41848
use zabbix;
select distinct t.triggerid,t.expression,t.description,t.status,t.priority,t.value,t.url,t.comments from hosts h,items i,triggers t,functions f where f.triggerid=t.triggerid and f.itemid=i.itemid and h.hostid=i.hostid and i.nextcheck+i.delay<1255412880 and i.key_<>'status' and h.status not in (4,3) and i.type not in (2);
# Time: 091013 14:58:06
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 17 Lock_time: 0 Rows_sent: 100 Rows_examined: 162148
select distinct a.alertid,a.clock,mt.description,a.sendto,a.subject,a.message,a.status,a.retries,a.error from alerts a,media_type mt,functions f,items i where mt.mediatypeid=a.mediatypeid and a.triggerid=f.triggerid and f.itemid=i.itemid and i.hostid not in (-1) and (a.alertid div 100000000000000) in (0) order by a.clock desc limit 100;
/etc/my.cnfは、下記のようになっています。
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
innodb_file_per_table
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 20971520
innodb_log_buffer_size = 16777216
innodb_log_file_size = 134217728
log-bin=mysql-bin
table_cache = 200
default-table-type = innodb
log-slow-queries = /var/lib/mysql/mysql-slow.log
long-query-time=2
log-long-format
[mysql]
default-character-set = utf8
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
宜しくお願いします。
KAZ - 投稿数: 1085
mikoさん
できれば、ls -lが良いです。
miko - 投稿数: 113
御回答頂き有難うございます。
ファイルに関しては、次のようになります。
/var/lib/mysqlで実行
[root@centos53 mysql]# ls -l
合計 293884
-rw-rw---- 1 mysql mysql 134217728 10月 13 16:38 ib_logfile0
-rw-rw---- 1 mysql mysql 134217728 10月 13 14:51 ib_logfile1
-rw-rw---- 1 mysql mysql 27262976 10月 13 16:38 ibdata1
drwx------ 2 mysql mysql 4096 9月 11 16:14 mysql
-rw-rw---- 1 mysql mysql 4888338 10月 13 16:38 mysql-bin.000038
-rw-rw---- 1 mysql mysql 19 10月 13 16:36 mysql-bin.index
-rw-rw---- 1 mysql mysql 13198 10月 13 16:36 mysql-slow.log
srwxrwxrwx 1 mysql mysql 0 10月 13 14:47 mysql.sock
drwx------ 2 mysql mysql 4096 7月 16 14:57 test
drwx------ 2 mysql mysql 4096 9月 11 16:40 zabbix
[root@centos53 mysql]# ls -l zabbix/
合計 3774004
-rw-rw---- 1 mysql mysql 8716 9月 11 16:14 acknowledges.frm
-rw-rw---- 1 mysql mysql 147456 9月 11 16:14 acknowledges.ibd
-rw-rw---- 1 mysql mysql 8714 9月 11 16:14 actions.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:14 actions.ibd
-rw-rw---- 1 mysql mysql 9002 9月 11 16:14 alerts.frm
-rw-rw---- 1 mysql mysql 25165824 10月 13 16:37 alerts.ibd
-rw-rw---- 1 mysql mysql 8684 9月 11 16:14 applications.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:14 applications.ibd
-rw-rw---- 1 mysql mysql 8748 9月 11 16:14 auditlog.frm
-rw-rw---- 1 mysql mysql 9437184 10月 13 14:56 auditlog.ibd
-rw-rw---- 1 mysql mysql 8730 9月 11 16:14 conditions.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:15 conditions.ibd
-rw-rw---- 1 mysql mysql 8818 9月 11 16:14 config.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:15 config.ibd
-rw-rw---- 1 mysql mysql 61 7月 16 14:58 db.opt
-rw-rw---- 1 mysql mysql 8746 9月 11 16:14 dchecks.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:15 dchecks.ibd
-rw-rw---- 1 mysql mysql 8734 9月 11 16:14 dhosts.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:15 dhosts.ibd
-rw-rw---- 1 mysql mysql 8738 9月 11 16:14 drules.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:15 drules.ibd
-rw-rw---- 1 mysql mysql 8836 9月 11 16:14 dservices.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:15 dservices.ibd
-rw-rw---- 1 mysql mysql 8782 9月 11 16:14 events.frm
-rw-rw---- 1 mysql mysql 14680064 10月 13 16:37 events.ibd
-rw-rw---- 1 mysql mysql 8764 9月 11 16:14 functions.frm
-rw-rw---- 1 mysql mysql 10485760 10月 13 16:37 functions.ibd
-rw-rw---- 1 mysql mysql 8962 9月 11 16:14 graphs.frm
-rw-rw---- 1 mysql mysql 163840 10月 1 15:09 graphs.ibd
-rw-rw---- 1 mysql mysql 8898 9月 11 16:14 graphs_items.frm
-rw-rw---- 1 mysql mysql 212992 10月 1 15:09 graphs_items.ibd
-rw-rw---- 1 mysql mysql 8596 9月 11 16:14 groups.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:15 groups.ibd
-rw-rw---- 1 mysql mysql 8642 9月 11 16:14 help_items.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:15 help_items.ibd
-rw-rw---- 1 mysql mysql 8628 9月 11 16:14 history.frm
-rw-rw---- 1 mysql mysql 465567744 10月 13 16:37 history.ibd
-rw-rw---- 1 mysql mysql 8766 9月 11 16:17 history_log.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:18 history_log.ibd
-rw-rw---- 1 mysql mysql 8628 9月 11 16:17 history_str.frm
-rw-rw---- 1 mysql mysql 79691776 10月 13 16:10 history_str.ibd
-rw-rw---- 1 mysql mysql 8688 9月 11 16:18 history_str_sync.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:18 history_str_sync.ibd
-rw-rw---- 1 mysql mysql 8688 9月 11 16:18 history_sync.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:18 history_sync.ibd
-rw-rw---- 1 mysql mysql 8654 9月 11 16:18 history_text.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:18 history_text.ibd
-rw-rw---- 1 mysql mysql 8628 9月 11 16:18 history_uint.frm
-rw-rw---- 1 mysql mysql 3053453312 10月 13 16:38 history_uint.ibd
-rw-rw---- 1 mysql mysql 8688 9月 11 16:39 history_uint_sync.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:40 history_uint_sync.ibd
-rw-rw---- 1 mysql mysql 8908 9月 11 16:39 hosts.frm
-rw-rw---- 1 mysql mysql 196608 10月 13 16:36 hosts.ibd
-rw-rw---- 1 mysql mysql 8644 9月 11 16:39 hosts_groups.frm
-rw-rw---- 1 mysql mysql 327680 10月 1 15:07 hosts_groups.ibd
-rw-rw---- 1 mysql mysql 8952 9月 11 16:39 hosts_profiles.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 hosts_profiles.ibd
-rw-rw---- 1 mysql mysql 8656 9月 11 16:39 hosts_templates.frm
-rw-rw---- 1 mysql mysql 163840 10月 1 15:09 hosts_templates.ibd
-rw-rw---- 1 mysql mysql 8682 9月 11 16:39 housekeeper.frm
-rw-rw---- 1 mysql mysql 262144 10月 13 10:54 housekeeper.ibd
-rw-rw---- 1 mysql mysql 8850 9月 11 16:39 httpstep.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 httpstep.ibd
-rw-rw---- 1 mysql mysql 8686 9月 11 16:39 httpstepitem.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 httpstepitem.ibd
-rw-rw---- 1 mysql mysql 9048 9月 11 16:39 httptest.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 httptest.ibd
-rw-rw---- 1 mysql mysql 8686 9月 11 16:39 httptestitem.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 httptestitem.ibd
-rw-rw---- 1 mysql mysql 8682 9月 11 16:39 ids.frm
-rw-rw---- 1 mysql mysql 98304 10月 13 16:37 ids.ibd
-rw-rw---- 1 mysql mysql 8668 9月 11 16:39 images.frm
-rw-rw---- 1 mysql mysql 147456 9月 11 16:40 images.ibd
-rw-rw---- 1 mysql mysql 18172 9月 11 16:39 items.frm
-rw-rw---- 1 mysql mysql 14680064 10月 13 16:37 items.ibd
-rw-rw---- 1 mysql mysql 8652 9月 11 16:39 items_applications.frm
-rw-rw---- 1 mysql mysql 393216 9月 11 16:40 items_applications.ibd
-rw-rw---- 1 mysql mysql 8682 9月 11 16:39 mappings.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 mappings.ibd
-rw-rw---- 1 mysql mysql 8784 9月 11 16:39 media.frm
-rw-rw---- 1 mysql mysql 131072 9月 28 13:38 media.ibd
-rw-rw---- 1 mysql mysql 13022 9月 11 16:39 media_type.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 media_type.ibd
-rw-rw---- 1 mysql mysql 8790 9月 11 16:39 node_cksum.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 node_cksum.ibd
-rw-rw---- 1 mysql mysql 8808 9月 11 16:39 node_configlog.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:40 node_configlog.ibd
-rw-rw---- 1 mysql mysql 9072 9月 11 16:39 nodes.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 nodes.ibd
-rw-rw---- 1 mysql mysql 8810 9月 11 16:39 operations.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 operations.ibd
-rw-rw---- 1 mysql mysql 8704 9月 11 16:39 profiles.frm
-rw-rw---- 1 mysql mysql 114688 10月 13 16:34 profiles.ibd
-rw-rw---- 1 mysql mysql 8700 9月 11 16:39 rights.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 rights.ibd
-rw-rw---- 1 mysql mysql 8662 9月 11 16:39 screens.frm
-rw-rw---- 1 mysql mysql 98304 9月 29 14:23 screens.ibd
-rw-rw---- 1 mysql mysql 9054 9月 11 16:39 screens_items.frm
-rw-rw---- 1 mysql mysql 98304 10月 1 15:09 screens_items.ibd
-rw-rw---- 1 mysql mysql 8684 9月 11 16:39 service_alarms.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:40 service_alarms.ibd
-rw-rw---- 1 mysql mysql 8826 9月 11 16:39 services.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 services.ibd
-rw-rw---- 1 mysql mysql 8686 9月 11 16:39 services_links.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:40 services_links.ibd
-rw-rw---- 1 mysql mysql 8732 9月 11 16:39 services_times.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 services_times.ibd
-rw-rw---- 1 mysql mysql 8646 9月 11 16:39 sessions.frm
-rw-rw---- 1 mysql mysql 98304 10月 13 16:34 sessions.ibd
-rw-rw---- 1 mysql mysql 8710 9月 11 16:39 slides.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 slides.ibd
-rw-rw---- 1 mysql mysql 8636 9月 11 16:39 slideshows.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 slideshows.ibd
-rw-rw---- 1 mysql mysql 8802 9月 11 16:39 sysmaps.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 sysmaps.ibd
-rw-rw---- 1 mysql mysql 8984 9月 11 16:39 sysmaps_elements.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 sysmaps_elements.ibd
-rw-rw---- 1 mysql mysql 8898 9月 11 16:39 sysmaps_links.frm
-rw-rw---- 1 mysql mysql 98304 9月 11 16:40 sysmaps_links.ibd
-rw-rw---- 1 mysql mysql 8744 9月 11 16:39 trends.frm
-rw-rw---- 1 mysql mysql 167772160 10月 13 16:38 trends.ibd
-rw-rw---- 1 mysql mysql 8672 9月 11 16:40 trigger_depends.frm
-rw-rw---- 1 mysql mysql 131072 9月 11 16:40 trigger_depends.ibd
-rw-rw---- 1 mysql mysql 8982 9月 11 16:40 triggers.frm
-rw-rw---- 1 mysql mysql 11534336 10月 13 16:37 triggers.ibd
-rw-rw---- 1 mysql mysql 8862 9月 11 16:40 users.frm
-rw-rw---- 1 mysql mysql 114688 9月 28 13:38 users.ibd
-rw-rw---- 1 mysql mysql 8628 9月 11 16:40 users_groups.frm
-rw-rw---- 1 mysql mysql 114688 9月 28 13:38 users_groups.ibd
-rw-rw---- 1 mysql mysql 8598 9月 11 16:40 usrgrp.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 usrgrp.ibd
-rw-rw---- 1 mysql mysql 8602 9月 11 16:40 valuemaps.frm
-rw-rw---- 1 mysql mysql 114688 9月 11 16:40 valuemaps.ibd
/usr/share/zabbixは、別に記載します。
宜しくお願いします。
miko - 投稿数: 113
引き続いて、/usr/share/zabbix/のファイル一覧を記載します。
[root@centos53 mysql]# ls -l /usr/share/zabbix/
合計 680
-rw-r--r-- 1 root root 3910 7月 23 2008 acknow.php
-rw-r--r-- 1 root root 13374 7月 23 2008 actionconf.php
-rw-r--r-- 1 root root 2328 7月 23 2008 actions.php
drwxr-xr-x 2 root root 4096 9月 28 13:16 audio
-rw-r--r-- 1 root root 3021 7月 23 2008 audit.php
-rw-r--r-- 1 root root 2517 7月 23 2008 chart.php
-rw-r--r-- 1 root root 3502 7月 23 2008 chart2.php
-rw-r--r-- 1 root root 3622 7月 23 2008 chart3.php
-rw-r--r-- 1 root root 5885 7月 23 2008 chart4.php
-rw-r--r-- 1 root root 5544 7月 23 2008 chart5.php
-rw-r--r-- 1 root root 3108 7月 23 2008 chart_sla.php
-rw-r--r-- 1 root root 8387 7月 23 2008 charts.php
drwxr-xr-x 2 root root 4096 9月 28 13:16 conf
-rw-r--r-- 1 root root 11487 7月 23 2008 config.php
-rw-r--r-- 1 root root 31263 7月 23 2008 css.css
-rw-r--r-- 1 root root 3808 7月 23 2008 discovery.php
-rw-r--r-- 1 root root 8163 7月 23 2008 discoveryconf.php
-rw-r--r-- 1 root root 6089 7月 23 2008 events.php
-rw-r--r-- 1 root root 12729 7月 23 2008 exp_imp.php
-rw-r--r-- 1 root root 13807 7月 23 2008 graphs.php
-rw-r--r-- 1 root root 16097 7月 23 2008 history.php
-rw-r--r-- 1 root root 3297 7月 23 2008 hostprofiles.php
-rw-r--r-- 1 root root 37302 7月 23 2008 hosts.php
-rw-r--r-- 1 root root 17952 9月 27 16:39 httpconf.php
-rw-r--r-- 1 root root 7624 7月 23 2008 httpdetails.php
-rw-r--r-- 1 root root 9436 7月 23 2008 httpmon.php
-rw-r--r-- 1 root root 2702 7月 23 2008 image.php
drwxr-xr-x 6 root root 4096 7月 23 2008 images
drwxr-xr-x 4 root root 4096 9月 28 13:16 include
-rw-r--r-- 1 root root 3367 7月 23 2008 index.php
-rw-r--r-- 1 root root 2037 7月 23 2008 instal.php
-rw-r--r-- 1 root root 33120 9月 27 16:39 items.php
drwxr-xr-x 2 root root 4096 9月 28 13:16 js
-rw-r--r-- 1 root root 13269 7月 23 2008 latest.php
-rw-r--r-- 1 root root 8481 9月 27 16:39 map.php
-rw-r--r-- 1 root root 3291 7月 23 2008 maps.php
-rw-r--r-- 1 root root 5627 7月 23 2008 media_types.php
-rw-r--r-- 1 root root 5066 7月 23 2008 nodes.php
-rw-r--r-- 1 root root 4875 7月 23 2008 overview.php
-rw-r--r-- 1 root root 25734 7月 23 2008 popup.php
-rw-r--r-- 1 root root 5725 7月 23 2008 popup_gitem.php
-rw-r--r-- 1 root root 5017 7月 23 2008 popup_httpstep.php
-rw-r--r-- 1 root root 3405 7月 23 2008 popup_media.php
-rw-r--r-- 1 root root 3900 7月 23 2008 popup_right.php
-rw-r--r-- 1 root root 10137 7月 23 2008 popup_trexpr.php
-rw-r--r-- 1 root root 2798 7月 23 2008 popup_users.php
-rw-r--r-- 1 root root 2908 7月 23 2008 popup_usrgrp.php
-rw-r--r-- 1 root root 3261 7月 23 2008 profile.php
-rw-r--r-- 1 root root 4397 7月 23 2008 queue.php
-rw-r--r-- 1 root root 2589 7月 23 2008 report1.php
-rw-r--r-- 1 root root 5814 7月 23 2008 report2.php
-rw-r--r-- 1 root root 5539 7月 23 2008 report3.php
-rw-r--r-- 1 root root 6016 7月 23 2008 report4.php
-rw-r--r-- 1 root root 3223 7月 23 2008 report5.php
-rw-r--r-- 1 root root 9940 7月 23 2008 screenconf.php
-rw-r--r-- 1 root root 4619 7月 23 2008 screenedit.php
-rw-r--r-- 1 root root 6229 7月 23 2008 screens.php
-rw-r--r-- 1 root root 4172 7月 23 2008 services.php
-rw-r--r-- 1 root root 26074 7月 23 2008 services_form.php
-rw-r--r-- 1 root root 4356 7月 23 2008 setup.php
-rw-r--r-- 1 root root 6837 7月 23 2008 srv_status.php
-rw-r--r-- 1 root root 10590 7月 23 2008 sysmap.php
-rw-r--r-- 1 root root 4515 7月 23 2008 sysmaps.php
-rw-r--r-- 1 root root 2720 7月 23 2008 tr_comments.php
-rw-r--r-- 1 root root 5264 9月 27 16:39 tr_events.php
-rw-r--r-- 1 root root 15151 7月 23 2008 tr_status.php
-rw-r--r-- 1 root root 16947 7月 23 2008 triggers.php
-rw-r--r-- 1 root root 17681 7月 23 2008 users.php
-rw-r--r-- 1 root root 1692 7月 23 2008 vtext.php
宜しくお願いします。
KAZ - 投稿数: 1085
mikoさん
ファイルサイズ的にはかなり小さいように思えます…
innodb_file_per_tableも有効なようです。
気になる点として…
my.cnfに設定されている「innodb_buffer_pool_size 」デフォルト512MBだったはずなのですが、小さく絞られてます。
大きくしないといけないところなんですが…(汗)
下記のURL名前の通り、5分でInnoDBのことが良くわかります。
[url=http://dsas.blog.klab.org/archives/50860867.html]DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！[/url]
上のサイトにもあるのですが、innodb_buffer_pool_sizeを大きくして、innodb_log_file_size × innodb_log_files_in_group
< innodb_buffer_pool_size になれば良いかと。
miko - 投稿数: 113
御回答頂き有難うございました。
提示していただいたサイトは何度か見ておりました。
これを参考に、本番サーバーでは2Gメモリなので768Mに設定していたのですが、VMware上のサーバーでは1Gメモリなので絞っていました。
早速1Gに変更しましたが、あまり変りませんでした。
show variables like 'Inno_%';
innodb_buffer_pool_size | 1073741824
slow-queryのログ
# Time: 091013 17:46:41
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 582 Lock_time: 0 Rows_sent: 10056 Rows_examined: 41679
Mysql5.0のinnodb_buffer_pool_size初期値を調べてみました。
mysqlを停止して、/etc/my.confで次のパラメータをコメントアウト
innodb_buffer_pool_size = 1024M
innodb_additional_mem_pool_size = 20971520
innodb_log_buffer_size = 16777216
innodb_log_file_size = 134217728
/var/lib/mysqlのib_logfile0とib_logfile1を削除し、mysqlを起動
show variables like 'Inno_%';で確認したところ、あまり大きくは有りませんでした。
| innodb_buffer_pool_size | 8388608
| innodb_log_buffer_size | 1048576 |
| innodb_log_file_size | 5242880
innodb_log関係も大きくしてみましたが、あまり変りませんでした。
| innodb_buffer_pool_size | 1073741824
| innodb_log_buffer_size | 268435456
| innodb_log_file_size | 268435456
# Time: 091013 18:35:26
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 589 Lock_time: 0 Rows_sent: 10056 Rows_examined: 71670761
宜しく御願致します。
KAZ - 投稿数: 1085
mikoさん
私はPC上にVMWare Workstaion6.5.2でCentOS5.3入れてる環境ですが…
普通のマシンに比べれば遅いですが、mikoさんが書かれているレベルまでは遅くないと思います。
メモリは物理3.25GBで、VMWareに1.5GB渡しています。(以前は2GB)
CPUはCore2 DUO 2.13GHzです。
※：余りメモリをVMWareに渡しすぎると本体側がswapし、遅くなります。
OSにもよりますが、WindowsXPなら512MB〜1024MBは残しておいてあげたいかと。
後、VMWare Workstaion6.5.2ですが、VMWareのディスクの最適化するとパフォーマンスが良くなったことがあります。
下記、私の環境の設定です。
現在はzabbix環境ではないですがzabbix-jpの1.4.5のテストに使ったり、20GBのzabbixデータ戻し実験に使ったりしています。
<code>
[root@xxxxxxx ~]# free
total used free shared buffers cached
Mem: 1355776 1113420 242356 0 54924 837948
-/+ buffers/cache: 220548 1135228
Swap: 1048568 0 1048568
[root@pits131 ~]# service mysqld start
MySQL を起動中: [ OK ]
[root@xxxxxxx ~]# free
total used free shared buffers cached
Mem: 1355776 1225948 129828 0 55000 838416
-/+ buffers/cache: 332532 1023244
Swap: 1048568 0 1048568
[root@xxxxxxx ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
old_passwords=1
#zabbix-jp
default-character-set=utf8
skip-character-set-client-handshake
sort_buffer_size=2M
read_rnd_buffer_size=1M
join_buffer_size=256K
read_buffer_size=1MB
table_cache=1024
max_connections=100
thread_cache_size=100
innodb_file_per_table
innodb_buffer_pool_size=1024M
innodb_log_file_size=256M
innodb_log_files_in_group=2
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
</code>
miko - 投稿数: 113
御回答頂き有難うございました。
ベースマシンはPentiumD940+3.6GメモリでVMwareServer2.01を動かしています。
仮想マシン稼働中の空きメモリは、800M程度です。
ディスクの最適化は別途行ってみます。
CentOS5.3上でZABBIX動作中のメモリは、下記のとおりです。
[root@centos53 mysql]# free
total used free shared buffers cached
Mem: 2075556 948944 1126612 0 35892 344484
-/+ buffers/cache: 568568 1506988
Swap: 1572856 0 1572856
Mysqlのパラメーターが下記のとおりだったので、KAZさんの設定に合わせてみましたが、イベント表示はあまり変りませんでした。
| join_buffer_size | 131072 |
| read_buffer_size | 131072 |
| table_cache | 200 |
| thread_cache_size | 0 |
# Time: 091014 10:14:28
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 590 Lock_time: 0 Rows_sent: 10056 Rows_examined: 41679
ただ通常時のMysqlのCPU負荷がかなり下がったようなので、本番系に適用して、そちらでのイベント表示を確認してみます。
宜しくお願いします。
KAZ - 投稿数: 1085
mikoさん
遅いSQLを試してみました。
〜今年の５月に作った実際の環境での検証 zabbix1.4.6-2〜
検索件数が余り多くないので比較にならないような…
〜去年の９月に作った実際の環境での検証 zabbix1.4.2〜
データは４０日保存で、週次でdatabaseの再編(ALTER TABLE)をしています。また、再編前にdatabseをダンプしてます。
１ヶ月以上過去のデータを見る場合は別環境にバックアップしたデータを戻して見る運用としています。
mikoさんの環境と比べるとイベントの件数がかなり違います。
※：41,679件が対象で、10,056件ヒットしてます。
SQLにhistoryテーブルとかないので保存期間は関係ないと思うのですが…
気になるのはitemsやtriggersテーブルでしょうか…
itemやtriggerの数はどれくらいでしょうか？
miko - 投稿数: 113
御回答頂き有難うございます。
また、検証をいろいろと行っていただき有難うございます。
本番１の環境から持ってきたVMwareで検証データは、次のとおりです。
ZABBIXサーバの起動 いいえ
ホスト数 (有効/無効/テンプレート/削除済) 514(448/28/38/0)
アイテム数 (有効/無効/取得不可)[トラッパー] 10121(603/8279/1239)[0]
トリガー数 (有効/無効)[障害/不明/正常] 1013(1012/1)[1/978/33]
イベント数 40028
アラート数 37594
本番２の環境に関しては、次のとおりです。こちはVMwareESX3.5上でCentOS5.3を2Gメモリで動かしています。
ホスト数 (有効/無効/テンプレート/削除済) 73(29/5/39/0)
アイテム数 (有効/無効/取得不可)[トラッパー] 2604(1257/1240/107)[0]
トリガー数 (有効/無効)[障害/不明/正常] 913(913/0)[0/416/497]
イベント数 3483
アラート数 168
こちらはMySQLの設定を変更したところ、総データ数が少ないですが以前より表示が速くなりました。
それでもSlow-queryには記載されています。MySQLの設定を変更する前にSlow-queryを取っていなかったので、比較が出来ませんでした。
# Time: 091014 11:30:27
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 5 Lock_time: 0 Rows_sent: 2150 Rows_examined: 9181
SELECT DISTINCT t.triggerid,t.priority,t.description,t.expression,h.host FROM triggers t, functions f, items i, hosts h , hosts_groups hg WHERE (t.triggerid div 100000000000000) in (0) AND t.triggerid=f.triggerid and f.itemid=i.itemid AND i.hostid=h.hostid and h.hostid in ( [i]全ホストID[/i] ) AND h.status=0;
本番１に関しては、自分の判断だけでMySQLを止められないため、許可がおりたら設定を変更しみます。
宜しくお願いします。
KAZ - 投稿数: 1085
mikoさん
zabbixのマニュアル「3.2.1 ハードウェア要件」という章があるのですが、上記は『大規模』に分類され構成になるかと。
VMWare上での検証はちょっと厳しいかもしれません。
上記は『中規模』に分類され構成になるかと。
VMWare上で「Query_time: 5」は許容圏内かと(汗)
zabbixのマニュアルは本家にあります。(1.4系は日本語版もあります。)
[url=http://www.zabbix.com/jp/documentation.php]Homepage of ZABBIX :: An Enterprise-Class Open Source Distributed Monitoring Solution[/url]
後はSQLを見る限り、無効なアイテムで抜ける物は抜いたほうが速くなると思います。もちろんホストもトリガーも同様です。
miko - 投稿数: 113
御回答頂き有難うございます。
日本語版のマニュアルには設定でお世話になっていますが、マニュアルの要件は見落としていました。
なるほど、本番１の監視数は大規模になりますね。
監視対象のホストのうち大部分がpingによる死活監視なので、そこまで負荷かかると思っていませんでしたが、データ抽出の点から考えると、総ホスト数が影響しするので注意します。
本番２のVMwareは、ホストCPUがXeon L5320 2個なので、他に負荷の軽いサーバーが3台動いていますが余裕だと思っていました。
ただVMwareのI/Oパフォーマンスを考えると、それなりの制限があるのですね。
アイテム・トリガーに関しては、テンプレートでの割当を行っているので、無効や取得不可をどうするか検討してみます。
有難うございました。
miko - 投稿数: 113
本番１環境（Pentium4 3.4G、メモリ2G)のMySQL設定を変更しましたが、状況はあまり変りませんでした。
innodb_buffer_pool_size = 768M
innodb_additional_mem_pool_size = 20M
innodb_log_buffer_size = 256M
innodb_log_file_size = 256M
sort_buffer_size = 2M
read_rnd_buffer_size = 2M
join_buffer_size = 1M
read_buffer_size = 2M
table_cache = 1024
thread_cache = 100
# Time: 091014 14:59:34
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 555 Lock_time: 0 Rows_sent: 9829 Rows_examined: 40767
宜しくお願いします。
KAZ - 投稿数: 1085
mikoさん
多分、(無効な)アイテム数が多すぎな様な…
後、「取得不可」は無効にした方が良いかと…
SQLも無効なitemやtriggerをハジイテないのがガンかと…
JOINを使ってテーブル結合し、結合時にhostsやitemsやtriggersを有効なものだけに絞り込めば問題なくなると思うのですが、そこまでソースを読み込んでません。
申し訳ありません。m(__)m
miko - 投稿数: 113
御回答頂き有難うございます。
提示していただきましたように、アイテムやトリガーなどの無効や取得不可を調整していきたいと思います。（本番サーバーなら調整しなくてもとは思いましたが、甘かったです）
クエリに関しては、イベントの発生時間でインデックスを作り表示する100件だけ抜ければ早いとは思うのですが、難しいものですね。
有難うございました。
KAZ - 投稿数: 1085
mikoさん
SQLチューニングができるかと、チェックしていて変な個所見つけました。(汗)
hostsとhosts_groupsの表結合条件がない…
↓こんなのが必要なはず。
<code>h.hostid=hg.hostid</code>
なくても表示があってるってことは、不要なテーブルをくっつけてる？
となると、zabbix-1.4.6\frontends\php\include\events.inc.phpの54行目をコメントアウトしたら速くなったりするかも…
※：49行目は必要なので、消さないでください。
KAZ - 投稿数: 1085
mikoさん
すいません。
間違っているの54行目じゃなくて、55行目っぽいです。m(__)m
〜\zabbix-1.4.6\frontends\php\include\events.inc.phpの38行目から67行目が該当のSQL文作成して実行する流れなのですが、43行目〜56行目の判定をよく読むと下記を判定しているように見えます。
■イベントの画面 右上のドロップダウンの選択
１．「ホスト」で対象を選択(”全て”を選ばない）
２．「ホスト」で”全て”を選択、「グループ」で対象を選択(”全て”を選ばない）
３．「ホスト」「グループ」で”全て”を選択
元ソースは↓なのですが…
<code>
$sql_cond = " and h.hostid in (".$availiable_hosts.") ";
</code>
↓が正しいような…
<code>
$sql_cond = " and h.hostid=hg.hostid and h.hostid in (".$availiable_hosts.") and hg.groupid in (".$availiable_groups.") ";
</code>
使っている1.4.6の環境で上記通りに修正してみました。
動作は問題ないのですが、データ量が少ないのでパフォーマンスはわからない状態です。
kodai - 投稿数: 1341
だいぶんと出遅れました (汗
KAZさん、フォロー＆SQLの調査ありがとうございます。
こちらでも7万件のイベントがあるZABBIXサーバがありますのでSQLを変更して試してみます。
ところで、その7万件のイベントがあるサーバなのですが、mikoさんに調査頂いたのと同じslowqueryログが出ていますので、遅い箇所はその部分と見て間違いなさそうです。
miko - 投稿数: 113
御回答頂き有難うございました。
提示していただきました、ZABBIXディレクトリのinclude\events.inc.php を変更しました。
変更前
$sql_cond = " and h.hostid in (".$availiable_hosts.") ";
変更後
$sql_cond = " and h.hostid=hg.hostid and h.hostid in (".$availiable_hosts.") and hg.groupid in (".$availiable_groups.") ";
イベントを表示したところ数秒で完了し、表次ページの切替も数秒です。これで安心して運用することが出来ます。
Slow-queryログを見たところ、次のようになっていました。
# Time: 091016 13:03:34
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 3 Lock_time: 0 Rows_sent: 10056 Rows_examined: 92538
皆様には大変お世話になりました。
今後とも宜しくお願いします。
KAZ - 投稿数: 1085
mikoさん
良かったです。
1.6系は1.6.6で対応されているようです。
※：但し、修正方法が異なっていました。
1.6.6ではグループ、ホストに「全て」を選択した場合、hosts_groupsテーブルを結合しないようにしていました。
理由は多分、ホストグループの無効と言う状態は無い為です。
※：ホストグループで無効を実行するとホストグループに属するホストが無効になります。
パフォーマンス的にはhosts_groupsテーブルを結合しない方が良いと思われますが、hosts_groupsテーブルを結合して絞り込むロジックも間違ってはいないので運用に支障が無ければ直す必要性は無いと思います。
では！
miko - 投稿数: 113
御回答頂き有難うございました。
1.6系でイベント表示が速くなっていると聞いていましたが、1.6.6以降でないと同じ原因で遅いのですね。
まだZABBIX-JP版の1.6系がリリースされないので、すぐに移行することは無いのですが、移行する場合は1.6.6以降を使用することにいたします。
有難うございました。
KAZ - 投稿数: 1085
mikoさん
zabbix-jpの1.6系rpmは1.6.4ベース＋パッチとなる予定です。
もちろん、この対応も入れてあります。
では！
miko - 投稿数: 113
御回答頂き有難うございます。
ZABBIX-JP版の1.6系のリリースを、楽しみにしておりますので、宜しくお願いします。