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 database configuration.

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

All tests and validations are performed with Percona Server for MySQL® 8 (recommended option). Due to the similarities between Percona Server for MySQL 8 and MySQL® 8 there is great compatibility between both solutions. For the practical purposes of this topic the term MySQL is used, always bearing in mind that tests are performed on Percona Server for MySQL.

すべてのテストと検証は、Percona Server for MySQL® 8 (推奨オプション) を使用して実行しています。Percona Server for MySQL 8 と MySQL® 8 は類似しているため、両方のソリューションの間には優れた互換性があります。ここでの説明では MySQL という用語が使用されています が、テストは Percona Server for MySQL で実行されることを常に念頭に置いてください。

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

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

• MySQL recommends using a 64-bit system. 32-bit systems may have serious problems from 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 a system will be 4 GB. A good choice for a large system is 16 GB. 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 may use symbolic links for this. Use different disks for the system, the database and, if necessary, binary replication logs.

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

• If you start the client and MySQL server are 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. Disable the start of the binary session and the replication if it only launches a MySQL host server.
• Pandora FMS works on MySQL and it is recommended to use the modified version of MySQL (Percona Server for MySQL), which offers better performance. The plugins programmed are for Percona®.

• もし、MySQLサーバとクライアントを同じマシン上で起動するなら、TCP/IPのかわりにsocketを使用してMySQLサーバへ接続しましょう(これにより7.5%性能が改善されます)。MySQLサーバに接続する際、ホスト名を指定しないかlocalhost と指定することでsocket経由で接続することができます。MySQLサーバを1台しか起動しないのであれば、binary logの出力とレプリケーションを無効にしましょう。
• Pandora FMS は MySQL で動作し、よりパフォーマンスの高い、修正版の MySQL (Percona Server for MySQL) を使うことを強くお勧めします。デフォルトでは、プラグインは Percona® 用に作成しています。

Please note that the following items greatly affect performance:

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

• Only use binary logs if you use a MySQL configuration with replication.
• Do not use logs tracing queries or slow query logs. This is only recommended in specific cases.
• MySQL® でレプリケーション設定を行う時のみ binary log を利用してください。
• クエリのトレースログや スロークエリログ は利用しないでください。これは特定の場合にのみ推奨されます。

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:

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

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

Comment both lines, and then restart MySQL Server.

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

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 です。これは、トランザクション量が多い本番環境では非常に低い値です。 稼働中のシステムで値を変更するには、次のようにします。

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

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

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 = 300

This parameter has the value 200 by default, but you have to know the IOPS of the system disk. You may find out exactly by looking for IOPS and the exact hard disk model, where the recommended values are: 7500RPM → 100 IOPS, 15000 RPM → 190 IOPS, SSD → 1500 IOPS. More information in this link.

デフォルトでは、このパラメータの値は 200 です。ただし、事前にシステムのディスクの IOPS を知る必要があります。正確な IOPS およびハードディスクのモデルを知ることができます。ここでのお勧めの値は、7500RPM → 100 IOPS, 15000 RPM → 190 IOPS, SSD → 1500 IOPS です。詳しくはこちらのリンクを参照ください。

innodb_file_per_table

Use a tablespace for each table:

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

In Percona, itis 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.

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

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

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

Multiple tablespaces can be enabled by adding this line to the mysqld section of the my.cnf file:

マルチプルテーブルスペースは 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 parameter 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 tablespace. 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 tablespaces.

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 によって、ディスクへの書き込みが発生するということを意味します。

So, would it be bad if it always writes on the disk? Not at all. It ensures that when there is any compromising event, the data will be there when the database is restored after an incident. The problem is that the DB performance is limited by the physical speed of the disk.

さて、常にディスクへ書き込むのはよくないのでしょうか？そんなことはありません。これにより、侵害イベントが発生した場合でも、インシデント後にデータベースが復元されたときにデータが確実に存在するようになります。問題は、DBのパフォーマンスがディスクの物理的な速度によって制限を受けることです。

Given that the disk has to write the data in a disk before the writing isconfirmed, this will take some time. Even when considering a searching average time of 9 ms for disk writing, it is limited to approximately 67 commits per second, which is very slow. And while the disk is busy trying for the sector to be written, it cannot read.

