====== Pandora FMS の最適化と問題解決 ====== {{indexmenu_n>8}} [[:ja:documentation:start|Pandora FMS ドキュメント一覧に戻る]] Pandora FMS server can monitor about 2000 devices (between 5 and 80 thousands modules, [[:en:documentation:pandorafms:installation:01_installing#ks1_2|depending on available hardware]]); but this also requires fine-tuning the database configuration. Pandora FMS サーバは、約 2000のデバイス(5 から 8万モジュール、[[:ja:documentation:pandorafms:installation:01_installing#ks1_2|ハードウエアに依存します]])のモニタリングが可能です。ただし、そのためには、データベースの設定を調整する必要があります。 This article also explains some techniques to detect and solve problems of your Pandora FMS installation. この章ではまた、Pandora FMS の問題発見および解決のためのテクニックについて説明します。 ===== Percona の最適化 ===== 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 learn more about "Data Backup and Recovery in Pandora FMS", [[:en:documentation:pandorafms:technical_annexes:07_backup_and_restore_procedures|follow this link]]. "Pandora FMS におけるデータバックアップとリカバリ" についての詳細は、[[:ja:documentation:pandorafms:technical_annexes:07_backup_and_restore_procedures|こちら]]を参照してください。 ==== 一般的に推奨する設定 ==== * Unless otherwise specified, this entire topic refers to **MySQL version 8** . * See also "[[:en:documentation:pandorafms:technical_annexes:19_mysql_8|Upgrading from MySQL 5.7 to MySQL 8]]". * 特に明示されていない限り、ここでの説明は **MySQL バージョン 8** を前提としています。 * "[[:ja:documentation:pandorafms:technical_annexes:19_mysql_8|]]" も合わせて参照してください。 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 システムでは、[[https://en.wikipedia.org/wiki/Year_2038_problem|2038年]]以降重大な問題があります。 * よりよいパフォーマンスを得るために十分なメモリとCPUを用意します。われわれの経験では、CPUよりもメモリのほうが重要です。エンタープライズレベルであれば最低 4GiB 必要です。巨大なシステムであれば、16GiB 割り当てるというのもよいでしょう。メモリが十分あれば、利用されるインデックスの大半をメモリ上に置くことでインデックスの更新が高速化されるということを忘れてはいけません。 * 障害が発生した場合にシステムを切り離すようにできるようにするのが良いでしょう。特定のサーバにデータベースがあるシステムの場合は、ギガビットイーサを利用すべきです。待ち時間はパフォーマンスにとって重要です。 * ディスクの最適化は、とても大きなデータベースにとっては大変重要です。データベースおよびテーブルを異なるディスクに分割すべきです。MySQL では、シンボリックリンクを使うことができます。システムおよび、データベースで異なるディスクを使い、一つのハードディスクのアクセスを減らすようにすることが重要です。 The use of SSD disks is recommended due to their speed and improved system latency. システムの応答時間を早めるために、SSD を利用することをお勧めします。 * 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 ([[https://www.percona.com/software/mysql-database/percona-server|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 ([[https://www.percona.com/software/mysql-database/percona-server|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 [[#ks1_12|in specific cases]]. * MySQL® でレプリケーション設定を行う時のみ binary log を利用してください。 * クエリのトレースログや //スロークエリログ// は利用しないでください。これは[[#ks1_12|特定の場合にのみ推奨されます]]。 ==== バイナリログ出力の停止 ==== If you configured a [[:fr:documentation:pandorafms:complex_environments_and_optimization:06_ha|Pandora FMS HA system]], **the binary replication is necessary**. This recommendation is only valid if you have a single Pandora FMS server. [[:ja:documentation:pandorafms:complex_environments_and_optimization:06_ha|Pandora FMS HA システム]]を設定している場合は、**バイナリログは必須です** 。ここに記載している内容は、Pandora FMS サーバが 1台の場合にのみ有効です。 It is enabled by default on most GNU/Linux distros. To disable it, edit the ''my.cnf'' file, usually in ''/etc/my.cnf'' and //comment// the following lines: 多くの GNU/Linux ディストリビューションにおいてデフォルトで有効になっています。無効にするには、''my.cnf'' ファイル (通常、''/etc/my.cnf'' にあります) を編集し、次の行をコメントアウトします。 # log-bin=mysql-bin # binlog_format=mixed //Comment// both lines, **and then restart MySQL Server**. 両方の行を//コメントアウト// し、**MySQL サーバを再起動します** 。 ==== ディスク I/O パフォーマンス ==== To learn more about “Data Backup and Recovery in Pandora FMS”, [[:en:documentation:pandorafms:technical_annexes:07_backup_and_restore_procedures|go to this link]]. "Pandora FMS におけるデータバックアップとリカバリ" に関する詳細は、[[:ja:documentation:pandorafms:technical_annexes:07_backup_and_restore_procedures|こちら]]を参照してください。 There are three very important configuration tokens, directly related to disk IO, and should be considered because improper IO access is usually the most important bottleneck in MySQL. ディスク I/O に直結し、考慮すべきとても重要な 3つの設定があります。MySQL において、不適切な I/O アクセスは、通常最も重要なボトルネックになります。 **innodb_log_file_size** innodb_log_file_size = 64M This value is set by default, which can be higher (even 512M) without any risk, except for recovery in case of any problem or higher disk occupation. The default value of MySQL is 5M, which is very low for production environments with high transaction volume. **To change this value with an already running system:** デフォルトではこの値が設定されていますが、問題が発生した場合の回復とディスク占有率が増えることを除いては、事前検証なしに高くすることができます(512Mでも)。 MySQL のデフォルト値は 5M です。これは、トランザクション量が多い本番環境では非常に低い値です。 稼働中のシステムで値を変更するには、次のようにします。 - First make a complete DUMP in the databases. - Delete the **Innodb** binary index files (usually in ''/var/lib/mysql/ib*''. - Change file ''my.cnf'' with the hosen value. - Restart MySQL. - Load the SQL DUMP. - データベースのフルバックアップ(SQL ダンプ)を行います。 - Innodb バイナリインデックスファイル(通常は ''/var/lib/mysql/ib*'' です)を削除します。 - my.cnf を編集します。 - MySQL を再起動します。 - ダンプを読み込みます。 Since the process is the same as the one to activate the ''//innodb_file_per_table//'' token (described below), **it is recommended to do the whole process simultaneously.** サーバは、新たなトランザクションログファイルを新たなサイズで再生成し、通常通り動きだします。この処理は ''innodb_file_per_table'' トークン(後述)を有効化するのと同じであるため、処理全体を同時に行うことをお勧めします。 **innodb_io_capacity** innodb_io_capacity = 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 [[https://dev.mysql.com/doc/refman/8.0/en/innodb-configuring-io-capacity.html|this link]]. デフォルトでは、このパラメータの値は 200 です。ただし、事前にシステムのディスクの IOPS を知る必要があります。正確な IOPS およびハードディスクのモデルを知ることができます。ここでのお勧めの値は、7500RPM → 100 IOPS, 15000 RPM → 190 IOPS, SSD → 1500 IOPS です。詳しくは[[https://dev.mysql.com/doc/refman/8.0/ja/innodb-configuring-io-capacity.html|こちらのリンク]]を参照ください。 **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'' となっています。 ==== KeyBuffer の大きさ ==== システムに搭載された物理メモリ量に依存しますが、非常に重要なグローバル変数であり、これを設定することで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 **For MySQL version 8**, and later versions, MySQL development team has withdrawn support for //query cache//, used in previous versions of Pandora FMS; for more information, please visit the following web link: [[https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/|https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/]] . **MySQL バージョン 8** 以降では、//query cache// のサポートが廃止されました。詳細については以下を参照してください。 [[https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/|https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/]] . ==== InnoDB の同時実行スレッド ==== 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 で "同時実行スレッド" をいくつにするのかを設定するのに利用します。 This is an advanced parameter and should only be modified manually **if performance tuning is required on high concurrency systems**. これは高度なパラメータであり、**多くの同時実行を行うシステムでパフォーマンスチューニングが必要な場合** のみ手動で変更する必要があります。 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 [[https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_thread_concurrency|official MySQL documentation]]. * MySQL バージョン: 異なるバージョンの MySQL では、このパラメータはとても異なる動作をします。 * 物理プロセッサ数: この点については、[[https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_thread_concurrency|公式のMySQLドキュメント]] を参照してください。 The recommended value is the number of (physical) CPUs multiplied by 2 plus the number of disks where InnoDB is located. 推奨値は、CPU(物理)の数に 2を掛けたものに、InnoDB が配置されているディスクの数を加えたものです。 The value of ''innodb_thread_concurrency'' [[https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-thread_concurrency.html|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'' の値は [[https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-thread_concurrency.html|MySQL のいくつかのバージョンで変更されています]]、現在デフォルト値は ''0'' です。 ''0'' は「可能な限り多くのスレッドを開く」ことを意味します。 したがって、良くわからない場合は次のように設定できます。 innodb_thread_concurrency = 0 ==== MySQL フラグメンテーション ==== 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 の設定やデータベースに関する問題である可能性があります。 === my.cnf 設定の確認 === 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 If there is any change in ''my.cnf'' file, restart **MySQL** service. ''my.cnf'' ファイルを変更した場合は、**MySQL** サービスを再起動します。 * 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 [[http://dev.mysql.com/doc/refman/8.0/en/error-log.html|link]] at MySQL website. * ''systemctl status mysqld.service'' にてサービスの状態を確認します。 * エラーの確認には ''/var/log/mysqld.log'' の最後を見てください。 * より詳細は、MySQL サイトの [[http://dev.mysql.com/doc/refman/8.0/en/error-log.html|こちら]]を確認してください。 === データベースのリストア === To learn more about "Server Management and Administration", [[:en:documentation:pandorafms:installation:06_server_management#ks4|follow this link]]. サーバ管理のより詳細は、[[:ja:documentation:pandorafms:installation:06_server_management#データベースバックアップ|こちら]]を確認してください。 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 MySQL/Percona systems often do not load correctly the configuration parameters of the ''my.cnf'' file, usually because these values **have been written outside** ''[mysqld]'' **section**. MySQL/Percona システムでは、多くの場合、''my.cnf'' ファイルの設定パラメータが正しく読み込まれません。これは通常、これらの値が **''[mysqld]'' セクションの外部に書き込まれている** ためです。 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 [[#ks1_10|rebuild the DB]]. 非常に大規模な環境では、**OPTIMIZE** オプションが「ブロック」される可能性があります。この場合、最善のオプションは [[#ks1_10|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 にマップされ、テーブルを再構築してインデックス統計を更新し、クラスター化インデックス内の未使用領域を解放します// 」。 === MySQL 特殊トークン === 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'' など) は、断片化が激しい場合、最適化に長い時間がかかることがあります。これは、実稼働システムに影響を与える可能性があります。 Caution is advised when optimizing such large tables. A normal environment could be optimized once a year and larger environments every six months. このような大きなテーブルを最適化する場合は注意が必要です。通常の環境は 1 年に 1 回、大規模な環境は 6 か月ごとに最適化できます。 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 | +--------+-------------------------+-------------+--------------+-----------+------------+ To be able to perform this optimization, there must be enough space on the hard disk to perform the operation. Otherwise an error will appear and the operation will not be performed. 最適化を実行するには、操作を実行できるだけのディスクの空き容量が必要です。そうでないとエラーとなり処理が実行されません。 === システム負荷 === 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 テーブルパーティショニング ==== To use MySQL table partitioning, you should also use the //multiples tablespaces// system [[#ks1_3|described above]] (''innodb_file_per_table''). MySQL テーブルパーティショニングを使用するには、[[#ks1_3|上記で説明した]] //複数のテーブルスペース// システム (''innodb_file_per_table'') も使用する必要があります。 MySQL supports table partitioning, which allows very large tables to be distributed into smaller chunks, such as logical subdivisions (see the [[http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html|MySQL manual]] for details). MySQL はテーブルパーティショニングをサポートしており、これにより、非常に大きなテーブルを論理的なサブディビジョンなどの小さなチャンクに分散できます (詳細については、[[http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html|MySQL マニュアル]] を参照してください)。 If you have large amounts of data in Pandora FMS database (main and [[:en:documentation:pandorafms:complex_environments_and_optimization:09_pandorafms_engineering#ks1_5|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 (メインおよび[[:ja:documentation:pandorafms:complex_environments_and_optimization:09_pandorafms_engineering#ヒストリデータベース|ヒストリ]]の両方の)データベースに大量のデータがあり、グラフ描画のようなデータを参照する処理がとても遅いと感じるなら、テーブルパーティショニングを行うことでパフォーマンスを改善できるでしょう。 === 自動パーティショニング === 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 [[:en:documentation:pandorafms:management_and_operation:12_console_setup#ks1_4|check this link]]. Pandora FMS は、Web コンソールの一般設定のセクション **ヒストリデータベース** から設定されている場合、ヒストリデータベースの月次パーティショニングを自動的に実行します。詳細については、[[:ja:documentation:pandorafms:management_and_operation:12_console_setup#ヒストリデータベース|こちら]]を参照してください。 === 手動パーティショニング === 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 "[[#ks1_9_1|Automatic partitioning]]"). Pandora FMS をインストールし、ヒストリデータベースを有効にすると、これが最大量のデータを保持するものになります。**テーブルパーティション分割の実行が推奨されます。** これに指定されているテーブルは、正確には ''tagente_datos'' 、''tagente_datos_string'' 、''tagente_datos_inc'' 、および ''tevento'' です。テーブル ''tagente_datos'' の手動による実際の処理については、以下で説明します (「[[#ks1_9_1|自動パーティション分割]]」も参照してください)。 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 ==== データベースの再構成 ==== \\ To find out more abour Pandora FMS backup and data recovery, go to this [[:en:documentation:pandorafms:technical_annexes:07_backup_and_restore_procedures|link]]. \\ \\ Pandora FMS のバックアップとデータ復旧の詳細については、[[:ja:documentation:pandorafms:technical_annexes:07_backup_and_restore_procedures|こちら]] を参照してください。 \\ === 部分的再構成 === 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時間程度のサービス停止を計画すべきです。 In this service stop, stop the Pandora FMS WEB console and the server too. **Attention**: you may leave the Tentacle server, so that it can still receive data and these will be processed as soon as the server works again. 計画的なサービス停止時に、Pandora FMS Webコンソールとサーバも停止すべきです (**注意** tentacle サーバはデータを受け取れるようにしておき、サーバが復旧次第データを処理できるようにします) 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. データベースのサイズとマシンで使用可能なリソースに応じて、数秒から数分かかる場合があります。 It is possible to automatize this process, but, because it is very delicate, the best option is to make it manually. この処理を自動化することは可能ですが、非常にデリケートなため、手動で実行するのが最善のオプションです。 === 全体の再構築 === 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 [[#ks1_3|mentioned before]], regulates part of this performance. ''ibdata1'' ファイルは、すべてのシステム Innobd データを保存するファイルです。長い間「再構築」または「インストール」されていない非常に断片化されたシステムでは、これは大きくなり効率は下がります。[[#ks1_3|前に説明した]] ''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: 手順はとても簡単です。 - Dump (via **mysqldump**) all the schemes to the disk: - すべてのスキーマをディスクにダンプします (**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`); At the moment, in the heaviest tables of Pandora FMS in MySQL, this optimization is there by default. **It is advisable to have expert help to optimize MySQL tables**. 現在、MySQL の Pandora FMS の最も重いテーブルでは、この最適化がデフォルトになっています。MySQL テーブルを最適化する前に専門家に相談するのが良いです。 ==== スロウクエリ ==== 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: いくつかのシステムでは保持している情報によって、通常よりもシステムのパフォーマンスが悪いスロウクエリが見られることがあります。テーブルを最適化するために、(システムのパフォーマンスに影響する)一定時間を超えたこのタイプのクエリをログに記録するようにできます。これを有効にするには次のようにします。 * [[#ks1_8_1|Edit]] ''my.cnf'' and add the following lines: * my.cnf を[[#ks1_8_1|編集]]し、次の設定を加えます。 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 サービスを再起動することを忘れないでください。 ==== 参考サイト ==== * [[https://web.archive.org/web/20100414124138/https://dev.mysql.com/tech-resources/presentations/presentation-oscon2000-20000719/|http://dev.mysql.com/tech-resources/presentations/presentation-oscon2000-20000719/index.html]] * [[http://jeremy.zawodny.com/mysql/mysql-optimization.html|http://jeremy.zawodny.com/mysql/mysql-optimization.html]] ===== 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, 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 処理) を出すように最適化したいと思います。 === 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=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 === pandora_server.conf === Only the most relevant parameters are shown. 重要なパラメータのみを示しています。 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 ''[[:en:documentation:pandorafms:installation:04_configuration#dataserver_threads|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. * ''[[:ja:documentation:pandorafms:installation:04_configuration#dataserver_threads|dataserver_threads]]'' に設定された非常に多数のスレッド(5以上)は、ネットワークサーバやプラグインサーバなど、E/S 待機時間が長い処理がある場合にのみメリットがあります。継続的に処理されているデータサーバの場合は、**パフォーマンスに影響を与える可能性さえあります** 。 データベースの速度が遅いシステムでは、使用するスレッドをさらに少なくします。1〜10 のさまざまな組み合わせを試してください。ネットワークサーバ用にシステムを最適化する場合、その数は 10〜30の間の大きな値にします。 ==== キャパシティ分析ツール (Capacity) ==== 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**) です。 === Pandora FMS の XML 負荷 === 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_type module_description module_exec type =;; … module_unit module_min_critical module_max_critical module_min_warning module_max_warning module_end 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 Each one can be configured as: それぞれの項目は次のように設定可能です。 * **type_generation_xml_stress**: It can have values [[#ks2_2_1_1|RANDOM]], [[#ks2_2_1_2|SCATTER]], [[#ks2_2_1_3|CURVE]]. * **module_attenuation **: The generated module value is multiplied by the specified value, usually between 0.1 and 0.9. * **module_attenuation_wdays … **: 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に設定すると、モジュールの以前の値を常に新たな値に加えます。値が増え続ける機能です。 * **その他**: 実効タイプに依存して、どのようなオプションがあるかは以下を確認してください。 == RANDOM == 次のオプションがあります。 * **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 ==SCATTER== 数値データの場合のみ有用で、ハートビートのようなグラフを生成します。これは通常の値で、ある時間に //"beat"// を出します。 次のオプションがあります。 * **min** とりうる最小の値。 * **max** とりうる最大の値。 * **prob** //"beat"// を生成する頻度を % で指定します。 * **avg** //"beat"// が無い場合に、デフォルトで表示する平均値。 ==CURVE== 三角関数を使った曲線でモジュールデータを生成します。 次のオプションがあります。 * **min** とりうる最小の値。 * **max** とりうる最大の値。 * **time_wave_length** 山が出現する時間。 * **time_offset** モジュールの値が 0 の時の波形の開始タイミングを秒で指定します。(正弦波に似ています) {{ wiki:Curve module xml stress.v2.png?700 }} **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秒間の処理率を求めています。これは初歩的なソリューションですが、サーバの設定を修正するための情報を提供します。 === Pandora FMS の DB 負荷 === データベースパフォーマンスを確認するためのツールがあります。これはまた、架空のデータを定期的もしくは不定期に生成するためにも利用できます。エージェントを作成し、このツールを使って自動的にデータを挿入するためのモジュールを作成しておく必要があります。 * //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; - The first line of the variable corresponding with ''target_module'' should be fixed for a fix module or ''-1'' to process all the matching targets. - The second line of variable must match ''target_agent'', for a specific agent. - The third line must match ''target_interval'', defined in seconds and which represents the module predefined periodical interval. - The fourth line is ''target_days'' and represents the number of days in the past since the date, in the current //timestamp//. - 最初の行の ''target_module'' の設定では、対象のモジュールを指定するか ''-1'' を指定すると全てが対象になります。 - 2行目の ''target_agent'' は、エージェントの指定です。 - 3行目の ''target_interval'' は、秒単位で実行間隔を指定します。 - 4行目の ''target_days'' は、現在日時から何日後までかを表します。 ===== Pandora FMS の診断ツール ===== 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 の設定とデータベースに関する最も重要な情報を提供するように設計されています。 [[:wiki:diagnostic_info.png?id=ja%3Adocumentation%3Apandorafms%3Acomplex_environments_and_optimization%3A08_optimization&media=wiki:diagnostic_info.png|{{ :wiki:diagnostic_info.png }}]] [[:ja:documentation:start|Pandora FMS ドキュメント一覧に戻る]] ===== (OBSOLETE) ===== ==== pandora_diagnostic.sh ==== {{ :wiki:pfms-pandora_diagnostic.sh.png }} ///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