個人用ツール

Pandora:Documentation ja:Optimization

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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

目次

Pandora FMS の最適化と問題解決

概要

Pandora FMS server can monitor about 2000 devices. But to do it, the database configuration must be adjusted and tailored.

Pandora FMS サーバは、約 2000のデバイスのモニタリングが可能です。そのためには、データベースの設定を調整する必要があります。

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

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

Pandora FMS の最適化

商用レベルのシステムのための MySQL チューニング

一般的に推奨する設定

The first thing you should do if you really want to have a HUGE system with tables bigger than 2GiB is take into account some advice. MySQL recommends using 64Bit system. However, there is also another useful suggestion: the more RAM memory and CPU are used, the better the performance will be.

まず最初に、2GiBを超えるテーブルを持つ巨大なシステムを必要とするのであれば、いくつかのガイドラインに従うべきです。MySQLは64Bit版の利用を推奨します。さらに、一般的な推奨項目として、よりよいパフォーマンスを得るために十分なメモリとCPUを用意すべきです。

According to experience, RAM memory is more important than CPU. If you are thinking about using 1GiB or a lower memory quantity for your SQL system, please reconsider. The minimum for an enterprise system should be 2GiB; a good option for a big system would be 8GiB. Remember that a bigger RAM memory could speed up key updates by keeping the most used pages in the RAM.

われわれの経験によれば、CPUよりもメモリのほうが重要です。もし、DBサーバ用に割り当てるメモリ量を1GiB以下にしようと考えているのであれば、考え直してください。エンタープライズレベルであれば最低2GiB必要です。巨大なシステムであれば、8GiB割り当てるというのもよいでしょう。メモリが十分あれば、利用されるインデックスの大半をメモリ上に置くことでインデックスの更新が高速化されるということを忘れてはいけません。

It is a good idea to be able to remove the system in case of failure. For systems where the database is in an specific server, take a look at Ethernet Gigabit. The latency is as important as the performance.

障害が発生した場合にシステムを切り離すようにできるようにするのが良いでしょう。特定のサーバにデータベースがあるシステムの場合は、ギガビットイーサを利用すべきです。待ち時間はパフォーマンスにとって重要です。

Disk optimization is very important for databases that are very big: you should divide the databases and tables in different disks. In MySQL it is possible to use symbolic links for this. Use different discs for the system and the database and, most important: try to use a low capture hard disk, since the application would be compromised by the disk capture speed, that increases in N log N when it gets more data.

ディスクの最適化は、とても大きなデータベースにとっては大変重要です。データベースおよび手ープルを異なるディスクに分割すべきです。MySQL では、シンボリックリンクを使うことができます。システムおよび、データベースで異なるディスクを使い、一つのハードディスクのアクセスを減らすようにすることが重要です。アプリケーションは、ディスクアクセスに左右され、データが増えていくと N log N で増加していきます。

Info.png

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


Info.png

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


Use --skip-locking (activated by default in some systems) if it is possible. This will put out the external blockade and will enable a better performance.

可能であれば、--skip-locking (いくつかのシステムでは事前設定で有効化します) を使ってください。これにより外部ロックを行わず、パフォーマンスが向上します。

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 replicationif it only launches one MySQL host server.

もし、MySQLサーバとクライアントを同じマシン上で起動するなら、TCP/IPのかわりにsocketを使用してMySQLサーバへ接続しましょう(これにより7.5%性能が改善されます)。MySQLサーバに接続する際、ホスト名を指定しないかlocalhostと指定することでsocket経由で接続することができます。MySQLサーバを1台しか起動しないのであれば、binary logの出力とレプリケーションを無効にしましょう。

As a general advice for a better performance, check this two items:

一般的なパフォーマンス向上のためのアドバイスとしては、以下を確認してください。

  • Don't use binary replication logs if you will not use replication.
  • レプリケーションを利用しない場合は、バイナリログを出力しない。
  • Don't use slowquery or debug logs.
  • slowquery または debug ログを出力しない。
MySQL のバージョンについて

It is highly recommended the use of Percona modified MySQL versions which offers better performance. By default, the plugins create are for Percona.

よりパフォーマンスの高い、修正版の MySQL である Percona 使うことを強くお勧めします。デフォルトでは、プラグインは Percona 用に作成しています。

MySQL performance is also better in last versions (5.5) and you can get an improvement on performance about 20% respect 5.0 version.

MySQL のパフォーマンスはまた、最新バージョン(5.5)で向上しています。バージョン 5.0 よりも約 20%ほどパフォーマンスが上がります。

MySQL の設定をチェックするためのツール

There are many tools to optimize the setup of your MySQL server.

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

MySQL Tuning Primer, from Mattew Montgomery, is a command line tool used to check your MySQL performance, and gives you a few tips and suggestions to improve it. Check it at https://bugs.launchpad.net/mysql-tuning-primer

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

バイナリログ出力の停止

It ss enabled by default on most 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 the MySQL Server,although by default these lines are not configured with the Pandora FMS ISO installation.

両方の行をコメントアウトし、MySQL サーバを再起動します。Pandora FMS を ISO からインストールした場合、デフォルトではこれらの行は設定されていません。

Template warning.png

These recommendations are for the case of not having configured a Pandora FMS HA system, which needs binary replication for its operation


Template warning.png

これらのお勧めは、Pandora FMS を HA 構成にしていない場合です。HA 構成の場合はバイナリレプリケーションが必要です。


ディスク I/O パフォーマンス

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

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

innodb_log_file_size = 64M