書き込みが確認される前にディスクにデータを書き込む必要があるため、これには時間がかかります。ディスクの書き込みに平均9msかかるとしてと、おおよそ1秒当たり67コミットに制限されます。これは非常に遅いです。そして、ディスクのあるセクタに書き込み中は、そのセクタを読み込むことはできません。

InnoDB can avoid some of these limitations by associating some writing together, but, even with this, this restriction still exists. You may 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 this 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.

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

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

key_buffer_size = 4M

This is the default value in the configuration.

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

There are several buffers that are empty by default in some distributions. Modifying these parameters can improve performance significantly compared to the default one. It is important to make sure that these tokens exist in MySQL configuration file.

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

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

There is a parameter that may affect MySQL server performance with Pandora FMS. This parameter is innodb_thread_concurrency. This parameter is used to specify how many “concurrent threads” MySQL can execute.

Pandora FMS の MySQL サーバパフォーマンスを向上に有効なパラメータがあります。そのパラメータは、innodb_thread_concurrency です。このパラメータは、MySQL で “同時実行スレッド” をいくつにするのかを設定するのに利用します。

A wrong setting of this parameter may cause it to run slower than default, so it is especially important to pay attention to several aspects:

このパラメータがうまく設定されていない場合、デフォルトよりも遅くなることがあります。そのため、次のような情報に注意を払うことが特に重要です。

• MySQL version: In different MySQL versions this parameter behaves very differently.
• Number of actual (physical) processors: In this regard, you may access the official MySQL documentation.

• MySQL バージョン: 異なるバージョンの MySQL では、このパラメータはとても異なる動作をします。
• 物理プロセッサ数: この点については、公式のMySQLドキュメント を参照してください。

The value of innodb_thread_concurrency changed in several MySQL versions, currently the default value is 0. A value of 0 means “open as many threads as possible”. Therefore, if in doubt, it can be used:

innodb_thread_concurrency の値は MySQL のいくつかのバージョンで変更されています、現在デフォルト値は 0 です。 0 は「可能な限り多くのスレッドを開く」ことを意味します。 したがって、良くわからない場合は次のように設定できます。

innodb_thread_concurrency = 0

Like filesystems,databases also will fragment themselves, slowing the whole system down. In a high performance system such as Pandora FMS, it is key for the database state to not affect system performance. In overloaded systems, the database could block and force the monitoring system to fall down.

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

Setting up MySQL server could make Pandora FMS become faster, so if you have performance problems, the reason might be a problem in MySQL Setup or problems related with the database.

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

First check my.cnf file and its basic configuration for MySQL. 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

my.cnf setup should be similar to this one (4 GB RAM Server and using an average server hardware). Make sure that you have all these parameters correctly inside section [mysqld]:

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

[mysqld]
 datadir=/var/lib/mysql
 socket=/var/lib/mysql/mysql.sock
 user=mysql
 character-set-server=utf8mb4
 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=1M
 join_buffer_size=4M

 sql_mode=""

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

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

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

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

When making certain modifications to my.cnf (for example, adding the innodb_file_per_table parameter), it is likely that the database will not work when restarting the service. If you get the following error, you should restore the previous configuration (you should use root user credentials or root user) and back up the database:

