私は (ほぼ) 専用のシステムを持っており、これをいくつかのデータベースに使用しています。私の問題: Java アプリケーションの実行が非常に遅く (タスクを完了するのに 2 ～ 3 日かかる)、その理由がわかりません。
システムは、Xubuntu 12.04.1 LTS、3.2.0-32-generic x86_64、mySQL 5.5.28、Phenom X2 550、16 GB RAM、Intel SSD 520 (高い IOPS で知られる SandForce プロセッサを使用) です。
まず、CPU 負荷が実際には 100% になることはありません。ほとんどの場合、htop の出力は次のようになります。
1 : 63.9% sys: 12.9% low: 0.0% Tasks: 99, 164 thr; 2 running
2 : 18.5% sys: 21.2% low: 0.7% Load average: 1.14 1.23 1.22
Mem[|||||||||||||||||13490/16049MB] Uptime: 1 day, 06:32:13
Swp:8188M used:195M Time: 18:33:04
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
16168 micha 20 0 5163M 1595M 4500 S 75.0 9.9 11h36:10 java -jar ./build
16169 micha 20 0 5163M 1595M 4500 R 75.0 9.9 11h31:34 java -jar ./build
5968 mysql 20 0 11.9G 10.7G 3992 S 31.0 68.4 13h21:10 /usr/sbin/mysqld
6142 mysql 20 0 11.9G 10.7G 3992 S 31.0 68.4 10h44:50 /usr/sbin/mysqld
mysqld の CPU 使用率が Java よりも高い場合もありますが、両方のコアで 100% 近くになることはありません。
私が取り組んでいるデータベースはかなり大きく、合計 24 GB の InnoDB テーブルがあります。すべてのテーブルにはPRIMARYキーがありEXPLAIN、インデックスを正しく取得するためにも使用していました。Java ツールはかなり単純なことを行いますが、その量は膨大です。関連するテーブルには約 1,000 ～ 2,000 万行あり、Java アプリケーションはさらに多くのクエリを実行しています ( SELECT、UPDATEおよびINSERT)。準備済みステートメントを使用しています。
これらは InnoDB の私の設定です:
mysql> show variables like 'innodb%'
-> ;
+---------------------------------+------------------------+
| Variable_name | Value |
+---------------------------------+------------------------+
| innodb_adaptive_flushing | ON |
| innodb_adaptive_hash_index | ON |
| innodb_additional_mem_pool_size | 8388608 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 10737418240 |
| innodb_change_buffering | all |
| 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_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | OFF |
| innodb_flush_log_at_trx_commit | 0 |
| innodb_flush_method | |
| innodb_force_load_corrupted | OFF |
| innodb_force_recovery | 0 |
| innodb_io_capacity | 200 |
| innodb_large_prefix | OFF |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_size | 5242880 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_max_dirty_pages_pct | 75 |
| innodb_max_purge_lag | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 0 |
| innodb_open_files | 300 |
| innodb_purge_batch_size | 20 |
| innodb_purge_threads | 0 |
| innodb_random_read_ahead | OFF |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | OFF |
| innodb_rollback_segments | 128 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | ON |
| innodb_stats_sample_pages | 8 |
| innodb_strict_mode | OFF |
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_native_aio | OFF |
| innodb_use_sys_malloc | ON |
| innodb_version | 1.1.8 |
| innodb_write_io_threads | 4 |
+---------------------------------+------------------------+
59 rows in set (0.01 sec)
最後に、iotop を見ると、ディスクの使用率は約 1% で推移しているため、mySQL はほとんどの場合、システム メモリ内/システム メモリでのみ動作し、ディスクをスラッシングしないと思います。これでRAMとSSDがボトルネックから除外され、CPUだけが残ると思います。
しかし、新しい CPU に投資する前に、その他の意見をお聞きしたいと思います。本当にCPUがボトルネック？はいの場合、使用率が 100% を大幅に下回っているのはなぜですか?