By default this value is set, which can be higher (even 512M) without prejudice, except for recovery in case of problem and higher disk occupation. The default value of MySQL is 5M, which is very low for production environments with high transaction volume. To alter this value with an already running system we must first make a complete DUMP and delete the Innodb binary index files (usually in /var/lib/mysql/ib*). Change my.cnf restart MySQL and load the SQL dump. Since the process is the same as for activating the innodb_file_per_table token (described below, we recommend doing the whole process simultaneously): change the whole my.cnf, restart and restore the DDBB only once. To know more about the backup and recovery process go to the following link.

デフォルトではこの値が設定されていますが、問題が発生した場合の回復とディスク占有率が増えることを除いては、事前検証なしに高くすることができます(512Mでも)。 MySQ Lのデフォルト値は 5M です。これは、トランザクション量が多い本番環境では非常に低い値です。 稼働中のシステムで値を変更するには、フルバックアップ(SQL ダンプ)を行い、データベースを停止し、Innodb バイナリインデックスファイル(通常は /var/lib/mysql/ib* です)を削除します。my.cnf を編集し、サーバを再起動し、ダンプを読み込みます。サーバは、新たなトランザクションログファイルを新たなサイズで再生成し、通常通り動きだします。この処理は innodb_file_per_table トークンを有効化するのと同じであるため(以下で説明します。処理全体を同時に行うことをお勧めします)、my.cnf 全体を変更し、DB を 1回だけ再起動して復元します。 バックアップとリカバリの処理について詳細を知りたい場合は、こちら を参照してください。

innodb_io_capacity = 100

By default this parameter has the value 100, but we must know previously 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 です。

トランザクションごとのディスク書き込みの回避

By default, MySQL fix autocommit=1 for each connection. This is not so bad for MyISAM, so what one person writes is not guaranteed in the disk, but for InnoDB it means that any insert / update / delete in an InnoDB table will be result in a register on the disk.

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

So, why would it be bad that it writes on the disk? Nothing at all. It assures that when there's any commitment, it will be for sure that the data will be there when the database will be restarted after an accident. The problem is that the DDBB performance is limited by the physical velocity of the disk. Given that the disk has to write the data in a disk before the writing has been confirmed, this will take some time.

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

Even when we consider a searching average time of 9ms for the disk writing, we are being limited to approximately 67 commits/ sec1, this is very slow. And while the disk is busy trying that the sector would be written, it's not reading. InnoDB can avoid some of this limitation through the association of some writing together, but, even with this, the restriction exists.

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

We can avoid that it writes at the end of each transaction, doing that it uses an "automatic" system of writing, that writes approximately every second. In case of failure, we could lose the data from the last second, something more bearable considering that we are trying to gain efficiency. For doing this, we need to use the following configuration token:

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

innodb_flush_log_at_trx_commit = 0

By default it has this value in the configuration.

デフォルトでは、上記の設定になっています。

KeyBuffer の大きさ

Depending on the system total RAM, it's a very important global parameter, thats speeds up DELETES and INSERT.

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

key_buffer = 4M

This is the default value in the configuration.

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

他の重要なバッファ

There are several buffers that come empty by default in some distributions. Modifying these parameters can give a much higher performance than the default. It is important to make sure that these tokens exist in the MySQL configuration file.

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

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

InnoDB の同時実行スレッド

There is a parameter that can affect Pandora MySQL server performance pretty much. This parameter is innodb_thread_concurrency. This parameter is used to specify how many "concurrent threads" can run MySQL. Misconfiguration of this parameter can make it go slower than the default, so it is especially important to pay attention to several parameters:

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

  • MySQL version. In different versions of MySQL this parameter behaves VERY differently.
  • MySQL バージョン。異なるバージョンの MySQL では、このパラメータはとても異なる動作をします。
  • Real number of physical processors.
  • 物理プロセッサ数。

Here you can read the official MySQL documentation [1].

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

The recommended value is the number of CPUs (Physical) multiplied by 2 plus the number of disks where is located InnoDB. In later versions of MySQL (> 5.0.21) the default is 8. A value of 0 would mean that "opens up so many threads as possible."

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