my.cnf に特定の変更を加えると (たとえば、innodb_file_per_table パラメータを追加するなど)、サービスを再起動したときにデータベースが機能しなくなる可能性があります。次のエラーが発生した場合は、以前の設定を復元し (管理者権限または 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. Back up the database:

1. データベースをバックアップします。

mysqldump -uroot -p pandora > /home/pandora/pandora.sql

2. Stop MySQL server and move the data to a backup folder:

2. MySQL サーバを停止し、バックアップフォルダへデータを移動します。

systemctl stop mysql
mv /var/lib/mysql /var/lib/mysql.bak

3. Create a new folder for MySQL data (the relevant permissions will be assigned in step five):

3. MySQL データ用の新たなフォルダを作成します(関連する権限はステップ5で割り当てられます)。

mkdir /var/lib/mysql

4. Initialize MySQL server by specifying the target folder in the parameter --datadir. This process will generate a temporary password which must be noted down (it will be displayed by standard output or stored in /var/lib/mysqld.log):

4. パラメータ --datadir でターゲット フォルダを指定して、MySQL サーバーを初期化します。このプロセスにより、メモしておく必要がある一時パスワードが生成されます (標準出力に表示されるか、/var/lib/mysqld.log に保存されます)。

mysqld --initialize --datadir /var/lib/mysql

5. Assign the appropriate permissions to the new folder:

5. 新しいフォルダーに適切な権限を割り当てます。

chown -R mysql:mysql /var/lib/mysql
chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

6. Start MySQL service and log in with MySQL client, using the password from step four:

6. MySQL サービスを起動し、手順 4 のパスワードを使用して MySQL クライアントでログインします。

systemctl start mysql
mysql -uroot -p

7. Change the user password root to the one of your choosing (here we use Pandor4!):

7. ユーザ root のパスワードを任意のパスワードに変更します (ここでは Pandor4! を使用します)。

ALTER USER 'root'@'localhost' IDENTIFIED BY 'Pandor4!';

8. Exit MySQL client and check that you can log in again using the new password.

8. MySQL クライアントを終了し、新しいパスワードを使用して再度ログインできることを確認します。

9. Access MySQL client again and create the database:

9. MySQL クライアントに再度アクセスし、データベースを作成します。

CREATE DATABASE pandora;
USE pandora;

10. Load the backup from the database:

10. データベースへバックアップをロードします。

SOURCE /home/pandora/pandora.sql

11. Create the access users for Pandora FMS using the same credentials as in the previous installation (here Pandor4! is used) and then give them permissions over the database:

11. 以前のインストールと同じ資格情報を使用 (ここでは Pandor4! を使用) して、Pandora FMS のアクセスユーザを作成し、データベースに対する権限を付与します。

CREATE USER 'pandora'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Pandor4!';
CREATE USER 'pandora'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'Pandor4!';
GRANT ALL PRIVILEGES ON pandora.* TO 'pandora'@'localhost';
GRANT ALL PRIVILEGES ON pandora.* TO 'pandora'@'127.0.0.1';

12. After having configured my.cnf file and restarted MySQL service, you should check that these changes have been correctly applied. To that end, check the variables one by one:

12. my.cnf ファイルを設定して MySQL サービスを再起動した後、これらの変更が正しく適用されていることを確認する必要があります。そのためには、変数を 1 つずつ確認します。

SHOW VARIABLES LIKE 'innodb_log_file_size';

SHOW VARIABLES LIKE 'innodb_io_capacity';

SHOW VARIABLES LIKE 'innodb_file_per_table';

Or with a general inquiry such as:

または、次のような一般的な問い合わせでも構いません。

SHOW VARIABLES LIKE "innodb%";

Once you check that Pandora FMS (both Web Console and server) can connect correctly to the database and everything works properly, you may delete mysql.bak directory:

Pandora FMS (Web コンソールとサーバの両方) がデータベースに正しく接続でき、すべてが正常に動作することを確認したら、mysql.bak ディレクトリを削除できます。

rm -rf /var/lib/mysql.bak

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

There should be more than 100 files there (depending on the version of Pandora FMS), each .ibd is the data file of each table, when innodb_file_per_table parameter is enabled in file my.cnf. If you do not have any of these files, .ibd means it uses a single file to store all information. The previous one means table fragmentation is also present on all tables and performance will worsen each week.

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

If you have your database running in a single database, first you will need to recreate the database after correctly configuring file my.cnf and restarting MySQL.

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

Another less “drastic” solution to solve the fragmentation issue is the use of MySQL OPTIMIZE tool to optimize certain Pandora FMS tables. To benefit from it, run right away from MySQL the following:

断片化の問題を解決するためのもう 1 つの「それほど劇的ではない」解決策は、MySQL OPTIMIZE ツールを使用して Pandora FMS の特定のテーブルを最適化することです。これを利用するには、MySQL から直接以下を実行します。

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

This prevents performance from degrading over time as the system works.

これにより、システムが稼働しているときに時間の経過とともにパフォーマンスが低下するのを防ぎます。

In large environments, the OPTIMIZE option could be “blocked”. In this case, the best option is to rebuild the DB.

非常に大規模な環境では、OPTIMIZE オプションが「ブロック」される可能性があります。この場合、最善のオプションは DB を再構築 することです。

After doing these operations, run:

これらの操作を行った後、次を実行します。

FLUSH TABLES;

From MySQL manual:

MySQL マニュアルより:

“For InnoDB tables, OPTIMIZE TABLE is mapped to ALTER TABLE, which rebuilds the table to update index statistics and free unused space in the clustered index”.

「InnoDB テーブルの場合、OPTIMIZE TABLE は ALTER TABLE にマップされ、テーブルを再構築してインデックス統計を更新し、クラスター化インデックス内の未使用領域を解放します 」。

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

MySQL には、パフォーマンスを向上させたり低下させたりできる非常に「特別な」トークンがいくつかあります。

• 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 fall and stop. If it lasts more than 90 lock, there is a real problem.

これはボトルネックがある場合に役立ち、MySQL が停止することはありません。90 ロックを超えて続く場合は、実際に問題が発生しています 。

Using MySQL CLI, run this query:

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 TABLE_TYPE = 'BASE TABLE' AND DATA_FREE> 0 ORDER BY frag_ratio DESC;

You should get only the tables with some fragmentation index, for example:

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

+--------+-------------------------+-------------+--------------+-----------+------------+
| 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 |
+--------+-------------------------+-------------+--------------+-----------+------------+

This query works only on tables with more than 10 % of fragmentation. Too big tables (like tagente_datos) can take a lot of time to get optimized if they are very fragmented. This may affect the production system.

このクエリは、断片化が 10 % を超えるテーブルでのみ機能します。大きすぎるテーブル (tagente_datos など) は、断片化が激しい場合、最適化に長い時間がかかることがあります。これは、実稼働システムに影響を与える可能性があります。

To optimize the tagent_module_inventory table (in this case the database is called pandora):

tagent_module_inventory テーブルを最適化する (この場合、データベースの名前は pandora) には次のようにします。

OPTIMIZE TABLE pandora.tagent_module_inventory;

A warning message will appear:

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

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

If you check again, you should see fragmentation is gone:

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

+--------+-------------------------+-------------+--------------+-----------+------------+
| 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 |
+--------+-------------------------+-------------+--------------+-----------+------------+

This is more general, but you need to make sure the system IO is not a bottleneck (disk). Run the following command to collect the system information:

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

vmstat 1 10

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

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

Having high CPU-US 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 のバッファの調整など)必要があります。

