ZABBIX-JP 1.6.6-1 でスクリーン表示が完了しません

FORUMにはいつもお世話になっております。

ZABBIX-JP 1.6.6-1 がリリースされたので、ZABBIX 1.4からZABBIX 1.6へのアップグレード方法の手順に従い、イベント表示のテストを行った環境(VMwareServer2.0.2上のCentOS5.3)をバージョンアップしました。

rpm -Uvh でパッケージをインストールし、DBのアップグレードを行いました。
ただし、rpm -Uvh *.rpm で実行したため、rpmのインストール順は記載されている順番では有りませんでした。

/etc/zabbix以下のファイルは、rpmで新規にインストールしたものに既存の設定を書き込み使用しています。

バージョンアップ後にテストしたところ、SNMPデバイスのトラフィックグラフを21個と26個設定したスクリーンが最後まで表示されず、mysqlが高負荷のままとなります。
30分待っても表示が完了せず、mysqlも高負荷のままです。
slow-queryログを設定していますが、クエリが完了していないためか何も記載されていませんでした。

このスクリーンは、1.4.6で問題なく表示されていました。
また、標準設定のスクリーン:ZABBIX Serverは、問題なく表示されます。

監視対象数などは、下記のとおりです。検証環境のためネットワーク通信が出来ないなどもあり、取得不可が多くなっています。
ホスト数 (有効/無効/テンプレート/削除済) 514 448 / 28 / 38
アイテム数 (有効/無効/取得不可)[トラッパー] 10121 602 / 8279 / 1240
トリガー数 (有効/無効)[障害/不明/正常] 542 541 / 1 [474 / 34 / 33]

何か情報がありましたら、教えていただけますか。
宜しく御願致します。

コメント表示オプション

お好みのコメント表示方法を選び「設定の保存」をクリックすると変更が反映されます。
ユーザー KAZ の写真

mikoさん

表示されない状態で、mysqlにrootでログインし「show processlist;」を実行すると何が表示されますか?

下記は私の環境で実行した例です。
※:ちょうど、データの更新があったようでhistory_uintのupdateが見えています。
<code>
mysql> show processlist;
+---------+--------+-----------+--------+---------+------+--------+---------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+---------+--------+-----------+--------+---------+------+--------+---------------------------------------------------------------------------+
| 1504244 | zabbix | localhost | zabbix | Sleep | 4 | | NULL |
| 1504245 | zabbix | localhost | zabbix | Sleep | 3 | | NULL |
| 1504247 | zabbix | localhost | zabbix | Sleep | 2 | | NULL |
| 1504246 | zabbix | localhost | zabbix | Sleep | 1 | | NULL |
| 1504248 | zabbix | localhost | zabbix | Sleep | 286 | | NULL |
| 1504249 | zabbix | localhost | zabbix | Sleep | 1104 | | NULL |
| 1504250 | zabbix | localhost | zabbix | Sleep | 41 | | NULL |
| 1504251 | zabbix | localhost | zabbix | Sleep | 864 | | NULL |
| 1504252 | zabbix | localhost | zabbix | Sleep | 24 | | NULL |
| 1504253 | zabbix | localhost | zabbix | Sleep | 1 | | NULL |
| 1504254 | zabbix | localhost | zabbix | Sleep | 24 | | NULL |
| 1504256 | zabbix | localhost | zabbix | Query | 0 | update | insert into history_uint (clock,itemid,value) values (1259116594,19569,3) |
| 1504258 | zabbix | localhost | zabbix | Sleep | 4 | | NULL |
| 1504260 | zabbix | localhost | zabbix | Sleep | 0 | | NULL |
| 1504261 | zabbix | localhost | zabbix | Sleep | 1 | | NULL |
| 1504264 | zabbix | localhost | zabbix | Sleep | 136 | | NULL |
| 1666728 | zabbix | localhost | zabbix | Sleep | 44 | | NULL |
| 1666730 | zabbix | localhost | zabbix | Sleep | 24 | | NULL |
| 1666731 | zabbix | localhost | zabbix | Sleep | 40 | | NULL |
| 1666732 | zabbix | localhost | zabbix | Sleep | 24 | | NULL |
| 1666733 | zabbix | localhost | zabbix | Sleep | 40 | | NULL |
| 1666778 | zabbix | localhost | zabbix | Sleep | 24 | | NULL |
| 1666800 | zabbix | localhost | zabbix | Sleep | 44 | | NULL |
| 1666841 | zabbix | localhost | zabbix | Sleep | 24 | | NULL |
| 1666853 | root | localhost | NULL | Query | 0 | NULL | show processlist |
+---------+--------+-----------+--------+---------+------+--------+---------------------------------------------------------------------------+
25 rows in set (0.00 sec)
</code>

