Pandora FMS の最適化と問題解決

Pandora FMS ドキュメント一覧に戻る

Pandora FMS server can monitor about 2000 devices (between 5 and 80 thousands modules, depending on available hardware); but this also requires fine-tuning the configuration of the database.

Pandora FMS サーバは、約 2000のデバイス(5 から 8万モジュール、ハードウエアに依存します)のモニタリングが可能です。ただし、そのためには、データベースの設定を調整する必要があります。

This article also explains some techniques to detect and solve problems of your Pandora FMS installation.

この章ではまた、Pandora FMS の問題発見および解決のためのテクニックについて説明します。

To learn more about “Data Backup and Recovery in Pandora FMS”, go to this link.

“Pandora FMS におけるデータバックアップとリカバリ” についての詳細は、こちらを参照してください。

Unless otherwise specified, this entire topic refers to MySQL version 5.7.
See also “Upgrading from MySQL 5.7 to MySQL 8”.

特に明示されていない限り、ここでの説明は MySQL バージョン 5.7 を前提としています。
“MySQL 5.7 から MySQL 8 へのアップグレード” も合わせて参照してください。

To work with tables larger than 2 GiB it is necessary to follow some guidelines:

2GiBを超えるテーブルを持つ巨大なシステムを必要とするのであれば、次のガイドラインに従う必要があります。

MySQL® recommends using a 64-bit system. 32-bit systems may have serious problems from the year 2038 onwards.
The more RAM and the more CPU, the better the performance. In our experience, RAM is more important than CPU. The minimum for an enterprise level system will be 4 GiB. A good choice for a large system is 16 GiB. Remember that more RAM can speed up key updates by keeping the most used key pages in RAM.
It is a good idea to be able to remove the system in case of failure. For systems where the database is on another dedicated server for the database use Gigabit Ethernet, preferably with fiber optics rather than copper. Latency is as important as performance.
Disk optimization is very important for very large databases: databases and tables will have to be split on different disks. In MySQL® you can use symbolic links for this. Use different disks for the system and the database.

MySQL® は 64Bit システムの利用を推奨します。32Bit システムでは、2038年以降重大な問題があります。
よりよいパフォーマンスを得るために十分なメモリとCPUを用意します。われわれの経験では、CPUよりもメモリのほうが重要です。エンタープライズレベルであれば最低 4GiB 必要です。巨大なシステムであれば、16GiB 割り当てるというのもよいでしょう。メモリが十分あれば、利用されるインデックスの大半をメモリ上に置くことでインデックスの更新が高速化されるということを忘れてはいけません。
障害が発生した場合にシステムを切り離すようにできるようにするのが良いでしょう。特定のサーバにデータベースがあるシステムの場合は、ギガビットイーサを利用すべきです。待ち時間はパフォーマンスにとって重要です。
ディスクの最適化は、とても大きなデータベースにとっては大変重要です。データベースおよびテーブルを異なるディスクに分割すべきです。MySQL では、シンボリックリンクを使うことができます。システムおよび、データベースで異なるディスクを使い、一つのハードディスクのアクセスを減らすようにすることが重要です。

The use of SSD disks is recommended due to their speed and improved system latency.

システムの応答時間を早めるために、SSD を利用することをお勧めします。

Use –skip-locking (enabled by default on some systems) if possible. This will turn off external locking and provide better performance.
If you start the client and MySQL in the same machine, use sockets instead of TCP/IP connexions when connecting with MySQL® (this could result in an improvement of a 7.5%). Do it without specifying the host name or the localhost when connecting with MySQL®: disallow the start of the binary session an the replication if it only launches one MySQL® host server.
Using recent versions of MySQL® (5.5 or later) over older versions of MySQL® (5.0.x) can offer up to a 20% difference in performance.
We recommend the use of the modified version of MySQL® (Percona Server for MySQL®), which offers better performance. By default the plugins programmed are for Percona®.

可能であれば、-skip-locking (いくつかのシステムではデフォルトで有効化されています) を使ってください。これにより外部ロックを行わず、パフォーマンスが向上します。
もし、MySQLサーバとクライアントを同じマシン上で起動するなら、TCP/IPのかわりにsocketを使用してMySQLサーバへ接続しましょう(これにより7.5%性能が改善されます)。MySQLサーバに接続する際、ホスト名を指定しないかlocalhostと指定することでsocket経由で接続することができます。MySQLサーバを1台しか起動しないのであれば、binary logの出力とレプリケーションを無効にしましょう。
MySQL® の最近のバージョン(5.5以降)を利用することにより、古いバージョン(5.0.x)よりも 20% ほどパフォーマンスが向上します。
よりパフォーマンスの高い、修正版の MySQL (Percona Server for MySQL®) を使うことを強くお勧めします。デフォルトでは、プラグインは Percona 用に作成しています。

Please note that performance is greatly affected by the following points:

以下の点においてパフォーマンスは大きく影響を受けることに注意してください。

Only use binary logs if you use a MySQL® configuration with replication.
Do not use query traceability logs or slowquery logs.

MySQL® でレプリケーション設定を行う時のみ binary log を利用してください。
クエリのトレースログや slowquery ログは利用しないでください。

MySQL サーバの設定を “最適化” するためのツールはたくさんあります。

Mattew Montgomery の MySQL Tuning Primer は、MySQL のパフォーマンスをチェックする(コマンドライン)ツールです。そして、それを改善するためのちょっとした提案をしてくれます。https://bugs.launchpad.net/mysql-tuning-primer を確認してみてください。

If you have configured a Pandora FMS HA system, the binary replication is necessary. This recommendation is only valid if you have a single Pandora FMS server.

Pandora FMS HA システムを設定している場合は、バイナリログは必須です。ここに記載している内容は、Pandora FMS サーバが 1台の場合にのみ有効です。

It is enabled by default on most GNU/Linux distros. To disable it, edit the my.cnf file, usually in /etc/my.cnf and comment the following lines:

多くの Linux ディストリビューションにおいてデフォルトで有効になっています。無効にするには、my.cnf ファイル (通常、/etc/my.cnf にあります) を編集し、次の行をコメントアウトします。

  # log-bin=mysql-bin
  # binlog_format=mixed

Comment both lines, and then restart MySQL Server.

両方の行をコメントアウトし、MySQL サーバを再起動します。

To learn more about “Data Backup and Recovery in Pandora FMS”, go to this link.

“Pandora FMS におけるデータバックアップとリカバリ” に関する詳細は、こちらを参照してください。

There are three very important configuration tokens, directly related to disk IO, and should be considered because improper IO access is usually the most important bottleneck in MySQL.

ディスク I/O に直結し、考慮すべきとても重要な 3つの設定があります。MySQL において、不適切な I/O アクセスは、通常最も重要なボトルネックになります。

innodb_log_file_size

innodb_log_file_size = 64M

This value is set by default, which can be higher (even 512M) without any risk, except for recovery in case of any problem or higher disk occupation. The default value of MySQL is 5M, which is very low for production environments with high transaction volume. To change this value with an already running system:

デフォルトではこの値が設定されていますが、問題が発生した場合の回復とディスク占有率が増えることを除いては、事前検証なしに高くすることができます(512Mでも)。 MySQL のデフォルト値は 5M です。これは、トランザクション量が多い本番環境では非常に低い値です。稼働中のシステムで値を変更するには、次のようにします。