Sample output of a “normal” system:

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

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

MySQL supports table partitioning, which allows very large tables to be distributed into smaller chunks, such as logical subdivisions (see the MySQL manual for details).

MySQL はテーブルパーティショニングをサポートしており、これにより、非常に大きなテーブルを論理的なサブディビジョンなどの小さなチャンクに分散できます (詳細については、MySQL マニュアル を参照してください)。

If you have large amounts of data in Pandora FMS database (main and history) and it is estimated that many Console operations that refer to that data (for example drawing graph) are slow, then it will improve its performance using table partitioning.

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

Pandora FMS automatically performs a monthly partitioning in the history database if it is configured from the Web Console, section History database, of the general configuration. For more details check this link.

Pandora FMS は、Web コンソールの一般設定のセクション ヒストリデータベース から設定されている場合、ヒストリデータベースの月次パーティショニングを自動的に実行します。詳細については、こちらを参照してください。

After having installed Pandora FMS and enabled its history database, this will be the one that holds the largest amount of data and it is the recommended one to perform a table partitioning Precisely the tables indicated for that are tagente_datos, tagente_datos_string, tagente_datos_inc and tevento. The manual practical process for the table tagente_datos is described below (see also “Automatic partitioning”).

Pandora FMS をインストールし、ヒストリデータベースを有効にすると、これが最大量のデータを保持するものになります。テーブルパーティション分割の実行が推奨されます。 これに指定されているテーブルは、正確には tagente_datos 、tagente_datos_string 、tagente_datos_inc 、および tevento です。テーブル tagente_datos の手動による実際の処理については、以下で説明します (「自動パーティション分割」も参照してください)。