ユーザー miko の写真

御回答頂き有難うございます。

KAZさんは書きました:
mikoさん

表示されない状態で、mysqlにrootでログインし「show processlist;」を実行すると何が表示されますか?

申し訳有りません。いろいろとやっていたところ、表示できるようになってしまいましたので、上記情報を見ることが出来ませんでした。

スクリーンA:26グラフとスクリーンB:20グラフがあり、どちらも表示できませんでした。グラフは全て別の物です。

スクリーン内のグラフ数が多すぎるかと思い、別のスクリーンCでスクリーンAのグラフを数個ごとに追加していき、それぞれの場合にスクリーンCを表示させたところ、問題なく表示できました。

この状態でスクリーンAを表示したところ、問題なく表示できるようになりました。
ただし、スクリーンBは表示が完了しないままでした。

スクリーンBの基本設定画面を開き、更新しました。
スクリーンBの設定画面を開いたところ、問題なくグラフが表示されました。
スクリーンBの登録済グラフの一つを選択し、内容を変更せずに保存しました。
スクリーンBを表示したところ、問題なく表示されるようになりました。

スクリーンまたはグラフのデータか設定を1.6系でアクセスする必要があるのでしょうか。

再度1.4系をインストールしてから1.6系にアップグレードして、同じ現象となるか、mysqlのプロセスをチェックしてみます。

宜しくお願いします。

ユーザー miko の写真

スクリーンが表示できない状態を再現するため、1.6をアンインストール、1.4をインストール、DBを再作成しデータをインポート、1.6へアップグレードを行いました。

スクリーンAの表示が完了しない状態で、mysqlのプロセスリストを取得しました。

mysql> show processlist;
+-----+--------+-----------+--------+---------+------+----------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+--------+-----------+--------+---------+------+----------------------+------------------------------------------------------------------------------------------------------+
| 3 | zabbix | localhost | zabbix | Query | 0 | end | UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid' |
| 4 | zabbix | localhost | zabbix | Sleep | 78 | | NULL |
| 5 | zabbix | localhost | zabbix | Query | 0 | Updating | UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid' |
| 6 | zabbix | localhost | zabbix | Sleep | 23 | | NULL |
| 7 | zabbix | localhost | zabbix | Sleep | 205 | | NULL |
| 8 | zabbix | localhost | zabbix | Sleep | 13 | | NULL |
| 9 | zabbix | localhost | zabbix | Sleep | 317 | | NULL |
| 10 | zabbix | localhost | zabbix | Sleep | 706 | | NULL |
| 11 | zabbix | localhost | zabbix | Sleep | 5 | | NULL |
| 12 | zabbix | localhost | zabbix | Sleep | 76 | | NULL |
| 13 | zabbix | localhost | zabbix | Sleep | 3 | | NULL |
| 14 | zabbix | localhost | zabbix | Sleep | 868 | | NULL |
| 15 | zabbix | localhost | zabbix | Sleep | 868 | | NULL |
| 16 | zabbix | localhost | zabbix | Sleep | 3 | | NULL |
| 17 | zabbix | localhost | zabbix | Sleep | 3 | | NULL |
| 18 | zabbix | localhost | zabbix | Sleep | 5 | | NULL |
| 19 | zabbix | localhost | zabbix | Sleep | 2 | | NULL |
| 20 | zabbix | localhost | zabbix | Query | 1 | Copying to tmp table | select i.itemid,i.key_,h.host,h.port,i.delay,i.description,i.nextcheck,i.type,i.snmp_community,i.snm |
| 23 | zabbix | localhost | zabbix | Sleep | 2 | | NULL |
| 25 | zabbix | localhost | zabbix | Sleep | 267 | | NULL |
| 27 | zabbix | localhost | zabbix | Sleep | 1 | | NULL |
| 28 | zabbix | localhost | zabbix | Sleep | 4 | | NULL |
| 31 | zabbix | localhost | zabbix | Query | 0 | Updating | UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid' |
| 33 | zabbix | localhost | zabbix | Query | 0 | Updating | UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid' |
| 34 | zabbix | localhost | zabbix | Sleep | 23 | | NULL |
| 35 | zabbix | localhost | zabbix | Query | 0 | Updating | UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid' |
| 67 | zabbix | localhost | zabbix | Query | 0 | Updating | UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid' |
| 163 | root | localhost | NULL | Query | 0 | NULL | show processlist |
+-----+--------+-----------+--------+---------+------+----------------------+------------------------------------------------------------------------------------------------------+
28 rows in set (0.01 sec)