Different people [3] [4] have done tests and have found problems with performance on servers with multiple physical CPUs when using a very high number, with relatively old versions of MySQL (we're talking 2008).

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

それぞれのテーブルでのテーブルスペースの利用

( From the MySQL manual at http://dev.mysql.com/doc/refman/5.0/es/multiple-tablespaces.html)

( MySQLのマニュアル http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html より )

In MySQL 5.0, it's 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テーブルとそのインデックスごとにデータファイルを生成し保存することができます。各テーブルがそれぞれテーブルスペースを持つことから、この特徴は「multiple tablespace」と呼ばれています。

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

multiple tablespaceを使用することで、特定のテーブルを別の物理ディスクに移動したり、他のInnoDBテーブルの利用を妨げることなくあるテーブルをバックアップから復元したりするのに役に立ちます。

It's possible to activate multiple table espaces adding this line to the my.cnf Mysqld section

my.cnfのmysqldセクションに以下の行を追加することで、multiple tablespaceを有効にすることができます。

[mysqld]
innodb_file_per_table

After restarting the server, InnoDB will store each new created table in its own file name_tabla.ibd in the database directory to which the table belongs to. This is similar to the MyISAM store motor does, but MyISAM divides the table in a tbl_name.MYD data file and the tbl_name.MYI. index file. For InnoDB data and index are kept together in the .ibd file. The tbl_name.frm file should be created as usual.

サーバ再起動後、InnoDBは新規に作成されたテーブルをそのテーブルが属するデータベースディレクトリ内にあるname_table.ibdという名前のファイルに保存します。これはMyISAMストレージエンジンの動きと似ていますが、MyISAMはテーブルをデータファイルtbl_name.MYDとインデックスファイルtbl_name.MYIに分割して保存します。InnoDBのデータとインデックスは.ibdファイル内に一緒に保存されます。tbl_name.frmファイルは通常通り作成されます。

If we take off the innodb_file_per_table line form my.cnf and we restart the server, then InnoDB will create again the tables in the shared table space files

my.cnf中のinnodb_file_per_tableの行をコメントアウトし、サーバを再起動すると、InnoDBは再び共有テーブルスペースファイルにテーブルを作成します。

innodb_file_per_table affect only to the 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ファイルを使用する状態で作成されますが、共有テーブルスペース内にあるテーブルにアクセスすることも可能です。このオプションを無効にすると、新規テーブルは共有テーブルスペース内に作成されますが、multiple tablespaceを使用しているテーブルにアクセスすることも可能です。

MySQL フラグメンテーション

Like the filesystems, databases also will fragment theirselves, doing the whole system slower. In a high performance system like Pandora, you need a fast al reliable database. In overloaded systems, database could block and force the monitoring system to stop.

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

Setting up the MySQL server is very important to have a good performance in any Pandora FMS setup. It doesn't matter if you have a powerful hardware or a small setup. A good configuration of MySQL could make a Pandora FMS faster, so if you have performance problems, probably will be because a problem in MySQL Setup or problems related with database.

Pandora FMS で良いパフォーマンスを得るには、MySQL の設定がとても重要です。強力なハードウエアや小規模な環境では関係はありません。MySQL で良い設定ができると、Pandora FMS を高速にすることができます。パフォーマンスの問題がある場合は、MySQL の設定やデータベースに関する問題である可能性があります。

my.ini/cnf 設定の確認

Let's start with my.ini, the "basic configuration" for the MySQL Server. This file in your setup should be similar to this (this is for a 4GB RAM Server using old (2013) average server hardware). Check you have this tokens inside your [mysqld] section:

MySQL サーバの "基本設定" である my.ini から確認します。このファイルは以下のような設定ファイルになっています(この例は、メモリ 4GB の 2013 年の平均的なサーバハードウエアです)。

 [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

If you change anything in the .cnf file you need to restart the MySQL. Take a look at the end of the /var/log/mysqld.log for any error.

.cnf ファイルを変更した場合は、MySQL を再起動する必要があります。エラーの確認には /var/log/mysqld.log の最後を見てください。

データベースのリストア

One common "issue" when altering the .cnf is to set up new values for the transaction logs. If you see this error in the logs:

.cnf ファイルを変更する場合の共通の問題としては、トランザクションログの値があります。 ログに次のようなエラーが出た場合は、

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

Restore the previous configuration, build a backup of your database and follow the steps below:

以前の設定をリストアするには、データベースのバックアップを生成し次の手順を実行します。

1. Once the backup is created, stop the MySQL service

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

systemctl stop mysql

2. Go to the previous folder where the MySQL data files are located (datadir) (default /var/lib/mysql)

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

cd /var/lib/

3. Move the folder to another location (/var/lib/mysql -> /var/lib/mysql_backup)

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

mv mysql mysql_old

4. Create a new folder (/var/lib/mysql)

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

mkdir mysql

5. Assign the owner of the folder

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

chown -R mysql. mysql.

6. Initialize the folder with MySQL data

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

mysql_install_db --datadir=/var/lib/mysql

7. Start the service

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

systemctl start mysql

8. Launch the configurator and follow the wizard

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

mysql_secure_installation

9. Rebuild your databases

9. データベースを再構築します。

mysql> create database pandora;

10. Assign permissions to the right users

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. Load the backups

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

mysql> source /path/to/your/backup.sql

Template warning.png

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


Template warning.png

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


You MUST check after restarting the mysql that the configuration has been applied and it's running. To do that, use SHOW VARIABLES command:

mysql を再起動したのち、設定が反映されて動作しているかを確認する必要があります。それには、SHOW VARIABLES コマンドを用います。

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                     |
+-----------------------------------------+------------------------+
各テーブルごとに分割されたデータファイルがアクティブであるか確認
ls -lah /var/lib/mysql/pandora/*.ibd | wc -l

You should have there more than 100 files (depending on the version of pandora), each ".ibd" is the data file of each table, when you have "innodb_file_per_table" token enabled. If you dont have any, you share a BIG file to store all data. That means table fragmentation is common on all tables and performace will be worst each week.

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

If you have your database running in a single database, you NEED TO RECREATE THE DATABASE first after setting the proper .ini value and restarting MySQL.

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

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

Using the mysq CLI, execute 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  DATA_FREE > 0 order by frag_ratio desc;

You should get only the tables with some fragmentation, 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 |
+--------+-------------------------+-------------+--------------+-----------+------------+

Work only on tables with more than 10% of fragmentation.

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

Template warning.png

Work only on tables with more than 10% of fragmentation. WARNING: Big tables (like tagente_datos) can take a huge time to optimize if are BIG and very fragmented. This MAY impact in the production system. Be careful.


Template warning.png

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


To optimize the "tagent_module_inventory" table:

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

optimize table  tagent_module_inventory;

It will give you a warning message:

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

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

If you check again you should see the 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 |
+--------+-------------------------+-------------+--------------+-----------+------------+

Template warning.png

To be able to perform this optimization it will be necessary to have the necessary space on the hard disk to perform the operation. Otherwise an error will appear and the operation will not be performed


Template warning.png

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


システム負荷

This is more general, but we need to be sure the system IO is not a bottleneck (disk). We will execute the vmstat command to get some stats from System:

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

vmstat 1 10

We should look the last columns (CPU WA), a higher than 10 value there means you have a disk I/O problem that should be solved. Having CPU US high is normal, CPU SY should nto be over 10~15. You should have swap si/so at zero, if not, means our system is using swap memory, that is a performance killer. You need to increase RAM or decrease RAM usage in your applications (Pandora server threads, Buffers in MySQL, etc.)

最後のカラム (CPU WA) を見て、10より大きい値であればディスク I/O の問題があり、解決する必要があります。CPU US が高いのは通常です。CPU SY は 10~15 を超えないようにすべきです。swap si/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

テーブルパーティショニングの利用

To use MySQL table partitioning, you should also use "multiple-tablespace" described above.

MySQLのテーブルパーティショニングを使う場合、上述の「multiple tablespace」も使用して下さい。

MySQL 5.1 supports table partitioning, which allows you to split large table into multiple small logical sub-tables. (See MySQL manual for more details: http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html)

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 and feel many console operations which refer to these data (e.g. drawing graph) are quite slow, you will improve their performance by using table partitioning.

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

For example, if you want to split tagente_datos table (which typically grow too large) into 100 logical partitions based on module id automatically, run the following query:

例えば、巨大になりがちな tagente_datos をモジュールIDに応じて100のパーティションに分割するには、次のクエリを実行します:

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

This operation may take a long time depending on table size. As an example, it took about one and half hour to split table which has about 7500 modules' data for 100 days (more than 50,000,000 rows):

この処理はとても時間がかかります。一例として、約7,500モジュールの100日分 (合計5千万件以上) のデータを保持しているテーブルの分割には1時間半程度かかりました:

mysql> ALTER TABLE tagente_datos
    ->  PARTITION BY HASH(id_agente_modulo)
    -> PARTITIONS 100;
Query OK, 53391880 rows affected (1 hour 35 min 3.41 sec)
Records: 53391880  Duplicates: 0  Warnings: 0

In the case of this table, it took about one seconds to execute following query to partitioned table, though it took more then 8 minutes for non-partitinoed one.

このテーブルの場合、以下のクエリを実行するのに、パーティショニングを行う前には8分以上かかっていましたが、パーティショニング後は1秒程度になりました。

SELECT datos,utimestamp FROM tagente_datos  WHERE `id_agente_modulo` = '6332' AND utimestamp > 1322838000 AND utimestamp < 1338390000 ORDER BY utimestamp ASC

データベースの再構成

部分的再構成

The MySQL database management system, same as with other SQL motors, such as Oracle (tm), is degraded as time goes on, due to causes as data fragmentation caused by the continue deleting and inserting into big tables. In big environments with lot of traffic volume, there is a very easy way to improve the performance and avoid that the performance would be degraded, that is: to rebuilt the DDBB in a periodical way

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

For it, you should schedule a service stop, that could last 1 hr approximately.

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

In this service stop, you should stop the Pandora FMS WEB console and also the server (be careful! keep the tentacle server to it could receive data and they will be processed as son as the server start working again).

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

Once they have been stop, we dump the DDBB (Export)

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

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

We delete the DDBB:

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

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

We create the DDBB and do an import of the previous export:

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

mysql> create database pandora3;
Query OK, 1 row affected (0.01 sec)

mysql> source /tmp/pandora3.sql

This could last some minutes minutes,depending if the system is large and the hardware is not very powerful. For one system with 1500 agents and approximately 100.000 modules. It's possible to automatize this process, but, because it's very delicate, the best option is to do this manually.

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

全体の再構築

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

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

Unfortunately MySQL is degraded with time, and this affects to the global performance of the system.There is no other solution that doesn't involve to rebuild all the database schemes from 0, 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 to the /var/lib/mysql directory, you can see that there are three files, that have always the same name, and that are, depending on the severity of the case, hugh. In my case of 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 is the one that store all the system Innobd data. In a very fragmented system, that has been a lot of time without "rebuilding" or without "installing", these system will be big a little efficient. The innodb_file_per_table parameter, that we have mentioned before, regulates part of this performance.

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

Same way, each database has in the /var/lib/mysql directory, one directory to define its structure. You should delete them also.

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

The process is very easy:

手順はとても簡単です。

  1. Dump (via mysqldump) all the schemes to disk:
  2. (mysqldump にて)全スキーマをディスクにダンプします。
  mysqldump -u root -p -A > all.sql
  1. Stop MySQL.
  2. MySQL を停止します。
  3. Delete ibdata1, ib_logfile0, ib_logfile1 and the InnoDB database directories
  4. ibdata1, ib_logfile0, ib_logfile1 および InnoDB データベースディレクトリを削除します。
  5. Restart MySQL.
  6. MySQL を再起動します。
  7. Import the backup file (all.sql)
  8. バックアップファイル(all.sql)をインポートします。
 mysql -u root -p
 mysql> source all.sql;

The system should go much faster now.

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

インデックスオプション

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

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

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

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

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

Info.png

At the moment in the heaviest tables of Pandora FMS in MySQL this optimization is there by default. It's convenient to ask experts before optimizing MySQL tables


Info.png

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


スロウクエリ

In some systems, depending on the type of information we have, we can find some "slow queries" that make the system work worse. We can enable logging of this type of queries over a short period of time (and that hurts the system performance) in order to consider trying to optimize queries to tables with indexes. To enable this setings, 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

In the OS:

コマンドラインから次のように設定します。

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

Restart mysql.

mysql を再起動します。

特定のテーブルのオプティマイズ

Other less "drastic" solution to solve the proble with fragmentation is the use of the MYSQL OPTIMIZE tool to optimize certain tables of Pandora FMS. For it, directly from MySQL, execute:

他のあまり“過激”ではないフラグメンテーションの問題を解決する方策として、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;

This will improve the performance, and it shouldn't be necessary to fire it more than once per week. It could be done "WHILE WARM", while the system is working. In very big environments the OPTIMIZE option could be "blocked". In this case the best option is to rebuild the DB.

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

After doing these operations, you should execute:

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

FLUSH TABLES;

From the 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 にマップされており、インデックス統計の更新とクラスタされたインデックス内の使用されていないスペースを解放するためにテーブルが再構築されます。

Info.png

For installations after 7.0 OUM715 the following configuration is applied by default


Info.png

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


Note: If your Pandora FMS installation was done before version 7.0 OUM 715, we recommend that you make the following modifications in your database (principal and historical):

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

alter table tagente_datos add index (id_agente_modulo,utimestamp);

This action will add an index to the tagente_data table, allowing queries that use both the reporting system, data query or module or custom graphs, to return results in a significantly shorter time than the previous one.

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

MySQL の特別なトークン

There are some tokens very "special" in MySQL: they can help or degrade the performance, there is no "fixed" rule and you will need to check it by yourself, BUT, they usually help more than make the system go worse.

MySQL には、いくつかの "特別な" トークンがあります。これらは、パフォーマンスを良くしたり悪くしたりできます。"決まった"ルールは存在せず、それぞれの環境で確認する必要があります。しかし、通常は、システムを悪化させるよりも良くする手助けになるでしょう。

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

This parameter, innodb_thread_concurrency, 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 = O_DIRECT

This important parameter affects on how is information written on disk, it helps to set to O_DIRECT.

この重要なパラメータは、ディスクにデータをどう書くかに影響します。O_DIRECT に設定すると良いです。

innodb_lock_wait_timeout = 90

This helps when your database is "stuck" in a lock due a long transaction (mysql has gone away messages). If you get more than 90 lock, you have a real problem

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

参考情報

References:

参考:

MySQL Percona XTraDB

Percona is a high performance version of MySQL, improving the scalability and using all CPU's of the system, speeding also the disk transactions.

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

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

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

Pandora FMS のキャパシティ計測

This section describes different methods to configure Pandora FMS in a high capacity environment. It also describes different tools to make load tests, 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 recommended figure is around 2500 agents per system, but this figure varies greatly depending on whether they are XML agents, remote modules, with high or low intervals, or with systems of high capacity or low memory, all factors greatly alter the number of agents that a system can manage efficiently. In laboratory tests, 10000 agents have been executed in a single server with basic hardware, but strongly optimized.

Pandora FMS は、1つのサーバでデータベース、コンソール、サーバを動かした場合、2500エージェントに対応できるように設定されています。推奨するエージェント数は、1システムあたり 2500 です。しかし、この数は、XML エージェントの割合、リモートモジュールの割合、監視間隔、システムのメモリ量に応じて変化します。これらの全ての要素が、1つのシステムで管理できるエージェント数に関わります。テスト環境では、通常のハードウエアの 1台のサーバで 10000 エージェントを実行できましたが、高度な最適化をしています。

高キャパシティサーバの設定例

For example, for one machine with 16GB of RAM and 4 CPUs that we wanted to optimize for the Data server maximum processing capacity (XML)

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

my.cnf

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

pandora_server.conf

(Only the most important parameters are shown)

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

verbose 3
server_threshold 5
dataserver_threads 1
max_queue_files 5000

You should consider these things:

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

  • The verbose number refers to the amount of information written in the logs, being recommended not to exceed 10. The higher the number, the less Pandora FMS performance will be due to the great amount of information to write in the logs.
  • verbose の数は、どの程度の情報をログに書くかで、10を超える数字にはしないでください。数字を大きくすると、ログに多くの情報を書くため、Pandora FMS のパフォーマンスが下がります。
  • A very high nº of threads(+5) only benefits to the processes with large E/S queues, like the network or the plugin server, just in case that the dataserver, which is always a processing one, could even penalize the performance. This is the reason why we use 5 here. In systems with an slow DB, we should use even less threads. Test different combinations between 1 and 10. In case of optimizing the system for the networkserver, the nº would be higher, between 10 and 30.
  • とても多くのスレッド (+5) は、ネットワークサーバやプラグインサーバのような、大きなキューの処理にのみ有効です。データサーバの場合、常に処理を実行しており、パフォーマンスを低下させる可能性があります。そのために、ここでは 5 に設定しています。DB が遅いシステムでは、スレッドを少なくするべきです。1 から 10 の間を試してみてください。ネットワークサーバの最適化の場合は、数は大きく、10 と 30 の間を試してみてください。
  • A high threshold server(15) does that the DB suffer less, and the increase in the maximum nº of files processed makes that any time that the server "looks for files" it fill the buffers. These two elements of the configuration are linked. In the case of optimizing the network server, it would be advisable to low the server threshold to 5 or 10.
  • サーバの threshold が大きい (15) と、DB への影響が少なくなり、処理できる最大ファイル数が増加します。それにより、サーバは常にファイルを読み込むことができ、バッファに蓄えます。これらの 2つの設定要素は関連があります。ネットワークサーバの最適化では、threshold を低めの 5 か 10 にすると良いでしょう。
  • Some parameters of the configuration could affect a lot to Pandora FMS performance, such as the parameter agent_access (configurable from the console).
  • agent_access (コンソールから設定できます) のようないくつかの設定パラメータは、Pandora FMS のパフォーマンスに多くの影響を与えます。

キャパシティ分析ツール (Capacity)

Pandora FMS has several tools that can help you to measure properly its hardware and software for the data amount that 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) です。

Pandora FMS の XML 負荷

This is a small script that generates XML data files like the ones sent by Pandora FMS agents. It's placed on /usr/share/pandora_server/util/pandora_xml_stress.pl

Pandora FMS エージェントから送られるような XML データファイルを生成する小さなスクリプトが /usr/share/pandora_server/util/pandora_xml_stress.pl にあります。

The scripts reads agent names from a text file and generates 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 <configuration file>

Sample configuration file:

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

# 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_descripcion Module 1 description.
module_max 100
module_min 0
# Probability of the module data changing, by default 100%
module_variation 100
module_end

module_begin
module_name Module_2
module_type generic_data_string
module_descripcion Module 2 description.
# Maximum string length, by default 0.
module_max 20
# Minimum string length, by default 0
module_min 10
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 start in your "pandora_xml_stress.conf" the configuration value "get_and_send_agent_conf" to 1, you can do that the test load agents will act as normal agents, so they send their configuration file and also the md5. And from Pandora Console Enterprise you can change the remote configuration in orther that in next executions of the pandora_xml_stress it uses the customized configuration from the Pandora Console Enterprise instead of doing it through the "pandora_xml_stress.conf" definition.

"pandora_xml_stress.conf" で、"get_and_send_agent_conf" を 1 に設定して実行した場合、テスト負荷エージェントで、通常のエージェントのように設定ファイルおよび md5 を送ることができます。エンタープライズ版の Pandora コンソールでは、pandora_xml_stress で次に何を実行するのか、リモートでの設定変更を行うことができます。pandora_xml_stress.conf ではなく、エンタープライズ版の Pandora コンソールから行った設定を利用するようになります。

Besides this, you can configure where to store in a local way the conf of your testing agents with the "directory_confs" configuration token in the file "pandora_xml_stress.conf".

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

設定ファイル
  • max_threads Number of threads where the script will be executed.This improves the E/S.
  • max_threads スクリプトの実行スレッド数。処理率を改善します。
  • agent_file Path of the name list file path, separated by new line
  • agent_file 行ごとに名前を書いたファイルのパス。
  • temporal Path of the directory where the fictitious XML data files are generated.
  • temporal 架空の XML データファイルを生成するディレクトリのパス。
  • log_file Path of the log where it will inform about its execution script.
  • log_file スクリプトの実行について情報を出力するログのパス。
  • xml_version Version of the XML data file (by default 1.0)
  • xml_version XML データファイルのバージョン。(デフォルトは 1.0)
  • encoding XML data files encoding (by default ISO-8859-1).
  • encoding XML データファイルのエンコーディング。(デフォルトは ISO-8859-1)
  • os_name Name of the fictitious agent Operative System (by default Linux).
  • os_name 仮想エージェントの OS 名。(デフォルトは Linux)
  • os_version Version of the fictitious agents Operative System (by default 2.6)
  • os_version 仮想エージェントの OS バージョン。(デフォルトは 2.6)
  • agent_interval Interval of the fictitious agents in seconds (by default 300).
  • agent_interval 仮想エージェントの実行秒間隔。(デフォルトは 300)
  • time_from Time from which fictitious XML data files are generated, in format" YEAR-MONTH-DAY HOUR:MIN:SEC"
  • time_from 仮想 XML データの開始時間。"年-月-日 時間:分:秒" というフォーマットにて。
  • time_to Time until which fictitious XML data files are generated, in format YEAR-MONTH-DAY HOUR:MIN:SEC"
  • time_to 仮想 XML データの終了時間。"年-月-日 時間:分:秒" というフォーマットにて。
  • get_and_send_agent_conf Boolean value 0 or 1. When it is active the fictitious agents will try to download by remote configuration a more updated version of the standard configuration file of an agent. And from the Pandora FMS Enterprise console you can edit them.
  • get_and_send_agent_conf 0 または 1 の値です。有効な場合、仮想エージェントは、リモート設定により、より新しいエージェントの設定ファイルをダウンロードしようとします。Pandora FMS Enterprise のコンソールから編集可能になります。
  • startup_delay Time numeric value in seconds before each agent starts to generate the files. It is used to avoid race conditions.
  • startup_delay それぞれのエージェントがファイル生成を開始するまでの時間を秒で指定します。競合を回避するために利用します。
  • timezone_offset Numeric value of the time zone offset
  • timezone_offset タイムゾーンのオフセット値です。
  • timezone_offset_range Numeric value that is useful to generate the timezone in this range in a random way.
  • timezone_offset_range ランダムに指定した範囲でタイムゾーンを生成します。
  • latitude_base Numeric value. It's the latitude where the fictitious agents will be shown.
  • latitude_base 数値です。仮想エージェントを表示する緯度です。
  • longitude_base Numeric value. It's the longitude where the fictitious agents will be shown.
  • longitude_base 数値です。仮想エージェントを表示する経度です。
  • altitude_base Numeric value. It's the altitude where the fictitious agents will be shown.
  • altitude_base 数値です。仮想エージェントを表示する高度です。
  • position_radius Numeric value. It's the range around. The circumference with this radius where the fictitious agent is shown in a random way.
  • position_radius 数値です。指定した半径内の円に仮想エージェントがランダムに表示されます。
モジュール定義

The definition of one module in the script configuration file and if you have activated the remote configuration will also be the same. It is:

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

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

And you can configure each of them as:

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

  • <type of exec>:Can have the values RANDOM,SCATTER,CURVE.
  • <タイプ>: 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 <値>: モジュールの値を指定した値で掛け合わせます。通常 0.1 と 0.9 の間です。
  • module_attenuation_wdays <value> <value> ... <value>: The module value is only attenuated 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:
  • 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 one, the module's previous value is alway added to a new value, resulting in an increasing function.
  • module_incremental <値>: 1に設定すると、モジュールの以前の値を常に新たな値に加えます。値が増え続ける機能です。
  • Others: See below what options are available, depending on the execution type.
  • その他: 実効タイプに依存して、どのようなオプションがあるかは以下を確認してください。

Note that min/max_critical and min/max_warning are only available in 5.0 or higher version.

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

RANDOM

These have the following options:

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

  • variation probability in % that it would change regarding the previous value.
  • variation 前回の値から変化が発生する可能性を % で指定します。
  • min Minimum value that the the value could have.
  • min 値の最小値を指定します。
  • max Maximum value that the the value could have.
  • max 値の最大値を指定します。

Numeric

Generates random numeric values between the ranges value min and the value max

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

Boleans

Generates values between 0 and 1.

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

String

Generates a string of length between values minand max. The characters are random between A and Z and includes capital and lower case letters and also numeric ciphers.

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

外部データソース (SOURCE)

Allows you to use a plain text file as a data source. Options:

  • src: source data file.

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

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

The file contains one data per line, there is no limit for lines. For example:

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

4
5
6
10

There are two possibilities for data (numeric and strings). These kind of modules will use data from file to generate module data in Pandora, data will be get secuentially. For example data above will be shown as follows:

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

It is only useful for numeric data, and the generated graphics are similar to the ones of a heartbeat, that is, a normal value, and from time to time a "beat".

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

It has the following options:

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

  • min Minimum value that the value could have.
  • min とりうる最小の値。
  • max Maximum value that the value could have.
  • max とりうる最大の値。
  • prob Probability in % that it generates a "beat".
  • prob "beat" を生成する頻度を % で指定します。
  • avg Average value that it should show by default if there isn't any "beat".
  • avg "beat" が無い場合に、デフォルトで表示する平均値。
CURVE

Generates module data following a trigonometric curve. They have the following options:

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

  • min Minimum value that the value could have
  • min とりうる最小の値。
  • max Maximum value that the value could have
  • max とりうる最大の値。
  • time_wave_length Numeric value in seconds of the duration of the "crest" of the wave
  • time_wave_length 山が出現する時間。
  • time_offset Numeric value in seconds from the starting of the wave from time zero with module value zero (similar to the sine graph)
  • time_offset モジュールの値が 0 の時の波形の開始タイミングを秒で指定します。(正弦波に似ています)
700px
注意事項

Please, consider that the amount of generated files is the link between the starting time (time_from)and the final date (time_to) and the interval setted in the agent (agent_interval),so is there are long periods of time or small intervals, the script will generate lot of XML data files.

開始日時(time_from)と終了日時(time_to)の間に生成されるファイルの量と、エージェントの実行間隔(agent_interval)には十分注意してください。長い期間で短い実行間隔の場合、スクリプトは大量の XML ファイルを生成します。

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

There is an small script called "pandora_count.sh" that is in the util/directory in the 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 pending of processing at /var/spool/pandora/data_in so to can use it you need thousand of packages pending of being processed (or to generate them with the tool mentioned before). This script takes into account only the packages that are now, and it take them away from the packages that were 10 seconds ago, then divide 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's a rudimentary solution but it serves to fix the server configuration.

"pandora_count.sh" というスクリプトが Pandora FMS サーバパッケージの /util ディレクトリにあります。このスクリプトは、データサーバの XML ファイル処理率を計測するのに利用します。このツールは、/var/spool/pandora/data_in に残っているファイルを利用します。そのため、未処理の数千のファイルを用意しておく (もしくは前述のツールで生成しておく) 必要があります。このスクリプトは、現在存在するファイルをカウントし、10秒前に処理したものを除外し、結果を 10 で割ることによって、1秒間の処理率を求めています。これは初歩的なソリューションですが、サーバの設定を修正するための情報を提供します。

Pandora FMS の DB 負荷

This is an small tool to test its database performance. You can also use it to «pregenerate» periodical or aleatory data (using trigonometric functions) and fill fictitious modules. You should create an agent and assign modules for automatic data injection with this tool. The names should be given taking in account these advices:

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

  • random: to generate aleatory data.
  • random: 不定期データを生成します。
  • curve: to generate a coincidence curve using trigonometric functions. Useful to see the interpolation work with different intervals, etc.
  • curve: 三角関数を利用して曲線データを生成します。異なる間隔で補完を見るのに便利です。
  • boolean: To generate aleatory boolean data.
  • boolean: ランダムな boolean データを生成します。

So you could use any name that would have the words «random», «curve» and/or «boolean», for example:

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

  • random_1
  • curve_other

You could only choose the «data_server» kind of module.

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


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

This tool is pre configured to search, in all agents, the name modules «random», «curve» or«boolean», and for that they use an interval between 300 seconds and 30 days.

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

If you want to modify this performance, you should edit the pandora_dbstress script and modify some variables in the beginning of the file:

もしこの設定を変更したい場合は、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 variable line that corresponds with target_module, should be fix for a fix module or -1 to process all the targets that coincide. The second variable line corresponds with target_agent, for an specific agent. The third line corresponds with target_interval, defined in seconds and that represents the module predetermined periodicity interval. The fourth line is target_days and represents the number of days in the past from the date, in timestamp, at present.

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

Pandora FMS の診断ツール

Sometimes, the user have problems and Pandora Developers can't help without more information about the user systems. In 3.0 version we have created two small tools to help solving user problems:

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

診断情報

In more current versions of Pandora FMS there is a functionality to obtain diagnostic information of our installation of Pandora FMS.

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

It is inside the section of Admin tools -> Diagnostic Info

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

ファイル:Diagnostic Info.png

In this window we can see information about Pandora FMS and MySQL configuration, as well as self-monitoring system graphs.

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

pandora_diagnostic.sh

Is a tool placed on /usr/share/pandora_server/util and it gives a lot of information about the system:

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

  • CPU information
  • CPU 情報
  • Uptime and CPU avgload
  • Uptime および CPU ロードアベレージ
  • Memory information
  • Memory 情報
  • Kernel/Release information.
  • Kernel/Release 情報
  • A fully mysql config file dump.
  • mysql 設定ファイルの内容
  • A fully PandoraFMS Server config file dump (filtering passwords).
  • PandoraFMS サーバ設定ファイルの内容 (パスワードはフィルタリングされます)
  • Pandora FMS logs information (but not the full log!).
  • Pandora FMS ログ情報 (ただし、全ログではありません)
  • Disk information
  • Disk 情報
  • Pandora FMS processes information
  • Pandora FMS プロセス情報
  • A fully kernel log information (dmesg).
  • kernel ログ情報 (dmesg)

All information is generated in a .txt file so users can sent this information to anyone who wants to help them, for example in Pandora FMS user forums or in the Pandora FMS public mailing lists. This information should not have any kind of confidential information. Note that you probably want to run with root privileges if you want to get pandora_server.conf and my.cnf files parsed.

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

This is an example of execution:

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

$ ./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'

And this is some parts of file output

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

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

(OBSOLETE)

incoming ディレクトリでの RAM ディスク (tmpfs) の利用

In some environments of high capacity for the XML processing coming from agents, the directory directorio /var/spool/pandora/data_ has a high traffic and to have this file system available in a memory storage can improve the XML processing performance in a 25%.

エージェントから大量の XML が送られてくるような環境では、/var/spool/pandora/data_in ディレクトリの大量の読み書きが発生します。このファイルシステムをメモリ上に置くと、XML 処理のパフォーマンスが 25% 上昇します。

To create a partition in /var/spool/pandora/data_in_RAM, it will be enough with the command:

/var/spool/pandora/data_in_RAM パーティションを作成するするには、次のコマンドを実行します。

mount -t tmpfs -o size=100M,nr_inodes=10k,mode=770 tmpfs /var/spool/pandora/data_in_RAM

It is possible to program in /etc/inittab so as this partition would be created when starting. The end directory should be exist and be empty.

/etc/inittab で設定すれば、システム起動時にこのパーティションが作成されます。なおディレクトリは作成済で空である必要があります。

tmpfs /var/spool/pandora/data_in_RAM tmpfs size=100M,nr_inodes=10k,mode=770 0 0

Of course, as it is limited to 100MB, if the system is filled it will stop working properly. If you are working with policies or remote configurations the directories that usually hang from /data_in (file collections, md5, conf and others) should be located as links to their real paths in the disk, with an structure based in the following commands:

もちろん、これは 100MB の容量制限があります。いっぱいになると処理が停止します。ポリシーやリモート設定を使っている場合は、/data_in ディレクトリの下にそれらに必要なディレクトリ (collections, md5, conf およびその他) が存在します。これらも次のようなコマンドで、パスを調整する必要があります。

mv /var/spool/pandora/data_in /var/spool/pandora/data_in_old
ln -s /var/spool/pandora/data_in /var/spool/pandora/data_in_RAM
ln -s /var/spool/pandora/data_in_old/md5 /var/spool/pandora/data_in_RAM/md5
ln -s /var/spool/pandora/data_in_old/conf /var/spool/pandora/data_in_RAM/conf
ln -s /var/spool/pandora/data_in_old/collections /var/spool/pandora/data_in_RAM/collections

同一システムにおける多くのリクエスト

An special case to implement a bigger processing power in servers with several processors (of two or more physical cores) consist of implementing several instances of Pandora Specific servers in the same machine, some that has nothing to do with increasing the nº of threads of the server, so due to the design of the Linux Kernel and of the Perl virtual machine, it is possible to take the most of the cores with several processes than with more threads in the same process

複数プロセッサ (2つ以上の物理コア) のサーバにおいて多くの処理を実行する必要がある場合、Pandora のいくつかのサーバの複数インスタンスを同一マシン上で上げることにより実現できます。これは、サーバのスレッド数を増やすということではなく、Linux kernel および Perl の仮想マシンの設計を使って、同一のプロセスで多くのスレッドを使うのではなく、複数のプロセスで多くのコアを使うという考えです。

You can use this technique when Pandora FMS is not able of processing all the information without delaying to much. This options means that you should have to install another Pandora FMS server with other incoming entry directory. Of course it will have its own pandora_server.conf and a different server name. You should also do some changes in the server firing script and other smaller customizations in the system.

Pandora FMS が遅延なく全ての情報を処理できないような場合にこの技術を使うことができます。この方法では、別の Pandora FMS サーバを別のディレクトリにインストールする必要があることを意味しています。もちろん、それぞれ別々のサーバ名で別々の pandora_server.conf があります。また、サーバの起動スクリプト等を若干修正する必要もあります。