First make a complete DUMP in the databases.
Delete the Innodb binary index files (usually in /var/lib/mysql/ib*.
Change file my.cnf with the hosen value.
Restart MySQL.
Load the SQL DUMP.

データベースのフルバックアップ(SQL ダンプ)を行います。
Innodb バイナリインデックスファイル(通常は /var/lib/mysql/ib* です)を削除します。
my.cnf を編集します。
MySQL を再起動します。
ダンプを読み込みます。

Since the process is the same as the one to activate the innodb_file_per_table token (described below), it is recommended to do the whole process simultaneously.

サーバは、新たなトランザクションログファイルを新たなサイズで再生成し、通常通り動きだします。この処理は innodb_file_per_table トークン(後述)を有効化するのと同じであるため、処理全体を同時に行うことをお勧めします。

innodb_io_capacity

innodb_io_capacity = 100

This parameter has the value 100 by default, but you have to know the IOPS of the system disk. You can know exactly by looking for IOPS and the exact hard disk model (obtained via smartctl), where the recommended values are: 7500RPM → 100 IOPS, 15000 RPM → 190 IOPS, SSD → 1500 IOPS.

デフォルトでは、このパラメータの値は 100 です。ただし、事前にシステムのディスクの IOPS を知る必要があります。正確な IOPS およびハードディスクのモデルを(smartctlを使って)知ることができます。ここでのお勧めの値は、7500RPM → 100 IOPS, 15000 RPM → 190 IOPS, SSD → 1500 IOPS です。

To install smarctl you must request the full smartmontools package; for example:

yum install smartmontools,

apt install smartmontools, etc.

smartctl をインストールするには、次のように smartmontools パッケージをインストールする必要があります。

yum install smartmontools,

apt install smartmontools, etc.

innodb_file_per_table

Using a table space for each table ( from the MySQL 5.0 Spanish manual)

テーブルごとにファイルを作成します。

In MySQL 5.0, it is possible to store each InnoDB table and its index in its own file. This feature is called “multiple tablespaces” because each table has its own table space.

MySQL 5.0 では、各 InnoDB テーブルとそのインデックスを独自のファイルに保存することができます。この機能は、各テーブルに独自のテーブルスペースがあるため、“複数のテーブルスペース” と呼ばれます。

The use of multiple space tables can be useful for users that want to move specific tables to separate physical disks or the ones who want to restore table back ups without interrupting the use of the rest of the InnoDB tables.

複数のスペーステーブルの使用は、特定のテーブルを別々の物理ディスクに移動したい場合や、残りの InnoDB テーブルの使用を中断せずにテーブルのバックアップを復元したい場合に役立ちます。

It is possible to activate multiple table spaces adding this line to the my.cnf Mysqld section

my.cnf の mysqld セクションに以下の設定を追加することにより、複数のテーブルスペースを有効化できます。

[mysqld]
innodb_file_per_table

After restarting the server, InnoDB will store each new created table in its own name_table.ibd file in the database directory to which the table belongs to. This is similar to what the MyISAM store motor does, but MyISAM divides the table in a tbl_name.MYD data file and a tbl_name.MYI index file.

サーバーを再起動した後、InnoDB は、新しく作成された各テーブルを、テーブルが属するデータベースディレクトリ内の独自の name_tabla.ibd ファイルに保存します。これは MyISAM が行う動作と似ていますが、MyISAM はテーブルを tbl_name.MYD データファイルと tbl_name.MYI インデックスファイルに分割します。

For InnoDB, data and index are kept together in the .ibd file. The tbl_name.frm file should be created as usual. If the innodb_file_per_table line is take off from my.cnf and the server is restarted (see previous instructions for innodb_log_file_size), then InnoDB will create again the tables in the shared table space files.

InnoDB の場合、データとインデックスは .ibd ファイルにまとめて保持されます。tbl_name.frm ファイルは通常どおり作成する必要があります。innodb_file_per_table 行が my.cnf から削除され、サーバが再起動された場合、InnoDB は共有表スペース・ファイルに表を再作成します。

innodb_file_per_table affects only table creation. If you start the server with this option, then the new tables will be created using .ibd files, but you could still have access to the existing tables in the shared table space. If you remove the option, then the new tables will be created in the shared space, but it will be still possible to have access to the tables created in multiple table spaces

innodb_file_per_table は、テーブルの作成にのみ影響します。このオプションを使用してサーバを起動すると、.ibd ファイルを使用して新しいテーブルが作成されますが、共有テーブルスペース内の既存のテーブルに引き続きアクセスできます。このオプションを削除すると、共有スペースに新しいテーブルが作成されますが、複数のテーブルスペースに作成されたテーブルにアクセスすることは引き続き可能です。

MySQL establishes autocommit =1 for each connection by default. This is not bad for MyISAM, since what one person writes in the disk is not guaranteed, but for InnoDB it means that any insert / update / delete in an InnoDB table will be registered on the disk (flush).

デフォルトでは、MySQLは各接続開始時の autocommit の値を autocommit =1 としています。MyISAMの場合、更新結果がディスクに保存されることを保証していないため、この設定はそんなに悪い設定ではありません。しかしInnoDBの場合、InnoDB　テーブルへのあらゆる　insert / update / delete によって、ディスクへの書き込みが発生するということを意味します。

さて, なぜディスクへの書き込みがよくないのでしょうか?　そんなことはありません。ディスクへの書き込みは何らかのcommitment後、データベースが障害後再起動したときもデータが存在することを保障します。問題は、DBのパフォーマンスがディスクの物理的な速度によって制限を受けることです。書き込みを確認する前にデータをディスクに書き込まなければならないことを考えると、少し時間がかかるでしょう。

ディスクの書き込みに平均9msかかるとすると、おおよそ1秒当たり67コミットに制限されます。これは非常に遅いです。そして、ディスクのあるセクタに書き込み中は、そのセクタを読み込むことはできません。InnoDBはこれらの制限のいくつかを複数の書き込みを同時に実行することで回避しています。しかしそれでも制約が存在します。

InnoDB can avoid some of this limitations by associating some writing together, but, even with this, this restriction still exists. You can prevent if from writing at the end of each transaction, ensuring that it uses an “automatic” writing system, which writes approximately every second. In case of failure, the data from the last second could be lost, but his is something more bearable considering that it achieves greater efficiency. To do it, use the following configuration token innodb_flush_log_at_trx_commit = 0. It has this value in the configuration by default.

システムによる“自動”書き込み(およそ1秒ごとに書き込みを行う)を利用することで、各トランザクションが完了するたびにディスクへ書き込むことを回避することができます。問題が発生した場合、最近1秒のデータが失われますが、パフォーマンス向上を得ようとしていることを考慮すれば、許容できる範囲でしょう。デフォルトでは、innodb_flush_log_at_trx_commit = 0 となっています。

システムに搭載された物理メモリ量に依存しますが、非常に重要なグローバル変数であり、これを設定することでDELETEおよびSELECTの実行速度が改善されます。

key_buffer_size = 4M

上記は、デフォルトの設定値です。

いくつかのディストリビューションでは、デフォルトで設定されていないいくつかのバッファがあります。これらのパラメータを設定することによりデフォルトより高いパフォーマンスを得ることができます。これらのトークンが MySQL の設定ファイルに存在するかどうかを確認することが重要です。

query_cache_size = 64M
query_cache_limit = 2M
join_buffer_size = 4M

For MySQL version 8, and later versions, the MySQL development team has withdrawn support for query cache, for more information please visit the following web link: https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/ .

MySQL バージョン 8 以降では、query cache のサポートが廃止されました。詳細については、https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/ を参照してください。

Pandora の MySQL サーバパフォーマンスを向上に有効なパラメータがあります。そのパラメータは、'innodb_thread_concurrency です。このパラメータは、MySQL で “同時実行スレッド” をいくつにするのかを設定するのに利用します。このパラメータがうまく設定されていない場合、デフォルトよりも遅くなることがあります。そのため、次のような情報に注意を払うことが特に重要です。

MySQL バージョン。異なるバージョンの MySQL では、このパラメータはとても異なる動作をします。
物理プロセッサ数。

Here you can read the official MySQL documentation.

MySQL の公式ドキュメントは、こちらです。

The recommended value is the number of CPUs (Physical) multiplied by 2 plus the number of disks where InnoDB is located.

推奨値は、CPU(物理)の数に 2を掛けたものに、InnoDB が配置されているディスクの数を加えたものです。

お勧めの値は、(物理的な)CPU数の2倍に、InnoDB が置かれているディスクの数を足した数です。MySQL の最近のバージョン (> 5.0.21) では、デフォルトは 8 です。0 に設定すると、“可能な限り多くのスレッドを開きます”。

innodb_thread_concurrency = 0

他に ¹⁾ ²⁾ によると、古いバージョンの MySQL でテストを行ったところ、大きい値にしたときに複数の物理 CPU のあるサーバでパフォーマンスの問題があったとのことです。(2008年の情報です)

ファイルシステムのように、データベースもフラグメンテーションが発生しシステム全体の速度が低下します。Pandora のように高いパフォーマンスを必要とするシステムでは、高速で信頼性の高いデータベースが必要です。高負荷なシステムでは、監視システムが停止する可能性があります。

Pandora FMS で良いパフォーマンスを得るには、MySQL の設定がとても重要です。パフォーマンスの問題がある場合は、MySQL の設定やデータベースに関する問題である可能性があります。

my.cnf 設定の確認

Let us start with my.cnf, the “basic configuration” for MySQL Server. This configuration file is written in INI format and its location can be determined with the following command:

MySQL サーバの “基本設定” である my.cnf から確認します。設定ファイルは、INI フォーマットで書かれており、次のコマンドで場所を確認できます。

mysqld --help --verbose | more

This file in your setup should be similar to this one (this is for a 4GB RAM Server using old (2013) average server hardware). Make sure that you have these tokens inside your [mysqld] section:

このファイルは以下のような設定ファイルになっています(この例は、メモリ 4GB の 2013 年の古い平均的なサーバハードウエアです)。[mysqld] セクション内のトークンを確認します。

[mysqld]
 datadir=/var/lib/mysql
 socket=/var/lib/mysql/mysql.sock
 user=mysql
 character-set-server=utf8
 skip-character-set-client-handshake

 max_allowed_packet = 64M
 innodb_buffer_pool_size = 800M
 innodb_lock_wait_timeout = 90
 innodb_file_per_table
 innodb_flush_log_at_trx_commit = 0
 innodb_flush_method = O_DIRECT
 innodb_log_file_size = 64M
 innodb_log_buffer_size = 16M
 innodb_io_capacity = 100
 thread_cache_size = 8
 thread_stack    = 256K
 max_connections = 100

 key_buffer_size=4M
 read_buffer_size=128K
 read_rnd_buffer_size=128K
 sort_buffer_size=128K
 join_buffer_size=4M

 query_cache_type = 1
 query_cache_size = 64M
 query_cache_min_res_unit = 2k
 query_cache_limit = 256K

 sql_mode=""

 [mysqld_safe]
 log-error=/var/log/mysqld.log
 pid-file=/var/run/mysqld/mysqld.pid

For MySQL version 8, and later versions, support for query cache has been withdrawn by MySQL development team. If you wish to obtain more information you may visit the following web link: https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/

MySQL バージョン 8 以降では、query cache のサポートが廃止されました。詳細については、https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/ を参照してください。

If you are using MySQL 8 and do not have an HA environment, disable the binary logs with the following command in section [mysqld]:

MySQL 8 を利用しており HA 環境が無い場合 は、[mysqld] セクションの次のコマンドでバイナリログを無効化します。

skip-log-bin

If there is any change in my.cnf file, restart MySQL service.

my.cnf ファイルを変更したら、MySQL サービスを再起動します。

Verify the service status with systemctl status mysqld.service.
Take a look at the end of the /var/log/mysqld.log for any error.
For more information check the following link in MySQL website.

systemctl status mysqld.service にてサービスの状態を確認します。
エラーの確認には /var/log/mysqld.log の最後を見てください。
より詳細は、MySQL サイトのこちらを確認してください。

データベースのリストア

To find out more about Server management and administragion, go to this link.

サーバ管理のより詳細は、こちらを確認してください。

when my.cnf file is modified, one of the most well knonw inconveniences consists in configuring the new values for transaction logs. If the following error appeats, back up the database and restore the previous configuration (use root user credentials):

my.cnf ファイルを変更する場合の共通の問題としては、トランザクションログの値があります。ログに次のようなエラーが出た場合は、データベースをバックアップし以前の設定をリストアします。(root 権限を利用)

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 67108864 bytes!

1. バックアップを作成したら、MySQL サービスを停止します。

systemctl stop mysql

2. MySQL データファイルがあるフォルダ(デフォルトは /var/lib/mysql)へ行きます。

cd /var/lib/

3. フォルダを他の場所へ移動します。(/var/lib/mysql → /var/lib/mysql_backup)

mv mysql mysql_old

4. 新たなフォルダを作成します。(/var/lib/mysql)

mkdir mysql

5. フォルダのオーナーを設定します。

chown -R mysql. mysql

6. MySQL データでフォルダを初期化します。

mysql_install_db --datadir =/var/lib/mysql

7. サービスを開始します。

systemctl start mysql

If you receive the folloring error:

failed to retrieve rpm info for /var/lib/musql/ibdata1

you propably have SELinux working. You may verify if it was denied when executing the following command:

cat /var/log/audit/audit.log | grep /var/lib/mysql/ibdata1

To disable SELinux check this section.
If you decide to keep working with SELinux, check this other section.

次のようなエラーとなった場合、

failed to retrieve rpm info for /var/lib/musql/ibdata1

SELinux が動作している可能性があります。次のコマンドを実行すると、拒否されたかどうかを確認できます。

cat /var/log/audit/audit.log | grep /var/lib/mysql/ibdata1

SELinux を無効化するには、こちらを確認してください。
SELinux を有効化した状態で利用する場合は, こちらを確認してください。

8. 設定プログラムを起動し、ウィザードに従います。

mysql_secure_installation

9. Login into MySQL command line. Rebuild the database:

9. MySQL へコマンドラインからログインし、データベースを再構築します。

mysql> create database pandora;

You may need to assign again the password for the root user in MySQL. For that use this command, replacing 'pandora' by the password you set in step numbre 8 of this same section:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');

MySQL の root ユーザのパスワードを設定する必要があるかもしれません。それには以下のコマンドを実行します。pandora の部分は任意のパスワードに置き換えてください。

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');

10. ユーザに権限を割り当てます。

 mysql> grant all privileges on pandora.* to pandora@'localhost' identified by 'pandora';
 mysql> grant all privileges on pandora.* to pandora@'127.0.0.1' identified by 'pandora';

11. バックアップを読み込みます。

mysql> use pandora;
mysql> source /path/to/your/backup.sql

Sometimes MySQL/Percona systems do not load the my.cnf configuration tokens correctly (usually because you put these tokens outside [mysqld] section)

時々、MySQL/Percona システムは my.cnf の設定を正しく読み込みません。(通常、[mysqld] セクションの外にトークンがある場合です)

After configuring my.cnf file and restarting MySQL service, check that changes were properly applied. To do that, use SHOW VARIABLES command (the result may contain more than one hundred elements and be different from the following summary)::

my.cnf を編集後、mysql を再起動したのち、設定が反映されて動作しているかを確認する必要があります。それには、SHOW VARIABLES コマンドを用います。(結果には 100を超える要素が含まれる可能性があり、次の結果とは異なる場合があります)

mysql> show variables like 'innodb%';
+-----------------------------------------+------------------------+
| Variable_name                           | Value                  |
+-----------------------------------------+------------------------+
| innodb_adaptive_hash_index              | ON                     |
| innodb_additional_mem_pool_size         | 1048576                |
| innodb_autoextend_increment             | 8                      |
| innodb_autoinc_lock_mode                | 1                      |
| innodb_buffer_pool_size                 | 8388608                |
| innodb_checksums                        | ON                     |
| innodb_commit_concurrency               | 0                      |
| innodb_concurrency_tickets              | 500                    |
| innodb_data_file_path                   | ibdata1:10M:autoextend |
| innodb_data_home_dir                    |   |
| innodb_doublewrite                      | ON                     |
| innodb_fast_shutdown                    | 1                      |
| innodb_file_io_threads                  | 4                      |
| innodb_file_per_table                   | OFF                    |
| innodb_flush_log_at_trx_commit          | 1                      |
| innodb_flush_method                     |   |
| innodb_force_recovery                   | 0                      |
| innodb_lock_wait_timeout                | 50                     |
| innodb_locks_unsafe_for_binlog          | OFF                    |
| innodb_log_buffer_size                  | 1048576                |
| innodb_log_file_size                    | 5242880                |
| innodb_log_files_in_group               | 2                      |
| innodb_log_group_home_dir               | ./                     |
| innodb_max_dirty_pages_pct              | 90                     |
| innodb_max_purge_lag                    | 0                      |
| innodb_mirrored_log_groups              | 1                      |
| innodb_open_files                       | 300                    |
| innodb_rollback_on_timeout              | OFF                    |
| innodb_stats_method                     | nulls_equal            |
| innodb_stats_on_metadata                | ON                     |
| innodb_support_xa                       | ON                     |
| innodb_sync_spin_loops                  | 20                     |
| innodb_table_locks                      | ON                     |
| innodb_thread_concurrency               | 8                      |
| innodb_thread_sleep_delay               | 10000                  |
| innodb_use_legacy_cardinality_algorithm | ON                     |
+-----------------------------------------+------------------------+

You may also check the variables one by one:

以下の変数もひとつずつ確認します。

mysql> show variables like 'innodb_log_file_size';
mysql> show variables like 'innodb_io_capacity';
mysql> show variables like 'innodb_file_per_table';

各テーブルごとに分割されたデータファイルがアクティブであるか確認

ls -lah /var/lib/mysql/pandora/*.ibd | wc -l

“innodb_file_per_table” トークンを有効化した場合、それぞれのテーブルに対応した “.ibd” ファイルが 100以上(Pandoraのバージョンに依存)存在します。このようなファイルが無い場合は、全データが大きなファイルに記録されます。これは、テーブルのフラグメンテーションが全テーブル共通して発生し、毎週パフォーマンスが劣化することを意味します。

すでに単一のデータベースで実行している場合は、設定を変更し MySQL を再起動したあとにデータベースを再作成する必要があります。

テーブルごとのフラグメンテーションを確認

MySQL の CLI を使って、以下のクエリを実行します。

Select ENGINE, TABLE_NAME,Round( DATA_LENGTH/1024/1024) as data_length , round(INDEX_LENGTH/1024/1024) as index_length, round(DATA_FREE/ 1024/1024) as data_free, (data_free/(index_length+data_length)) as frag_ratio from information_schema.tables  where  DATA_FREE > 0 order by frag_ratio desc;

フラグメンテーションのあるテーブルが次のように表示されます。

+--------+-------------------------+-------------+--------------+-----------+------------+
| ENGINE | TABLE_NAME              | data_length | index_length | data_free | frag_ratio |
+--------+-------------------------+-------------+--------------+-----------+------------+
| InnoDB | tserver_export_data     |           0 |            0 |         5 |   320.0000 |
| InnoDB | tagent_module_inventory |           0 |            0 |         6 |    25.6000 |
| InnoDB | tagente_datos_inventory |           4 |            0 |        40 |     9.8842 |
| InnoDB | tsesion_extended        |           1 |            0 |         4 |     3.3684 |
| InnoDB | tagent_access           |           2 |            7 |        27 |     2.9845 |
| InnoDB | tpending_mail           |           2 |            0 |         4 |     2.6392 |
| InnoDB | tagente_modulo          |           2 |            0 |         4 |     2.1333 |
| InnoDB | tgis_data_history       |          24 |           11 |        67 |     1.9075 |
| InnoDB | tsesion                 |           2 |            0 |         4 |     1.7778 |
| InnoDB | tupdate                 |           3 |            0 |         3 |     1.1852 |
| InnoDB | tagente_datos           |         186 |          194 |       399 |     1.0525 |
| InnoDB | tagente_datos_string    |          15 |            9 |        24 |     0.9981 |
| InnoDB | tevento                 |         149 |           62 |        46 |     0.2183 |
| InnoDB | tagente_datos           |        2810 |         2509 |        65 |     0.0122 |
| InnoDB | tagente_datos_string    |         317 |          122 |         5 |     0.0114 |
+--------+-------------------------+-------------+--------------+-----------+------------+

10% 以上フラグメンテーションがあるテーブルに対してのみ対応します。

10% 以上のフラグメンテーションがあるテーブルのみを対象とします。大きなテーブル(tagente_datos など)は、フラグメンテーションが大きいと最適化に長時間かかります。本番システムでは大きなインパクトとなりますので、注意してください。

“tagent_module_inventory” テーブルを最適化するには次のようにします。

optimize table  tagent_module_inventory;

次のような警告メッセージが表示されます。

"Table does not support optimize, doing recreate + analyze instead".

再度確認すると、フラグメンテーションが無くなっていることがわかります。

+--------+-------------------------+-------------+--------------+-----------+------------+
| ENGINE | TABLE_NAME              | data_length | index_length | data_free | frag_ratio |
+--------+-------------------------+-------------+--------------+-----------+------------+
| InnoDB | tserver_export_data     |           0 |            0 |         5 |   320.0000 |
| InnoDB | tagente_datos_inventory |           4 |            0 |        40 |     9.8842 |
| InnoDB | tsesion_extended        |           1 |            0 |         4 |     3.3684 |
| InnoDB | tagent_access           |           2 |            7 |        27 |     2.9845 |
| InnoDB | tpending_mail           |           2 |            0 |         4 |     2.6392 |
| InnoDB | tagente_modulo          |           2 |            0 |         4 |     2.1333 |
| InnoDB | tgis_data_history       |          24 |           11 |        67 |     1.9075 |
| InnoDB | tsesion                 |           2 |            0 |         4 |     1.7778 |
| InnoDB | tupdate                 |           3 |            0 |         3 |     1.1852 |
| InnoDB | tagente_datos           |         186 |          194 |       399 |     1.0525 |
| InnoDB | tagente_datos_string    |          15 |            9 |        24 |     0.9981 |
| InnoDB | tevento                 |         149 |           62 |        46 |     0.2183 |
| InnoDB | tagente_datos           |        2810 |         2509 |        65 |     0.0122 |
| InnoDB | tagente_datos_string    |         317 |          122 |         5 |     0.0114 |
+--------+-------------------------+-------------+--------------+-----------+------------+

最適化を実行するには、操作を実行できるだけのディスクの空き容量が必要です。そうでないとエラーとなり処理が実行されません。

システム負荷

より一般的な事として、システムの(ディスク) I/O がボトルネックになっていないことを確認する必要があります。システムの状態を取得するのに、vmstat コマンドを実行します。

vmstat 1 10

Look at the last columns (CPU WA), a value higher than 10 means there is a disk I/O problem that should be solved.

最後のカラム (CPU WA) を見て、10より大きい値であればディスク I/O の問題があり、解決する必要があります。

Having CPU-US high is normal, but CPU-SY should not be over 10~15.

CPU-US が高いのは通常です。しかし、CPU-SY は 10～15 を超えないようにすべきです。

Usually, SWAP-SI and SWAP-SO should have value zero, if not, it means the system is using SWAP memory, which degrades performance. Increase RAM or decrease RAM usage in your applications (Pandora FMS server threads, Buffers in MySQL, etc.)

SWAP-SI および SWAP-SO はゼロであるべきです。そうでなければシステムがスワップメモリを使っていることを意味し、パフォーマンスを落とします。メモリを増やすか、アプリケーションが使うメモリを減らす(Pandora サーバのスレッド、MySQL のバッファの調整など)必要があります。

以下は、“正常” なシステムの出力サンプルです。

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  46248  78664 154644 576800    0    0     2   147    0    9  7 10 83  0  0
 0  0  46248  78656 154644 576808    0    0     0     0   49   37  0  0 100  0  0
 2  0  46248  78904 154648 576740    0    0     0   184  728 2484 63  6 31  0  0
 0  0  46248  79028 154648 576736    0    0    16   616  363  979 21  0 79  0  0
 1  0  46248  79028 154648 576736    0    0     0    20   35   37  0  1 98  1  0
 0  0  46248  79028 154648 576736    0    0     0     0   28   22  0  0 100  0  0
 1  0  46248  79028 154648 576736    0    0     0  3852  141  303  0  0 98  2  0
 2  0  46248  78904 154660 576660    0    0     0   188  642 2354 56  4 40  0  0
 1  0  46248  78904 154660 576680    0    0     0    88  190  634 13  0 86  1  0
 1  0  46248  78904 154660 576680    0    0     0    16   35   40  0  0 100  0  0
 1  0  46248  78904 154660 576680    0    0     0     0   26   21  0  0 100  0  0
 0  0  46248  78904 154660 576680    0    0     0     0   27   27  0  0 100  0  0
 1  0  46248  78904 154724 576616    0    0   112   192  608 2214 52  4 44  0  0
 0  0  46248  78904 154724 576616    0    0     0    76  236  771 16  0 84  0  0
 0  0  46248  78904 154724 576616    0    0     0    20   38   38  0  0 100  0  0
 0  0  46248  78904 154724 576616    0    0     0     0   31   21  0  0 100  0  0
 0  0  46248  78904 154740 576608    0    0     0  3192  187  322  1  0 96  3  0
 1  0  46248  79028 154756 576544    0    0    16   192  632 2087 53  5 42  0  0
 0  0  46248  79028 154760 576568    0    0     0    56  255  927 19  2 79  0  0
 0  0  46248  79028 154768 576564    0    0     0    20   33   44  0  0 100  0  0

To use MySQL table partitioning, use multiple tablespaces described above (innodb_file_per_table).

MySQL のテーブルパーティショニングを使う場合、上述の複数のテーブルスペース (innodb_file_per_table) も使用して下さい。

MySQL 5.1 では、巨大なテーブルを小さい複数の論理的なテーブルに分割することができるテーブルパーティショニングを行えるようになりました。 (詳細は MySQL のマニュアルを参照して下さい: http://dev.mysql.com/doc/refman/5.1/ja/partitioning-overview.html)

If you have large amounts of data in your Pandora FMS database (both the main one and the history one)and feel many console operations which refer to these data (e.g. drawing graph) are quite slow, improve their performance by using table partitioning.

もし Pandora FMS (メインおよびヒストリの両方の)データベースに大量のデータがあり、グラフ描画のようなデータを参照する処理がとても遅いと感じるなら、テーブルパーティショニングを行うことでパフォーマンスを改善できるでしょう。

最初に、innodb_file_per_table が有効であり、データベースがそれを使用していることを確認してください。/var/lib/mysql/pandora_history/*.ibd に多くのファイルが表示されるはずです。そうでない場合は、データベースをダンプし、my.ini を変更し、mysql を再起動し、現在のデータベースを削除して、ダンプから再作成します。

innodb_file_per_table があることを確認したら、固定日付に基づいて 2つのメインデータテーブルを異なるパーティションに分割します。この例では、2015年以降のデータを分割していますが、自分のニーズに合わせて変更できます。

これには十分なディスク容量が必要です。 tagente_datos.ibd の大きさを確認してください。10G の場合、操作を開始するには少なくとも 15GB の空きが必要です。

テーブルサイズによっては、この操作に時間がかかる場合があります。例えば、100日間(50,000,000 行を超える)約 7500 モジュールのデータを含むテーブルを分割する場合、約 1.5時間かかりました。

MySQL の CLI 以下のクエリを実行します。

ALTER TABLE tagente_datos PARTITION BY RANGE (utimestamp) (
PARTITION Ene15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-01-01 00:00:00')),
PARTITION Feb15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-02-01 00:00:00')),
PARTITION Mar15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-03-01 00:00:00')),
PARTITION Apr15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-04-01 00:00:00')),
PARTITION May15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-05-01 00:00:00')),
PARTITION Jun15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-06-01 00:00:00')),
PARTITION Jul15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-07-01 00:00:00')),
PARTITION Ago15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-08-01 00:00:00')),
PARTITION Sep15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-09-01 00:00:00')),
PARTITION Oct15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-10-01 00:00:00')),
PARTITION Nov15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-11-01 00:00:00')),
PARTITION Dec15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-12-01 00:00:00')),
PARTITION pActual VALUES LESS THAN (MAXVALUE)
);

パーティション分割を再編成するには、毎月以下のクエリを実行します。

ALTER TABLE tagente_datos REORGANIZE PARTITION pActual INTO (
PARTITION Feb16 VALUES LESS THAN (UNIX_TIMESTAMP('2016-02-01 00:00:00')),
PARTITION pActual VALUES LESS THAN MAXVALUE);

“Feb16” を当月に変更します。

tagente_datos をモジュールIDに応じて100のパーティションに分割する場合は、次のクエリを実行します:

  ALTER TABLE tagente_datos PARTITION BY HASH(id_agente_modulo) PARTITIONS 100;

“tagente_datos” テーブルの大きさによっては、この操作には数時間かかる場合があることに注意してください。実行中のパーティションファイルのサイズを見ると、進行状況を確認できます。

[root@firefly pandora_history]# ls -lah | grep "#sql"

 -rw-rw----  1 mysql mysql 424M dic 23 05:58 #sql-76b4_3f7c#P#Ago15.ibd
 -rw-rw----  1 mysql mysql 420M dic 23 05:51 #sql-76b4_3f7c#P#Apr15.ibd
 -rw-rw----  1 mysql mysql 128K dic 23 05:40 #sql-76b4_3f7c#P#Dec15.ibd
 -rw-rw----  1 mysql mysql 840M dic 23 05:44 #sql-76b4_3f7c#P#Ene15.ibd
 -rw-rw----  1 mysql mysql 440M dic 23 05:47 #sql-76b4_3f7c#P#Feb15.ibd
 -rw-rw----  1 mysql mysql  10M dic 23 05:42 #sql-76b4_3f7c#P#Jan16.ibd
 -rw-rw----  1 mysql mysql 404M dic 23 05:56 #sql-76b4_3f7c#P#Jul15.ibd
 -rw-rw----  1 mysql mysql 436M dic 23 05:54 #sql-76b4_3f7c#P#Jun15.ibd
 -rw-rw----  1 mysql mysql 400M dic 23 05:49 #sql-76b4_3f7c#P#Mar15.ibd
 -rw-rw----  1 mysql mysql 408M dic 23 05:52 #sql-76b4_3f7c#P#May15.ibd
 -rw-rw----  1 mysql mysql  72M dic 23 06:03 #sql-76b4_3f7c#P#Nov15.ibd
 -rw-rw----  1 mysql mysql 404M dic 23 06:03 #sql-76b4_3f7c#P#Oct15.ibd
 -rw-rw----  1 mysql mysql 416M dic 23 06:00 #sql-76b4_3f7c#P#Sep15.ibd

部分的再構成

MySQLは他のデータベースシステム、たとえばOracle ™と同様、時間がたつにつれ、性能が劣化していきます。これは大きなテーブルに対してデータの削除と追加を続けることによって発生するデータのフラグメンテーションによるものです。大量のトラフィックが発生する大きな環境において、性能の改善および劣化を防ぐ非常に簡単な方法があります。それは定期的にデータベースの再構築を実施することです。

そのために、1時間程度のサービス停止を計画すべきです。

In this service stop, stop the Pandora FMS WEB console and the server too (be careful, leave the Tentacle server so that it can still receive data and these will be processed as soon as the server works again).

計画的なサービス停止時に、Pandora FMS Webコンソールとサーバも停止すべきです (注意 tentacle サーバはデータを受け取れるようにしておき、サーバが復旧次第データを処理できるようにします)

サービス停止後、データベースのダンプを取得(エクスポート)します。

 mysqldump -u root -p pandora3> /tmp/pandora3.sql
 Enter password:

データベースを削除します。

> mysql -u root -p
 Enter password:

 mysql> drop database pandora3;
 Query OK, 87 rows affected (1 min 34.37 sec)

データベースを作成し、先ほどエクスポートしたデータをインポートします。

 mysql> create database pandora3;
 Query OK, 1 row affected (0.01 sec)
 mysql> use pandora3;
 mysql> source /tmp/pandora3.sql

巨大でハードウエア性能があまり高くないシステムでは、この処理全体で数分かかります。たとえば、1500エージェントおよび 100,000モジュールのシステムなどです。この処理は自動化可能ですが、細心の注意が必要なため、毎月もしくは半月に一度、手動で実行することをお勧めします。

It is possible to automatize this process, but, because it is very delicate, the best option is carry it out manually.

この処理を自動化することは可能ですが、非常にデリケートなため、手動で実行するのが最善のオプションです。

全体の再構築

この節の説明は、Innodb データベースのみ該当します。Pandora FMS は、Innodb データベースを利用しています。

時間ともに MySQL のパフォーマンスが落ちると、システム全体のパフォーマンスに影響します。この場合は、すべてのデータベーススキーマをゼロから再構築する以外に解決策はありません。MySQL がデータの保存に利用しているバイナリファイルを利用し、またそれを再構築します。

/var/lib/mysql ディレクトリを見ると、常に同じ名前で状態に応じて以下のような 3つのファイルがあります。

-rw-rw----  1 mysql mysql 4.8G 2012-01-12 14:00 ibdata1
-rw-rw----  1 mysql mysql 5.0M 2012-01-12 14:00 ib_logfile0
-rw-rw----  1 mysql mysql 5.0M 2012-01-12 14:00 ib_logfile1

ibdata1 は、すべての Innodb データを保存する先です。非常に断片化されたシステムでは、再構築やインストールをした効率の良いシステムと比べると非常に処理時間を要します。前に言及した innodb_file_per_table パラメータは、このパフォーマンスを調整します。

それぞれのデータベースは /var/lib/mysql ディレクトリにあり、一つのディレクトリで構造が定義されています。それを削除します。

手順はとても簡単です。

(mysqldump にて)全スキーマをディスクにダンプします。
```
mysqldump -u root -p -A > all.sql
```
MySQL を停止します。
ibdata1, ib_logfile0, ib_logfile1 および InnoDB データベースディレクトリを削除します。
MySQL を再起動します。
バックアップファイル(all.sql)をインポートします。
```
mysql -u root -p
 mysql> source all.sql;
```

システムが高速化します。

他のシステムリソースを犠牲にして、MySQL パフォーマンスを最適化できるいくつかの場合があります。

以下のインデックスの最適化はグラフ生成を(とても)高速化しますが、多くのディスクスペースを必要とします。また、インデックスのオーバーヘッドにより、若干 INSERT/DELETE 処理が遅くなります。

ALTER TABLE `pandora`.`tagente_datos`  ADD  INDEX  `id_agente_modulo_utimestamp`  (  `id_agente_modulo`  , `utimestamp`  );

現在、MySQL の Pandora FMS の最も重いテーブルでは、この最適化がデフォルトになっています。MySQL テーブルを最適化する前に専門家に相談するのが良いです。

いくつかのシステムでは保持している情報によって、通常よりもシステムのパフォーマンスが悪いスロウクエリが見られることがあります。テーブルを最適化するために、(システムのパフォーマンスに影響する)一定時間を超えたこのタイプのクエリをログに記録するようにできます。これを有効にするには次のようにします。

Edit my.cnf and add the following lines:

my.cnf を編集し、次の設定を加えます。

  slow_query_log = 1
  long_query_time = 2
  slow_query_log_file = /var/log/mysql_slow.log

To be able to use it and set the admin rules:

利用できるように次のように設定します。

 touch /var/log/mysql_slow.log
 chown mysql:mysql /var/log/mysql_slow.log
 chmod 640 /var/log/mysql_slow.log

Restart mysql.
When finishing analyzing which ones are the slow queries, remember to reset the file my.cnf commenting the aggregated lines and restarting again MySQL service.

mysql を再起動します。
スロウクエリの分析が終了したら、ファイル my.cnf をリセットして、集約された行にコメントを付け、MySQL サービスを再起動することを忘れないでください。

他のあまり“過激”ではないフラグメンテーションの問題を解決する方策として、Pandora FMSのテーブルのいくつかに対してMYSQL OPTIMIZEツールを使用するというのがあります。

OPTIMIZE table tagente_datos;
OPTIMIZE table tagente;
OPTIMIZE table tagente_datos_string;
OPTIMIZE table tagent_access;
OPTIMIZE table tagente_modulo;
OPTIMIZE table tagente_estado;

この作業によって、パフォーマンスが改善されるでしょう。この作業は 1週間に複数回実行する必要はありません。システムの稼働中にさっと完了するでしょう。巨大な環境においては、OPTIMIZE コマンドがブロックされるかもしれません。このような場合、一番よい代替案はDBの再構築です。

これらの作業を実施した後、以下のコマンドを実行すべきです。

FLUSH TABLES;

MySQLのマニュアルから、

InnoDB のテーブルに対しては OPTIMIZE TABLE は ALTER TABLE にマップされており、インデックス統計の更新とクラスタされたインデックス内の使用されていないスペースを解放するためにテーブルが再構築されます。

7.0 OUM715 以降のインストールでは、デフォルトで以下の設定が適用されます。

注意: Pandora FMS バージョン 7.0 OUM 715 より前では、データベース(通常の DB とヒストリ DB 共)に以下の対応をすることをお勧めします。

alter table tagente_datos add index (id_agente_modulo,utimestamp);

この操作は、tagente_data テーブルにインデックスを追加します。以前よりも、レポートシステム、データのクエリ、モジュール、カスタムグラフで大幅に処理が短縮されます。

There are some very “special” tokens in MySQL, which can improve or worsen the performance:

MySQL には、いくつかの “特別な” トークンがあります。これらは、パフォーマンスを良くしたり悪くしたりします。

innodb_thread_concurrency:

 # Set to 0 in mysql 5.1.12 or higher
 innodb_thread_concurrency            = 20

This parameter in versions 5.1.12 or higher, on 0 value, means there is no limit on concurrency, BUT in previous versions, the same meaning is achieved with value 20.

この innodb_thread_concurrency というパラメータは、5.1.12 以降のバージョンに存在し、0 の場合、平行処理の制限がなくなります。しかし、以前のバージョンでは、20を設定すると同様の意味になります。

innodb_flush_method:

innodb_flush_method = O_DIRECT

This important parameter has an effect on how information is written on the disk.

この重要なパラメータは、ディスクにデータをどう書くかに影響します。

innodb_lock_wait_timeout:

innodb_lock_wait_timeout = 90

This helps when there is a bottleneck, so that MySQL does not go away and stops. If it lasts more than 90 lock, there is a real problem.

これは、データベースが長いトランザクションによりロックし“スタック”状態になったとき(mysqlはメッセージを出力しません)に有効です。ただし、もし、90以上のロックがあるのであれば、それは本当に何らかの問題がある場合です。

参考:

Percona is an improved version of MySQL, particularly regarding scalability (fast growth without affecting or slightly affecting work operations and routines). Make the most out of all the system's CPUs, speeding up also disk transactions.

Percona は、MySQL の “ハイパフォーマンス” 版で、スケーラビリティ改善およびシステムの全 CPU を利用した高速化、また、ディスクのアクセス改善がされています。

To configure your percona server, use their excelent online configuration wizard, which will generate the /etc/my.cnf file: Percona Wizard Configurator

percona サーバを設定するには、/etc/my.cnf を生成する、それ用のよくできた次の設定ウィザードを利用することができます。Percona 設定ウィザード

この章では、高いキャパシティが必要な環境での Pandora FMS を設定するための異なる手法を説明します。また、処理を実行する環境を調整するのに便利な負荷テストを行うためのツールについても説明します。

Pandora FMS は、1つのサーバでデータベース、コンソール、サーバを動かした場合、2500エージェントに対応できるように設定されています。推奨するエージェント数は、1システムあたり 2500 です。しかし、この数は、XML エージェントの割合、リモートモジュールの割合、監視間隔、システムのメモリ量に応じて変化します。

これらの全ての要素が、1つのシステムで管理できるエージェント数に関わります。テスト環境では、通常のハードウエアの 1台のサーバで 10000 エージェントを実行できましたが、高度な最適化をしています。

例えば、16GB の RAM および 4 CPU のマシンで、データサーバが最大のパフォーマンス (XML 処理) を出すように最適化したいと思います。

Only the most important parameters are shown).

重要なパラメータのみを示しています。

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
character-set-server=utf8
skip-character-set-client-handshake
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Mysql optimizations for Pandora FMS
# Please check the documentation in http://pandorafms.com for  better results
max_allowed_packet = 64M
innodb_buffer_pool_size = 800M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
thread_cache_size = 8
thread_stack    = 256K
max_connections = 100
wait_timeout = 900
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 1
query_cache_size = 64M
query_cache_min_res_unit = 2k
query_cache_limit = 256K
sql_mode=""
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

For MySQL version 8, and later versions, support for query cache has been withdrawn: Although it was intended to improve performance, it has serious scalability problems and can easily become a serious bottleneck.

MySQL バージョン 8 以降では、query cache のサポートが廃止されました。パフォーマンスの向上を目的としていますが、スケーラビリティに深刻な問題があり、簡単に深刻なボトルネックになる可能性があります。

重要なパラメータのみを示しています。

 verbose 3
 server_threshold 5
 dataserver_threads 1
 max_queue_files 5000

以下の点を認識しておく必要があります。

The verbose parameter number refers to the amount of information written in the logs, being recommended not to exceed 10. The higher the number, the worse the Pandora FMS performance will be, due to the great amount of information to write in the logs.

verbose の数は、どの程度の情報をログに書くかで、10を超える数字にはしないでください。数字を大きくすると、ログに多くの情報を書くため、Pandora FMS のパフォーマンスが下がります。

A high number (15) of the parameter server_threshold makes the database to bear a lower impact, while the increase in the maximum number of files processed makes the server to look for files and fill up the buffers. These two elements od the setup are closely related. In the case of optimizing the network server, it would be advisable to lower server_threshold to 5 or 10.

パラメータ server_threshold の数が大きい(15)と、データベースへの影響が少なくなり、処理されるファイルの最大数を大きくすると、サーバはファイルを検索してバッファをいっぱいにします。 これら 2つの要素の設定は密接に関連しています。ネットワークサーバを最適化する場合は、server_threshold を 5 または 10 より下げることをお勧めします。

A very high number of threads (more than 5) set in dataserver_threads only benefits processes with long E/S waiting time, such as the network server or the plugin server. In the case of the dataserver, that is in constant process, may even affect performance. In systems with a slow database, use even less threads: try out different combinations between 1 and 10. In case of optimizing the system for the networkserver, the number would be a lot greater, between 10 and 30.

dataserver_threads に設定された非常に多数のスレッド(5以上)は、ネットワークサーバやプラグインサーバなど、E/S 待機時間が長い処理がある場合にのみメリットがあります。継続的に処理されているデータサーバの場合は、パフォーマンスに影響を与える可能性さえあります。データベースの速度が遅いシステムでは、使用するスレッドをさらに少なくします。1〜10 のさまざまな組み合わせを試してください。ネットワークサーバ用にシステムを最適化する場合、その数は 10〜30の間の大きな値にします。

Some configuration parameters could affect a lot Pandora FMS performance, such as the agent_access parameter (configurable from the console).

agent_access (コンソールから設定できます) のようないくつかの設定パラメータは、Pandora FMS のパフォーマンスに多くの影響を与えます。

Pandora FMS には、ハードウエアおよびソフトウエアで、取得可能なデータ量を適切に計測できるいくつかのツールがあります。一つは、ダミーデータで直接データベースへアクセスするもの (dbstress)、もう一つは、ダミーの XML ファイルを生成するもの (xml_stress) です。

Pandora FMS の XML 負荷

This is an small script that generates XML data files like the ones sent by Pandora FMS agents. It is placed on:

Pandora FMS エージェントから送られるような XML データファイルを生成する小さなスクリプトが以下にあります。

/usr/share/pandora_server/util/pandora_xml_stress.pl

The scripts read agent names from a text file and generate XML data files for each agent according to a configuration file, where modules are defined as templates.

スクリプトは、テキストファイルからエージェント名を読み取り、設定ファイルに従って各エージェントの XML データファイルを生成します。ここで、モジュールはテンプレートとして定義されています。

モジュールの値はランダムな値になります。モジュールデータの初期値および変化率は設定可能です。

スクリプトは次のように実行します。

./pandora_xml_stress.pl <設定ファイル>

Sample configuration file called pandora_xml_stress.conf:

pandora_xml_stress.conf 設定ファイルの例を示します。

 # Maximum number of threads, 10 by default.
 max_threads 10

 # File containing a list of agent names (one per line).
 agent_file agent_names.txt

 # Directory where XML data files will be placed, /tmp by default.
 temporal /var/spool/pandora/data_in

 # Pandora FMS XML Stress log file, logs to stdout by default.
 log_file pandora_xml_stress.log

 # XML version, 1.0 by default.
 xml_version 1.0

 # XML encoding, ISO-8859-1 by default.
 encoding ISO-8859-1

 # Operating system (shared by all agents), Linux by default.
 os_name Linux

 # Operating system version (shared by all agents), 2.6 by default.
 os_version 2.6

 # Agent interval, 300 by default.
 agent_interval 300

 # Data file generation start date, now by default.
 time_from 2009-06-01 00:00:00

 # Data file generation end date, now by default.
 time_to 2009-06-05 00:00:00

 # Delay after generating the first data file for each agent to avoid
 # race conditions when auto-creating the agent, 2 by default.
 startup_delay 2

 # Address of the Tentacle server where XML files will be sent (optional).
 # server_ip 192.168.50.1

 # Port of the Tentacle server, 41121 by default
 # server_port 41121

 # Module definitions. Similar to pandora_agent.conf.

 module_begin
 module_name Module 1
 module_type generic_data
 module_description A long description.
 module_max 100
 module_min 10
 module_exec type=RANDOM;variation=60;min=20;max=80
 module_end

 module_begin
 module_name Module 2
 module_type generic_data
 module_description A long description.
 module_max 80
 module_min 20
 module_exec type=SCATTER;prob=1;avg=40;min=0;max=80
 module_end

 module_begin
 module_name Module 3
 module_type generic_data
 module_description A long description.
 module_max 80
 module_min 20
 module_exec type=CURVE;min=20;max=80;time_wave_length=3600;time_offset=0
 module_end

 module_begin
 module_name Module 4
 module_type generic_data_string
 module_description A long description.
 module_max 100
 module_min 10
 module_exec type=RANDOM;variation=60;min=20;max=80
 module_end

 module_begin
 module_name Module_3
 module_type generic_proc
 module_descripcion Module 3 description.
 # Initial data.
 module_data 1
 module_end

エージェントのローカル設定の送受信

If you activate in your pandora_xml_stress.conf the get_and_send_agent_conf configuration value to 1, you can make the test load agents work as normal agents, so that they send their configuration file and also the md5.

pandora_xml_stress.conf で、get_and_send_agent_conf を 1 に設定して実行した場合、テスト負荷エージェントで、通常のエージェントのように設定ファイルおよび md5 を送ることができます。

From Pandora FMS Console Enterprise, you can change the remote configuration so that in following executions of pandora_xml_stress, it uses the customized configuration from the Pandora FMS Enterprise Console instead of doing it through the pandora_xml_stress.conf definition.

Enterprise 版の Pandora コンソールでは、pandora_xml_stress で実行する内容をリモートでの設定変更で行うことができます。pandora_xml_stress.conf ではなく、Enterprise 版の Pandora コンソールから行った設定を利用するようになります。

Besides this, you may configure where to store locally the .conf files of your testing agents with the directory_confs configuration token in the pandora_xml_stress.conf file.

ほかにも、pandora_xml_stress.conf 内の directory_confis にて、テストエージェントの設定ファイル .conf をどこに保存するかを設定できます。

設定ファイル

max_threads スクリプトの実行スレッド数。処理率を改善します。
agent_file 行ごとに名前を書いたファイルのパス。
temporal 架空の XML データファイルを生成するディレクトリのパス。
log_file スクリプトの実行について情報を出力するログのパス。
xml_version XML データファイルのバージョン。(デフォルトは 1.0)
encoding XML データファイルのエンコーディング。(デフォルトは ISO-8859-1)
os_name 仮想エージェントの OS 名。(デフォルトは Linux)
os_version 仮想エージェントの OS バージョン。(デフォルトは 2.6)
agent_interval 仮想エージェントの実行秒間隔。(デフォルトは 300)
time_from 仮想 XML データの開始時間。“年-月-日時間:分:秒” というフォーマットにて。
time_to 仮想 XML データの終了時間。“年-月-日時間:分:秒” というフォーマットにて。
get_and_send_agent_conf 0 または 1 の値です。有効な場合、仮想エージェントは、リモート設定により、より新しいエージェントの設定ファイルをダウンロードしようとします。Pandora FMS Enterprise のコンソールから編集可能になります。
startup_delay それぞれのエージェントがファイル生成を開始するまでの時間を秒で指定します。競合を回避するために利用します。
timezone_offset タイムゾーンのオフセット値です。
timezone_offset_range ランダムに指定した範囲でタイムゾーンを生成します。
latitude_base 数値です。仮想エージェントを表示する緯度です。
longitude_base 数値です。仮想エージェントを表示する経度です。
altitude_base 数値です。仮想エージェントを表示する高度です。
position_radius 数値です。指定した半径内の円に仮想エージェントがランダムに表示されます。

モジュール定義

スクリプト設定の中に一つのモジュール定義があり、リモート設定を有効にした場合も一緒で、次の通りです。

module_begin
module_name <モジュール名>
module_type <タイプ, 例: generic_data>
module_description <説明>
module_exec type=<type_generation_xml_stress>;<; 区切りの他のオプション>
module_unit <ユニット>
module_min_critical <値>
module_max_critical <値>
module_min_warning <値>
module_max_warning <値>
module_end

それぞれの項目は次のように設定可能です。

type_generation_xml_stress: RANDOM,SCATTER,CURVEのいずれかを設定できます。
module_attenuation <値>: モジュールの値を指定した値で掛け合わせます。通常 0.1 と 0.9 の間です。
module_attenuation_wdays <値> <値> … <値>: 指定した日にのみモジュールの値を計算します。日曜(0) から土曜(6) を指定できます。例えば、以下のモジュールでは、土曜と日曜にネットワークトラフィックを 50% にします。

module_begin
module_name Network Traffic
module_type generic_data
module_description Incoming network traffic (Kbit/s)
module_exec type=RANDOM;variation=50;min=0;max=1000000
module_unit Kbit/s
module_min_critical 900000
module_attenuation 0.5
module_attenuation_wdays 0 6
module_end

module_incremental <値>: 1に設定すると、モジュールの以前の値を常に新たな値に加えます。値が増え続ける機能です。
その他: 実効タイプに依存して、どのようなオプションがあるかは以下を確認してください。

Note that min_critical, max_critical, min_warning and max_warning are only available in version 5.0 or later versions.

min_critical, max_critical, min_warning および max_warning は、バージョン 5.0 以上にのみであることに注意してください。

RANDOM

次のオプションがあります。

variation 前回の値から変化が発生する可能性を % で指定します。
min 値の最小値を指定します。
max 値の最大値を指定します。

Numeric

min と max の間の数値をランダムに生成します。

Boleans

0 または 1 の値を生成します。

String

min と max の間の長さの文字列を生成します。文字は、A から Z の間のランダムで、大文字、小文字を含み、また数字や記号を含みます。

外部データソース (SOURCE)

データのソースとしてプレーンテキストファイルを利用することができます。次のオプションがあります。

src: ソースデータファイル

ファイルは、1行に1データを含む形式で、行数に制限はありません。例えば次の通りです。

二種類のデータ(数値と文字列)を扱うことができます。これらのモジュールは、ファイルのデータ順番に読み込んで、Pandora でのモジュールデータを生成します。上記のデータの例では、次のように表示されます。

4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10

SCATTER

数値データの場合のみ有用で、ハートビートのようなグラフを生成します。これは通常の値で、ある時間に “beat” を出します。

次のオプションがあります。

min とりうる最小の値。
max とりうる最大の値。
prob “beat” を生成する頻度を % で指定します。
avg “beat” が無い場合に、デフォルトで表示する平均値。

CURVE

三角関数を使った曲線でモジュールデータを生成します。次のオプションがあります。

min とりうる最小の値。
max とりうる最大の値。
time_wave_length 山が出現する時間。
time_offset モジュールの値が 0 の時の波形の開始タイミングを秒で指定します。(正弦波に似ています)

注意事項

This tool is preconfigured to look for, in all agents, “random”, “curve” or boolean name modules that use an interval between 300 seconds and 30 days.

このツールは、すべてのエージェントで、300秒から 30日の間隔を使用する “random”、“curve”、またはブール名のモジュールを検索するように事前設定されています。

データサーバの処理能力の計測方法

There is a small script called pandora_count.sh that is found in the /usr/share/pandora_server/util/ directory in Pandora FMS server directory. This script is used to measure the processing rate of XML files by the data server, and it uses as reference all the files yet to be processed at /var/spool/pandora/data_in, so to be able to use it, thousands of packages yet to be processed are needed (or they must be generated with the tool mentioned before). Once running, you may stop it pressing the keys CTRL+C.

pandora_count.sh というスクリプトが Pandora FMS サーバパッケージの /usr/share/pandora_server/util/ ディレクトリにあります。このスクリプトは、データサーバの XML ファイル処理率を計測するのに利用します。このツールは、/var/spool/pandora/data_in に残っているファイルを利用します。そのため、未処理の数千のファイルを用意しておく (もしくは前述のツールで生成しておく) 必要があります。実行後は、CTRL+C で停止できます。

This script takes into account only the packages currently existing, and it take them away from the packages existing 10 seconds ago, then divides the result by 10, and these will be the files that have been processed in the last 10 seconds, showing the rate per second. It is a rudimentary solution but it is helpful to fix the server configuration.

このスクリプトは、現在存在するファイルをカウントし、10秒前に処理したものを除外し、結果を 10 で割ることによって、1秒間の処理率を求めています。これは初歩的なソリューションですが、サーバの設定を修正するための情報を提供します。

Pandora FMS の DB 負荷

データベースパフォーマンスを確認するためのツールがあります。これはまた、架空のデータを定期的もしくは不定期に生成するためにも利用できます。エージェントを作成し、このツールを使って自動的にデータを挿入するためのモジュールを作成しておく必要があります。

random: 不定期データを生成します。
curve: 三角関数を利用して曲線データを生成します。異なる間隔で補完を見るのに便利です。
boolean: ランダムな boolean データを生成します。

random, curve および boolean という語を含む任意の名前を使うことができます。

random_1
curve_other

data_server モジュールのみ選択することができます。

Pandora FMS の DB 負荷 ツールの調整

このツールは、すべてのエージェントから、random、curve または boolean という名前がついかモジュールを検索するようにあらかじめ設定されています。また、実行間隔は 300秒から 30日の間を指定できます。

もしこの設定を変更したい場合は、pandora_dbstress スクリプトを編集し、ファイルの先頭にあるいくつかの変数を変更する必要があります。

 # Configure here target (AGENT_ID for Stress)
 my $target_module = -1; # -1 for all modules of that agent
 my $target_agent = -1;
 my $target_interval = 300;
 my $target_days = 30;

The first line of the variable corresponding with target_module should be fixed for a fix module or -1 to process all the matching targets.
The second line of variable must match target_agent, for a specific agent.
The third line must match target_interval, defined in seconds and which represents the module predefined periodical interval.
The fourth line is target_days and represents the number of days in the past since the date, in the current timestamp.

最初の行の target_module の設定では、対象のモジュールを指定するか -1 を指定すると全てが対象になります。
2行目の target_agent は、エージェントの指定です。
3行目の target_interval は、秒単位で実行間隔を指定します。
4行目の target_days は、現在日時から何日後までかを表します。

時々、ユーザが問題に遭遇し、Pandora の開発者もユーザのシステムについての詳細情報が無くて手助けできないことがあります。バージョン 3.0 では、ユーザの問題を解決する手助けとなる 2つの小さなツールを作成しました。

Pandora FMS の最新バージョンには、Pandora FMS のインストールに関する診断情報を取得する機能があります。

It is inside the section of Admin tools → Diagnostic Info

それは、管理ツール(Admin tools) → 診断情報(Diagnostic Info) にあります。

このウインドウでは、Pandora FMS と MySQL の設定情報を見ることができるのに加えて、自己監視システムのグラフを見ることができます。

/usr/share/pandora_server/util にあるツールで、システムの多くの情報を取得します。

CPU 情報
Uptime および CPU ロードアベレージ
Memory 情報
Kernel/Release 情報
mysql 設定ファイルの内容
PandoraFMS サーバ設定ファイルの内容 (パスワードはフィルタリングされます)
Pandora FMS ログ情報 (ただし、全ログではありません)
Disk 情報
Pandora FMS プロセス情報
kernel ログ情報 (dmesg)

すべての情報は、.txt ファイル内に生成されるので、この情報を手助けしてくれる人に送信することができます。たとえば、Pandora FMS ユーザフォーラムや Pandora FMS public メーリングリストなどです。この情報には、機密情報は含まれません。pandora_server.conf および my.cnf ファイルの内容を取得したい場合は、root 権限で実行する必要があることに注意してください。

以下に実行例を示します。

$ ./pandora_diagnostic.sh 
 
Pandora FMS Diagnostic Script v1.0 (c) ArticaST 2009
http://pandorafms.org. This script is licensed under GPL2 terms
 
Please wait while this script is collecting data
  
Output file with all information is in '/tmp/pandora_diag.20090601_164511.data'

また、出力ファイルの例を示します。

Information gathered at 20090601_164511
Linux raz0r 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:27:06 UTC 2009 i686 GNU/Linux
=========================================================================
-----------------------------------------------------------------
CPUINFO
-----------------------------------------------------------------
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
.
.
-----------------------------------------------------------------
Other System Parameters
-----------------------------------------------------------------
Uptime:  16:45:11 up  5:27,  2 users,  load average: 0.11, 0.12, 0.09
-----------------------------------------------------------------
PROC INFO (Pandora)
-----------------------------------------------------------------
slerena  11875  0.9  2.1 114436 44336 pts/0    Sl   13:14   1:56 gedit pandora_diagnostic.sh
slerena  24357  0.0  0.0   4452  1524 pts/0    S+   16:45   0:00 /bin/bash ./pandora_diagnostic.sh
-----------------------------------------------------------------
MySQL Configuration file
-----------------------------------------------------------------
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
.
.
.
-----------------------------------------------------------------
Pandora FMS Logfiles information
-----------------------------------------------------------------
total 3032
drwxr-xrwx  2 root    root       4096 2009-04-30 20:00 .
drwxr-xr-x 17 root    root       4096 2009-06-01 11:24 ..
-rw-r-----  1 root    sys      377322 2009-04-06 00:12 pandora_agent.log
-rw-r--r--  1 root    root          0 2009-04-06 00:15 pandora_agent.log.err
-rw-r--r--  1 root    root      13945 2009-04-02 21:47 pandora_alert.log
-rw-r--r--  1 slerena slerena 2595426 2009-04-30 20:02 pandora_server.error
-rw-rw-rw-  1 root    root       9898 2009-04-30 20:02 pandora_server.log
-rw-rw-rw-  1 root    root      65542 2009-04-30 20:00 pandora_server.log.old
-rw-r--r--  1 root    root         94 2009-04-06 00:19 pandora_snmptrap.log
-rw-rw-rw-  1 root    root          4 2009-04-03 14:16 pandora_snmptrap.log.index
-----------------------------------------------------------------
System disk
-----------------------------------------------------------------
S.ficheros            Tamaño Usado  Disp Uso% Montado en
/dev/sda6              91G   49G   37G  58% /
tmpfs                1003M     0 1003M   0% /lib/init/rw
varrun               1003M  260K 1002M   1% /var/run
varlock              1003M     0 1003M   0% /var/lock
udev                 1003M  184K 1002M   1% /dev
tmpfs                1003M  480K 1002M   1% /dev/shm
lrm                  1003M  2,4M 1000M   1% /lib/modules/2.6.28-12-generic/volatile
-----------------------------------------------------------------
Vmstat (5 execs)
-----------------------------------------------------------------
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  0      0 684840 119888 619624    0    0    15    10  258  474  3  1 95  0
 0  0      0 684768 119888 619640    0    0     0     0  265  391  0  0 100  0
 0  0      0 684768 119892 619636    0    0     0    56  249  325  1  1 99  0
 0  0      0 684768 119892 619640    0    0     0     0  329  580  0  0 100  0
 0  0      0 684776 119892 619640    0    0     0     0  385 1382  1  0 99  0
-----------------------------------------------------------------
System dmesg
-----------------------------------------------------------------
[    0.000000] BIOS EBDA/lowmem at: 0009f000/0009f000
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.28-12-generic (buildd@rothera) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) )   #43-Ubuntu SMP Fri May 1 
19:27:06 UTC 2009 (Ubuntu 2.6.28-12.43-generic)
.
.
-----------------------------------------------------------------
END OF FILE
-----------------------------------------------------------------
560e8fa02818916d4abb59bb50d91f6a  /tmp/pandora_diag.20090601_164511.data

¹⁾

http://optimmysql.blogspot.com/2008/04/variable-day-out-5-innodbthreadconcurre.html

²⁾

[http://mysqlha.blogspot.com/2010/03/do-we-still-need-innodbthreadconcurrenc.html]

Pandora FMS の最適化と問題解決