再度、別のスクリーンにスクリーンAのグラフのいくつかを登録したところ、スクリーンAとその設定画面が表示できるようになりました。
スクリーンBの設定画面も表示できるようになり、スクリーンBも表示できるようになりました。

宜しくお願いします。

ユーザー KAZ の写真

mikoさん

情報提供ありがとうございます。
idsテーブルのupdate文ですが…
<code>
UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid'
</code>
同じSQLが複数ありますが,ロックがかかってないですね…

MyISAMなら問題ないのですが、InnoDBではまずいような気が…
少々調べてみます。

ユーザー miko の写真

御回答頂き有難うございます。

KAZさんは書きました:

idsテーブルのupdate文ですが…
同じSQLが複数ありますが,ロックがかかってないですね…

MyISAMなら問題ないのですが、InnoDBではまずいような気が…
少々調べてみます。

再度バージョンアップをしなおしたところ、ZABBIX Serverの初期設定スクリーンが表示できませんでした。

この時のmysqlプロセスリストには、同じように下記のクエリが4つ有りました。
UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='profiles' AND field_name='profileid'

宜しく御願致します。

ユーザー KAZ の写真

mikoさん

トランザクションはちゃんとかかってました。A(^^;
また、取得してくれた情報を良く見るとTimeが0なので、UPDATEのSQLはOKそうなのですが…

なにか別な原因がありそうなのですが…
1つのSQLに時間がかかっているのではなくて、延々と同じSQLを繰り返し発行しているとか…
表示が止まっているときにMySQLのshow statusを実行してupdateクエリの数がものすごい勢いで増えてたりするとその可能性もあります、

ちなみに現状の情報を整理すると…
■現象1
1.4.6→1.6.6を行い、グラフやマップを表示せずにスクリーンを表示すると画面が表示されない。(30分待っても表示されない)
その時CPU使用率、load averageが高い。

■現象2
スクリーンに使っている個々のグラフを一回表示させると次からスクリーンは正しく表示されるようになる。

上記の前提で良いでしょうか?

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:
mikoさん

トランザクションはちゃんとかかってました。A(^^;
また、取得してくれた情報を良く見るとTimeが0なので、UPDATEのSQLはOKそうなのですが…

なにか別な原因がありそうなのですが…
1つのSQLに時間がかかっているのではなくて、延々と同じSQLを繰り返し発行しているとか…
表示が止まっているときにMySQLのshow statusを実行してupdateクエリの数がものすごい勢いで増えてたりするとその可能性もあります、

表示が完了しない状態でプロセスリストを何回か見ましたが、数は増えていませんでした。
次にテストする時には、show statusも確認してみます。

ちなみに現状の情報を整理すると…
■現象1
1.4.6→1.6.6を行い、グラフやマップを表示せずにスクリーンを表示すると画面が表示されない。(30分待っても表示されない)
その時CPU使用率、load averageが高い。

ZABBIX-JPrpm版の1.4.6-2から同1.6.6-1へアップグレードしました。
いきなりスクリーンやスクリーンの設定画面を表示させた場合、一部のグラフが表示されますが、完了しません。
その時に負荷は、mysqlが大半となります。

■現象2
スクリーンに使っている個々のグラフを一回表示させると次からスクリーンは正しく表示されるようになる。

上記の前提で良いでしょうか?

はい、ただし全てのグラフを表示させなくても表示できるようになります。
スクリーンAの26グラフのうち、別のスクリーンに8個登録した時に、スクリーンAが表示できるようになりました。

現象に関してもう少し試してみます。

宜しく御願致します。

ユーザー KAZ の写真

mikoさん

apacheのログとかもエラーが出ていないか見て頂けると助かります。m(__)m

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:

apacheのログとかもエラーが出ていないか見て頂けると助かります。m(__)m

ZABBIXシステムが二つ動いているので、別のデータでも検証してみましたが、ZABBIX Serverのスクリーン(グラフをいくつか追加済み)をいきなり開くと、表示が完了しませんでした。

mysqlのprocesslistには、同じようにupdateが4つありました。
Innodb_rows_updatedは、1秒に300から400増えていきます。

apacheのログ(/var/log/httpd)には、エラーは有りませんでした。

宜しく御願致します。

ユーザー miko の写真

追記しますと、ダッシュボードを表示している状態では、Innodb_rows_updatedは数秒で10程度、時折50程度増えるだけです。

宜しく御願致します。

ユーザー KAZ の写真

mikoさん

mysqlのprocesslistには、同じようにupdateが4つありました。
Innodb_rows_updatedは、1秒に300から400増えていきます。

1秒間に100も更新してますか!
多分遅い原因はそれですね!
見てみます。

ユーザー KAZ の写真

mikoさん

現象が再現できなく、調査が行き詰っています。

<code>UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND able_name='profiles' AND field_name='profileid'</code>
表示が遅い時、上記がずーっと表示されるなら(field_name='profileid'まで同一のSQLが繰り返されるなら)、〜/include/db.inc.phpのget_dbid関数でloop脱出条件がうまく判定できていないと思います。(データの移行で問題がある可能性もあり?)

私は下記の様にソースにerror_logを追加して1.4.6-2のデータを取り込みアップグレードを行ってみたのですが、データ量が少ないのか事象が再現しません。(泣)
※:一応小規模環境を半年間監視したデータなんですが…

<code>
function get_dbid($table,$field){
$nodeid = get_current_nodeid(false);

$found = false;
do{
global $ZBX_LOCALNODEID;

$min=bcadd(bcmul($nodeid,'100000000000000'),bcmul($ZBX_LOCALNODEID,'100000000000'));
$max=bcadd(bcadd(bcmul($nodeid,'100000000000000'),bcmul($ZBX_LOCALNODEID,'100000000000')),'99999999999');
$row = DBfetch(DBselect('SELECT nextid FROM ids WHERE nodeid='.$nodeid ." AND table_name='$table' AND field_name='$field'"));
if(!$row){
$row=DBfetch(DBselect('SELECT max('.$field.') AS id FROM '.$table.' WHERE '.$field.'>='.$min.' AND '.$field.'<='.$max));
if(!$row || is_null($row["id"])){

DBexecute('INSERT INTO ids (nodeid,table_name,field_name,nextid) '.
" VALUES ($nodeid,'$table','$field',$min)");
}
else{
/*
$ret1 = $row["id"];
if($ret1 >= $max) {
"Maximum number of id's was exceeded"
}
*/

DBexecute("INSERT INTO ids (nodeid,table_name,field_name,nextid) VALUES ($nodeid,'$table','$field',".$row["id"].')');
}
continue;
}
else{
$ret1 = $row["nextid"];
if((bccomp($ret1,$min) < 0) || !(bccomp($ret1,$max) < 0)) {
DBexecute("DELETE FROM ids WHERE nodeid=$nodeid AND table_name='$table' AND field_name='$field'");
continue;
}

DBexecute("UPDATE ids SET nextid=nextid+1 WHERE nodeid=$nodeid AND table_name='$table' AND field_name='$field'");

$row = DBfetch(DBselect('SELECT nextid FROM ids WHERE nodeid='.$nodeid." AND table_name='$table' AND field_name='$field'"));
if(!$row || is_null($row["nextid"])){
/* Should never be here */
continue;
}
else{
$ret2 = $row["nextid"];
error_log("get_dbid before nextid:".$ret1." after:nextid:".$ret2."\n", 3, "/test/trace.log");
if(bccomp(bcadd($ret1,1),$ret2) ==0){
$found = true;
}
}
}
}
while(false == $found);

return $ret2;
}
</code>

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:
mikoさん

現象が再現できなく、調査が行き詰っています。

表示が遅い時、上記がずーっと表示されるなら(field_name='profileid'まで同一のSQLが繰り返されるなら)、〜/include/db.inc.phpのget_dbid関数でloop脱出条件がうまく判定できていないと思います。(データの移行で問題がある可能性もあり?)

私は下記の様にソースにerror_logを追加して1.4.6-2のデータを取り込みアップグレードを行ってみたのですが、データ量が少ないのか事象が再現しません。(泣)
※:一応小規模環境を半年間監視したデータなんですが…

error_log("get_dbid before nextid:".$ret1." after:nextid:".$ret2."\n", 3, "/test/trace.log");

データ移行に関しては、次のように行っています。
本番サーバーで下記をcronに設定し、バックアップを取得
0 2 * * * /usr/bin/mysqldump -u root --single-transaction --all-databases --master-data=2 --delete-master-logs --flush-logs --quick > /root/zabbixbackup.dump

検証サーバーのバージョン1.4.6-2でzabbixサービスを停止し、下記コマンドでインポート
mysql zabbix < zabbixbackup.dump &#8211;u roo -p

zabbixを1.6にアップグレード後に、1.6のDBアップグレードスクリプトを実行

提示していただいた上記内容を1.6のdb.inc.phpに追加しましたが、新規に作成した/testディレクトリにはログファイルが作成されませんでした。

宜しく御願致します。

ユーザー KAZ の写真

mikoさん

データ移行に関しては、次のように行っています。
本番サーバーで下記をcronに設定し、バックアップを取得
0 2 * * * /usr/bin/mysqldump -u root --single-transaction --all-databases --master-data=2 --delete-master-logs --flush-logs --quick > /root/zabbixbackup.dump

検証サーバーのバージョン1.4.6-2でzabbixサービスを停止し、下記コマンドでインポート
mysql zabbix < zabbixbackup.dump &#8211;u roo -p

zabbixを1.6にアップグレード後に、1.6のDBアップグレードスクリプトを実行

私もmysqldumpで取ってきたデータをcreate databaseしたところに戻して、アップグレードを実行しています。

環境はVMWareのCentoOS5.3の上なので、同じかと。
事象が再現できないのは、データ差異の可能性が高いです。

提示していただいた上記内容を1.6のdb.inc.phpに追加しましたが、新規に作成した/testディレクトリにはログファイルが作成されませんでした。

/testですが、apache起動ユーザ:グループで書き込み権を与えないといけません。chmod 777 /testでファイルができるようになるかと思います。

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:
mikoさん

私もmysqldumpで取ってきたデータをcreate databaseしたところに戻して、アップグレードを実行しています。

環境はVMWareのCentoOS5.3の上なので、同じかと。
事象が再現できないのは、データ差異の可能性が高いです。

/testですが、apache起動ユーザ:グループで書き込み権を与えないといけません。chmod 777 /testでファイルができるようになるかと思います。

/testのパーミッションを変更するのを忘れていました。
chmod 777を/testに付与することで、trace_logが作成されるようになりました。ログはひたすら追加されていきます。

開始数行は、次のとおりです。
get_dbid before nextid:1272 after:nextid:1273
get_dbid before nextid:710640 after:nextid:710641
get_dbid before nextid:710641 after:nextid:710642
get_dbid before nextid:710642 after:nextid:710643
get_dbid before nextid:710643 after:nextid:710644

15分ほど経っても表示が完了しないので、各サービスを停止した時の最後の部分は下記のとおりです。
get_dbid before nextid:927721 after:nextid:927726
get_dbid before nextid:927721 after:nextid:927727
get_dbid before nextid:927722 after:nextid:927728
get_dbid before nextid:927723 after:nextid:927729
get_dbid before nextid:927724 after:nextid:927730
get_dbid before nextid:927726 after:nextid:927731
get_dbid before nextid:927726 after:nextid:927732
get_dbid before nextid:927727 after:nextid:927733
get_dbid before nextid:927729 after:nextid:927734
get_dbid before nextid:927729 after:nextid:927735
get_dbid before nextid:927730 after:nextid:927736

宜しく御願致します。

ユーザー KAZ の写真

mikoさん

情報提供ありがとうございます。m(__)m
やはりそこかと言う感じです。

今気になっているのは移行パッチの下記です。

/usr/share/doc/zabbix-server-1.6.6/dbpatches/1.6/mysql/patch.sql
<code>
delete from ids;
</code>

私ももう一回トライして、1.4.6-2のidsテーブルと1.6.6-1のidsテーブルを比較してみます。

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:
mikoさん

情報提供ありがとうございます。m(__)m
やはりそこかと言う感じです。

今気になっているのは移行パッチの下記です。

/usr/share/doc/zabbix-server-1.6.6/dbpatches/1.6/mysql/patch.sql
delete from ids;

私ももう一回トライして、1.4.6-2のidsテーブルと1.6.6-1のidsテーブルを比較してみます。

再度1.4から1.6に移行し、その時にpatch.sqlからdelete from ids; の行を削除して実行しましたが、現象は変りませんでした。
そんなに単純なことではないのですね。

宜しく御願致します。

ユーザー KAZ の写真

mikoさん

移行直後のidsテーブルと、profilesテーブルを追っかけてみました。
スクリーン表示を見て頂けるとわかりますが、profilesテーブルのprofileidが飛んでます。推測になりますが、複数スレッドから同一テーブルのIDを更新している為に飛んでいるかと思います。(要するにスレッドセーフじゃない?)

多分、「do{〜}while(false == $found);」の間、idsテーブルの該当table_nameレコードにロックをかければ良いとは思うのですが…
トランザクションが使える関数はあったのですが、この個所には効いてないようです…
これは本家に報告になるかと思います。

■移行直後、ZABBIXサーバ起動前
<code>
mysql> select * from profiles;
Empty set (0.00 sec)

mysql> select * from ids;
Empty set (0.01 sec)
</code>

■ZABBIXサーバ起動直後
<code>
mysql> select * from ids;
+--------+------------+------------+--------+
| nodeid | table_name | field_name | nextid |
+--------+------------+------------+--------+
| 0 | events | eventid | 724 |
+--------+------------+------------+--------+
1 row in set (0.00 sec)
</code>

■webフロントエンド ログイン
<code>
mysql> select * from ids;
+--------+------------+------------+--------+
| nodeid | table_name | field_name | nextid |
+--------+------------+------------+--------+
| 0 | auditlog | auditid | 756 |
| 0 | events | eventid | 724 |
| 0 | profiles | profileid | 1 |
+--------+------------+------------+--------+
3 rows in set (0.00 sec)

mysql> select * from profiles;
+-----------+--------+---------------------+------+----------+-----------+-----------+--------+------+
| profileid | userid | idx | idx2 | value_id | value_int | value_str | source | type |
+-----------+--------+---------------------+------+----------+-----------+-----------+--------+------+
| 1 | 3 | web.menu.login.last | 0 | 0 | 0 | index.php | | 3 |
+-----------+--------+---------------------+------+----------+-----------+-----------+--------+------+
1 row in set (0.00 sec)
</code>

■スクリーン表示
<code>
mysql> select * from ids;
+--------+------------+------------+--------+
| nodeid | table_name | field_name | nextid |
+--------+------------+------------+--------+
| 0 | auditlog | auditid | 756 |
| 0 | events | eventid | 724 |
| 0 | profiles | profileid | 12 |
+--------+------------+------------+--------+
3 rows in set (0.00 sec)

mysql> select * from profiles;
+-----------+--------+---------------------+------+----------+-----------+-------------------------+------------------------------+------+
| profileid | userid | idx | idx2 | value_id | value_int | value_str | source | type |
+-----------+--------+---------------------+------+----------+-----------+-------------------------+------------------------------+------+
| 1 | 3 | web.menu.login.last | 0 | 0 | 0 | index.php | | 3 |
| 2 | 3 | web.menu.view.last | 0 | 0 | 0 | screens.php | | 3 |
| 3 | 3 | web.screens.config | 0 | 0 | 0 | | | 2 |
| 5 | 3 | web.screens.period | 0 | 0 | 3600 | | | 2 |
| 6 | 3 | web.history.0 | 0 | 0 | 0 | screens.php?elementid=2 | カスタムスクリーン | 3 |
| 9 | 3 | web.graph.period | 60 | 0 | 3600 | | | 2 |
| 11 | 3 | web.charts.graphid | 0 | 61 | 0 | | | 1 |
| 12 | 3 | web.graph.period | 61 | 0 | 3600 | | | 2 |
+-----------+--------+---------------------+------+----------+-----------+-------------------------+------------------------------+------+
8 rows in set (0.00 sec)
</code>

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:
mikoさん

移行直後のidsテーブルと、profilesテーブルを追っかけてみました。
スクリーン表示を見て頂けるとわかりますが、profilesテーブルのprofileidが飛んでます。推測になりますが、複数スレッドから同一テーブルのIDを更新している為に飛んでいるかと思います。(要するにスレッドセーフじゃない?)

多分、「do{〜}while(false == $found);」の間、idsテーブルの該当table_nameレコードにロックをかければ良いとは思うのですが…
トランザクションが使える関数はあったのですが、この個所には効いてないようです…
これは本家に報告になるかと思います。

検証をしていただき有難うございました。
修正版がリリースされるのを待つようにいたします。

こちらの環境で検証することや必要な情報があれば、連絡をいただければ行えます。

宜しく御願致します。

ユーザー KAZ の写真

mikoさん

検証をしていただき有難うございました。
修正版がリリースされるのを待つようにいたします。

こちらの環境で検証することや必要な情報があれば、連絡をいただければ行えます。

ありがとうございます。

これから、色々試してポイントを絞り込んでみたいと思います。
じゃないと報告してもスルーされると思うので(笑)

ユーザー KAZ の写真

mikoさん

取り敢えず、下記で何とかなると思います。
※:検証はMySQLで2回しかしていないですが…
下記の位置にDBstart()とDBend()を入れて下さい。
これでトランザクションが効くはずです。
宜しければお試しください。

/usr/share/zabbix/include/db.inc.php
<code>
function get_dbid($table,$field){
// PGSQL on transaction failure on all queries returns false..
global $DB;
if(($DB['TYPE'] == 'POSTGRESQL') && $DB['TRANSACTIONS'] && !$DB['TRANSACTION_STATE']) return 1;
//------
DBstart();
$nodeid = get_current_nodeid(false);

</code>
<code>
}
while(false == $found);
DBend();
return $ret2;
}
</code>

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:

取り敢えず、下記で何とかなると思います。
※:検証はMySQLで2回しかしていないですが…
下記の位置にDBstart()とDBend()を入れて下さい。
これでトランザクションが効くはずです。
宜しければお試しください。

提示していただきました内容を、/usr/share/zabbix/include/db.inc.php に追加したところ、問題なくスクリーンが表示されるようになりました。

trace.logも有効にしておいたところ、下記のように記載されていました。
get_dbid before nextid:22451 after:nextid:22452
get_dbid before nextid:22452 after:nextid:22453
get_dbid before nextid:22453 after:nextid:22454
 nextidが連続
get_dbid before nextid:22516 after:nextid:22517
get_dbid before nextid:22517 after:nextid:22518
get_dbid before nextid:22518 after:nextid:22519

本番環境の移行に関しては、ZABBIX-JP版の修正を待つことを考えております。

検証作業を行って解決策を提示していただき、有難うございました。
今後とも宜しく御願致します。

ユーザー KAZ の写真

mikoさん

検証した情報とパッチを本家に登録してきました。
現状、本家の回答待ちです。

情報提供ありがとうございました。m(__)m

ユーザー kodai の写真

こんにちは。

現在1.6.7-1のパッケージを作成しておりますが、すでにテスト済みなのでこのパッチを取り込むのは1.6.8-1になります。少々お待ちください。

ユーザー miko の写真

御回答頂き有難うございました。

kodaiさんは書きました:
こんにちは。

現在1.6.7-1のパッケージを作成しておりますが、すでにテスト済みなのでこのパッチを取り込むのは1.6.8-1になります。少々お待ちください。

本日、リリースされているのを見て早速と思いましたが、1.6.8-1で対応ということですので、そちらを待たせていただきます。

有難うございました。

ユーザー miko の写真

御回答頂き有難うございました。

KAZさんは書きました:
mikoさん

検証した情報とパッチを本家に登録してきました。
現状、本家の回答待ちです。

情報提供ありがとうございました。m(__)m

了解しました。
こちらこそ、いつも対応をしていただき有難うございます。

今後とも宜しくお願いします。