You should check at first that the directory /var/lib/mysql/pandora_history/*.ibd has many files (one per table). If this is not the case, you will need to do a dump of the database, change the configuration of the my.cnf file, restart MySQL, delete the current database and recreate it from the dump.

まず、ディレクトリ /var/lib/mysql/pandora_history/*.ibd に多くのファイル (テーブルごとに 1 つ) があることを確認する必要があります。そうでない場合は、データベースの dump を実行し、my.cnf ファイルの設定を変更し、MySQL を再起動し、現在のデータベースを削除して dump から再作成する必要があります。

Once you ensure that innodb_file_per_table is enabled, separate the two main databases into different partitions.

innodb_file_per_table が有効になっていることを確認したら、2 つのメインデータベースを異なるパーティションに分離します。

• This operation will need enough disk space to be completed. You will need to check how big the tagente_datos.ibd file is. If for example it occupies 10 gigabytes, you will need 15 GB of free space to start the operation.
• This operation may take a long time, depending on the size of the table. For example, it would take an hour and a half to split a table with approximately 7500 modules data for 100 days (more than 50,000,000 rows).

• この操作を完了するには、十分なディスク領域が必要です。tagente_datos.ibd ファイルのサイズを確認する必要があります。たとえば、このファイルが 10 GB を占める場合、操作を開始するには 15 GB の空き領域が必要になります。
• この操作は、テーブルのサイズに応じて長い時間がかかることがあります。たとえば、100 日間 (50,000,000 行以上) の約 7500 個の モジュールデータ を含むテーブルを分割するには、1 時間半 かかります。

This is an example for partitioning all of 2023 so far and for future months. To start the process, you will need to execute the following query in MySQL CLI:

これは、2023 年のこれまでと今後の月全体をパーティション分割する例です。処理を開始するには、MySQL CLI で次のクエリを実行する必要があります。

ALTER TABLE tagente_datos PARTITION BY RANGE (utimestamp) (
PARTITION Jan23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-02-01 00:00:00')),
PARTITION Feb23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-03-01 00:00:00')),
PARTITION Mar23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-04-01 00:00:00')),
PARTITION Apr23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-05-01 00:00:00')),
PARTITION May23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-06-01 00:00:00')),
PARTITION Jun23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-07-01 00:00:00')),
PARTITION Jul23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-08-01 00:00:00')),
PARTITION Aug23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-09-01 00:00:00')),
PARTITION Sep23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-10-01 00:00:00')),
PARTITION Oct23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-11-01 00:00:00')),
PARTITION Nov23 VALUES LESS THAN (UNIX_TIMESTAMP('2023-12-01 00:00:00')),
PARTITION Dec23 VALUES LESS THAN (UNIX_TIMESTAMP('2024-01-01 00:00:00')),
PARTITION pActual VALUES LESS THAN (MAXVALUE)
);

Then the following query would have to be run every month to reorganize the partitioning:

次に、パーティションを再編成するために、次のクエリを毎月実行する必要があります。

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

Changing “Jan24” to the month you are in.

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

Remember again that this operation could take hours, depending on how big the tagente_datos table is. You may check the process by watching the size of the partitioning files by running:

この操作は、tagente_datos テーブルの大きさに応じて、数時間かかる場合があることに再度注意してください。次のコマンドを実行して、パーティションファイルのサイズを監視することで、処理を確認できます。

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

 -rw-rw----  1 mysql mysql 424M feb 24 05:58 #sql-76b4_3f7c#P#Jan23.ibd
 -rw-rw----  1 mysql mysql 420M feb 24 05:51 #sql-76b4_3f7c#P#Feb23.ibd
 -rw-rw----  1 mysql mysql 128K feb 24 05:40 #sql-76b4_3f7c#P#Mar23.ibd
 -rw-rw----  1 mysql mysql 840M feb 24 05:44 #sql-76b4_3f7c#P#Apr23.ibd
 -rw-rw----  1 mysql mysql 440M feb 24 05:47 #sql-76b4_3f7c#P#May23.ibd
 -rw-rw----  1 mysql mysql  10M feb 24 05:42 #sql-76b4_3f7c#P#Jun23.ibd
 -rw-rw----  1 mysql mysql 404M feb 24 05:56 #sql-76b4_3f7c#P#Jul23.ibd
 -rw-rw----  1 mysql mysql 436M feb 24 05:54 #sql-76b4_3f7c#P#Aug23.ibd
 -rw-rw----  1 mysql mysql 400M feb 24 05:49 #sql-76b4_3f7c#P#Sep23.ibd
 -rw-rw----  1 mysql mysql 408M feb 24 05:52 #sql-76b4_3f7c#P#Oct23.ibd
 -rw-rw----  1 mysql mysql  72M feb 24 06:03 #sql-76b4_3f7c#P#Nov23.ibd
 -rw-rw----  1 mysql mysql 404M feb 24 06:03 #sql-76b4_3f7c#P#Dec23.ibd
 -rw-rw----  1 mysql mysql 416M feb 24 06:00 #sql-76b4_3f7c#P#jan23.ibd

MySQL database management system, same as other SQL engines, such as Oracle®, is degraded with time due to causes such as data fragmentation produced by deleting and continuous insertion in large tables. In large environments, with a lot traffic volume, there is a very easy way to improve performance and prevent performance from degrading. This is rebuilding the DB from time to time.

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

To that end, schedule a service stop, which could last approximately 1 hour.

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

Once they have been stopped, dump the DB (Export); in this example, the database is called pandora3 and the user must be root:

停止したら、DB ダンプ (エクスポート) を実行します。この例では、データベースの名前は pandora3 で、ユーザは root です。

mysqldump -u root -p pandora3> /tmp/pandora3.sql

Delete the DB:

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

mysql -u root -p

DROP DATABASE pandora3;
 Query OK, 87 ROWS affected (1 MIN 34.37 sec)

Create the DB and import the previous data export from the dump you did at first:

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

CREATE DATABASE pandora3;
USE pandora3;
SOURCE /tmp/pandora3.sql

This may take a few seconds or several minutes, depending on the size of the database and the resources available on the machine.

データベースのサイズとマシンで使用可能なリソースに応じて、数秒から数分かかる場合があります。

This section affects only InnoDB databases. Pandora FMS is built on Innodb databases.

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

Unfortunately, MySQL is degraded with time, and this affects the global performance of the system.There is no other solution that does not involve rebuilding all the database schemes from scratch, rebuilding the data binary file that MySQL uses to store all the information and the files used to rebuild the transactions.

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

If you take a look at the /var/lib/mysql directory, you may see that there are three files, that have always the same name, and that are, depending on the severity of the case, huge. In this example:

/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

The ibdata1 file is the one that stores all the system Innobd data. In a very fragmented system that has not been “rebuilt” or “installed” for a long time, this system will be big but little efficient. The innodb_file_per_table parameter, that was mentioned before, regulates part of this performance.

ibdata1 ファイルは、すべてのシステム Innobd データを保存するファイルです。長い間「再構築」または「インストール」されていない非常に断片化されたシステムでは、これは大きくなり効率は下がります。前に説明した innodb_file_per_table パラメータは、このパフォーマンスの一部を制御します。

Similarly, each database has in the /var/lib/mysql directory, one directory to define its structure. Delete them too.

同様に、各データベースは /var/lib/mysql ディレクトリ 内に、その構造を定義する 1 つのディレクトリがあります。これらも削除します。

The process is quite easy:

手順はとても簡単です。

1. Dump (via mysqldump) all the schemes to the disk:

1. すべてのスキーマをディスクにダンプします (mysqldump 経由)。

mysqldump -u root -p -A> alldata.sql

• Stop MySQL.
• Delete ibdata1, ib_logfile0, ib_logfile1 and the InnoDB database directories
• Start MySQL.
• Create pandora database again (create database pandora;)
• Import the backup file (alldata.sql)

• MySQL を停止します。
• ibdata1 、ib_logfile0 、ib_logfile1 、およびInnoDBデータベースディレクトリを削除します。
• MySQL を再起動します。
• pandora データベースを再度作成します (create database pandora;)
• バックアップファイル（alldata.sql ）をインポートします

mysql -u root -p

CREATE DATABASE pandora;
USE pandora;
SOURCE alldata.sql;

The system should work faster now.

システムの動作が高速化されるはずです。

There are some situations when you can optimize MySQL performance, but giving up other system resources.

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

This index optimizes speed on graph rendering (a lot), but it uses more disk storage space, and could entail a slightly decrease on INSERT/DELETE operation, due to the Index overhead:

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

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

In some systems, depending on the type of information you have, you may find some “slow queries” that make the system work worse. You may enable logs of this type of queries over a short period of time (since it harms the system performance) in order to consider trying to optimize queries to tables with indexes. To enable these settings, do the following:

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

• 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 サービスを再起動することを忘れないでください。

• http://dev.mysql.com/tech-resources/presentations/presentation-oscon2000-20000719/index.html
• http://jeremy.zawodny.com/mysql/mysql-optimization.html

This section describes different methods to configure Pandora FMS in a high capacity environment. It also describes different tools to make load tests, which are useful to adjust the environment to the highest possible process capacity.

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

Pandora FMS has been configured to support a load of around 2500 agents in systems where database, console and server are in the same machine. The maximum recommended number is around 2500 agents (about 60,000 modules) per system, but this number varies greatly depending on whether they are XML agents, remote modules, with high or low intervals, or with systems with high capacity or low memory.

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

All factors greatly alter the number of agents that a system can manage efficiently. In laboratory tests, 10,000 agents have been executed in a single server with basic hardware, but strongly optimized.

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

Assuming a RHEL 8 machine with 16 GB of RAM and 8 CPU to be optimized for the maximum processing capacity of the Dataserver (XML).

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

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
character-set-server=utf8mb4
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 = 6400M
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 = 300
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=1M
join_buffer_size=4M
sql_mode=""

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

verbose 3
server_threshold 5
xxxxserver_threads 8
max_queue_files 5000

Aspects to take into account:

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

• The number established in the verbose parameter refers to the amount of information that is written in the logs, being advisable not to exceed 3. The higher the number, the lower the performance of Pandora FMS due to the large amount of information to write in the logs.

• verbose パラメータで設定された数値は、ログに書き込まれる情報の量を指し、3 を超えないようにすることをお勧めします。数値が高くなると、ログに書き込まれる情報量が多くなるため、Pandora FMS のパフォーマンスが低下します 。
• A high value (15) of the server_threshold parameter causes the DB to suffer less, while the increase in the maximum number of files processed causes the server to seek files and fill the buffers every time. These two elements of the configuration are closely linked. In the case of optimizing the network server, it may be interesting to lower the server_threshold to 5 or 10.

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

• The very high number of threads (more than 5) set in xxxxserver_threads ' only benefits processes with long I/O waits, such as the network server or plugin server. In the case of the Dataserver, which is in process all the time, setting too many threads can even hurt performance. On systems with a slow DB: try different combinations between 1 and 10; with faster disks and multi-core CPUs, it could be increased. In the case of optimizing the system for the Networkserver, the number can be much higher, between 10 and 30.

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

Pandora FMS has several tools that may help you to measure properly its hardware and software for the amount of data it expects to obtain. One of them is useful to “attack” directly the database with fictitious data (dbstress) and the other generates fictitious XML files (xml_stress).

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

This is an small script that generates XML data files like the ones sent by Pandora FMS agents. By default 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 データファイルを生成します。ここで、モジュールはテンプレートとして定義されています。

Modules are filled with random data. An initial value and the probability of the module data changing may be specified.

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

Run the script like this:

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

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

Sample < configuration file > called pandora_xml_stress.conf:

pandora_xml_stress.conf という < 設定ファイル > に指定するファイルの例を示します。

# Maximum number of threads, by default 10.
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, by default /tmp.
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, by default 1.0.
xml_version 1.0

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

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

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

# Agent interval, by default 300.
agent_interval 300

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

# Data file generation end date, by default now.
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, by default 2.
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, by default 41121.
# 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_5
module_type generic_proc
module_descripcion Module 3 description.
# Initial data.
module_data 1
module_end

Send and Receive Agent Local Configuration

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

If you activate in your pandora_xml_stress.conf the get_and_send_agent_conf configuration value to 1, you may make the test load agents work as normal agents, so that they send their configuration file and also the MD5 hash. From PFMS Web Console you may modify the remote configuration for subsequent runs of pandora_xml_stress.

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

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_confs にて、テストエージェントの設定ファイル .conf をどこに保存するかを設定できます。

Configuration File

設定ファイル

• max_threads: Number of threads where the script will be executed. This improves the E/S.
• agent_file: Path of the name list file path, separated by a new line.
• temporal: Path of the directory where made-up XML data files are generated.
• log_file: Path of the log where it will report about its execution script.
• xml_version: Version of the XML data file (by default 1.0).
• encoding: XML data file encoding (by default ISO-8859-1).
• os_name: Name of the made-up agent Operative System (Linux by default).
• os_version: Version of the made-up agents Operative System (2.6 by default)
• agent_interval: Interval of the made-up agents in seconds (300 by default).
• time_from: Time from which made-up XML data files are generated, in format yyyy-MM-dd HH:mm:ss.
• time_to: Time until which made-up XML data files are generated, in format yyyy-MM-dd HH:mm:ss.
• get_and_send_agent_conf: Boolean value 0 or 1. When it is active, the made-up agents will try to download by remote configuration a more updated version of the standard configuration file of an agent. And they can be edited through Pandora FMS Web console.
• startup_delay: Time numeric value in seconds before each agent starts to generate files. It is used to avoid race conditions.
• timezone_offset: Numeric value of the time zone offset.
• timezone_offset_range: Numeric value that is useful to generate the timezone in this range randomly.
• latitude_base: Numeric value. It is the latitude geographic area to be used to define fictitious agents.
• longitude_base: Numeric value. It is the longitude geographic area to be used to define fictitious agents.
• altitude_base: Numeric value. It is the altitude geographic area to be used to define fictitious agents.
• position_radius: Numeric value. It defines the radius of the circumference in which the geographic position of the fictitious agent will be set (randomly and based on parameters latitude_base and longitude_base).
• 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 数値です。指定した半径内の円に仮想エージェントがランダムに表示されます。

The definition of one module in the script configuration file. If remote configuration was enabled, it will also be the same. It is:

スクリプト設定ファイル内の 1 つのモジュールの定義。リモート設定が有効になっている場合も同様です。次のようになります。

module_begin
module_name <module_name>
module_type <module_type_data>
module_description <description>
module_exec type =<xml_stress_type_generation>;<another_option>;<another_option> …
module_unit <units>
module_min_critical <value>
module_max_critical <value>
module_min_warning <value>
module_max_warning <value>
module_end

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

Each one can be configured as:

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

• type_generation_xml_stress: It can have values RANDOM, SCATTER, CURVE.
• module_attenuation <value>: The generated module value is multiplied by the specified value, usually between 0.1 and 0.9.
• module_attenuation_wdays <value> <value> … <value>: The module value is only attenuated during the given days, ranging from Sunday (0) to Saturday (6). For example, the following module simulates a 50 % drop in network traffic on Saturdays and Sundays:
• 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 < value >: If set to 1, the module's previous value is always added to a new value, resulting in an increasing function.
• Others: See below which options are available, depending on the execution type.
• module_incremental <値>: 1に設定すると、モジュールの以前の値を常に新たな値に加えます。値が増え続ける機能です。
• その他: 実効タイプに依存して、どのようなオプションがあるかは以下を確認してください。

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

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

Numeric

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

Booleans

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

String

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

外部データソース (SOURCE)

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

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

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

4
5
6
10

二種類のデータ(数値と文字列)を扱うことができます。これらのモジュールは、ファイルのデータ順番に読み込んで、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

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

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

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

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

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

Note: 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秒間の処理率を求めています。これは初歩的なソリューションですが、サーバの設定を修正するための情報を提供します。

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

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

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

• random_1
• curve_other

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

Pandora FMS DB Stress Fine Adjustment

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

This tool is preconfigured in order to search, in all agents, the module names “random”, “curve” or “boolean”, that use an interval between 300 seconds and 30 days.

このツールは、すべてのエージェントから、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;

1. 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.
2. The second line of variable must match target_agent, for a specific agent.
3. The third line must match target_interval, defined in seconds and which represents the module predefined periodical interval.
4. The fourth line is target_days and represents the number of days in the past since the date, in the current timestamp.

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

Sometimes, there are problems for which direct help from Pandora FMS support is needed. To fmake the communication with the Support team easier, Pandora FMS servers have some tools for this.

場合によっては、Pandora FMS サポートからの直接的な支援が必要な問題が発生することがあります。サポートチームとのコミュニケーションを容易にするために、Pandora FMS サーバーにはそのためのツールがいくつかあります。

This tool is located in the Management → Admin tools → Diagnostic Info section, and is conceived to provide the most important information about Pandora FMS configuration and its database.

このツールは 管理(Management) → 管理ツール(Admin tools) → 診断情報(Diagnostic Info) セクションにあり、Pandora FMS の設定とデータベースに関する最も重要な情報を提供するように設計されています。

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

/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