Linux管理・運用の基本

Linuxサーバーの運用で、サービスのパフォーマンスは常に課題となります。特にWebサーバーやデータベースサーバーは、多くのユーザーからアクセスされるため、少しの遅延が大きな問題につながることがあります。この記事では、Webサーバー（Apache/Nginx）とデータベースサーバー（MySQL/PostgreSQL）の基本的なチューニングポイントと、パフォーマンスを向上させるためのヒントを解説します。

• ApacheとNginxのチューニングにおける同時接続数とキャッシュの最適化方法
• MySQLとPostgreSQLのメモリ、クエリ最適化（実行計画）、ログの調整ポイント
• Webサーバーとデータベースサーバーのパフォーマンスを改善するための実践的なヒント

Webサーバーのチューニングでは、主に同時接続数とキャッシュの設定が重要です。これらを適切に設定することで、サーバーの応答性を高め、リソースの無駄な消費を抑えることができます。

Apache

Apacheのチューニングは、主にMPM (Multi-Processing Modules) の設定に依存します。MPMは、クライアントからのリクエストをどのように処理するかを決定します。

どのMPMを使用しているかは、以下のコマンドで確認できます。

apachectl -V | grep MPM # または apache2ctl -V

Apacheの同時接続数とメモリの最適化

設定ファイルはディストリビューションによって異なりますが、主に/etc/httpd/conf/httpd.conf（CentOS系）や/etc/apache2/mods-available/mpm_*.conf（Ubuntu系）を編集します。設定ファイルを変更する際は、念のためバックアップを取っておくと安心です。

# 例: CentOS/RHELの場合
sudo cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak

※ MPMによって調整項目名が異なります。prefork では MinSpareServers と MaxSpareServers を調整しますが、worker や event では MinSpareThreads や MaxSpareThreads を調整します。

設定変更後の反映方法

設定ファイルを変更したら、以下のコマンドで設定を反映させます。文法チェックも同時に行えます。

sudo apachectl -t # または sudo apache2ctl -t
sudo systemctl reload httpd # または sudo systemctl reload apache2

Nginx

Nginxは、そのアーキテクチャ上、Apacheよりも効率的に多数の同時接続を処理できます。主なチューニングポイントはnginx.confの設定です。

Nginxの同時接続数チューニング

• worker_processes: 実行するワーカープロセス数。autoと設定すると、自動でCPUコア数に合わせます。物理CPUコア数（nprocコマンドの出力）と同じ値が基本です。多くしすぎても、タスク切り替えのオーバーヘッドが増えるため、効果は薄いでしょう。
• worker_connections: 1つのワーカープロセスが扱える最大接続数。全体の最大同時接続数は、worker_processes × worker_connections で計算できます。ただし、proxy_passなどリバースプロキシとして使う場合は、1クライアントにつき最大2接続（クライアント-Nginx間とNginx-上流サーバー間）を使う点に注意が必要です。

Nginxでのキャッシュ設定例と効果

静的コンテンツ（画像、CSS、JSなど）のキャッシュ設定は非常に効果的です。nginx.confの編集例は以下のようになります。

# main コンテキスト
worker_processes auto;
worker_rlimit_nofile 100000;   # FD上限の緩和はここ

events {
    worker_connections 4096;   # events ブロックで設定
}

http {
    server {
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            expires 30d;
            access_log off;    # アクセスログのみ無効化します
        }
    }
}

この設定により、指定されたファイルのアクセスログを無効化することで、ディスクI/Oを削減し、パフォーマンス向上に大きく貢献します。さらに、クライアントのブラウザに30日間キャッシュさせることで、2回目以降のアクセス時にサーバーへのリクエストを減らし、応答速度が劇的に改善します。

設定変更後の反映方法

worker_rlimit_nofileなど、systemd経由で起動するサービスの上限を変更する場合は、以下の手順が確実です。

# systemdの設定ファイルを作成・編集
sudo systemctl edit nginx
# [Service]セクションに以下を追記
# LimitNOFILE=100000
# 設定をリロードし、サービスを再起動
sudo systemctl daemon-reload
sudo systemctl restart nginx

その他の変更であれば、以下のコマンドで反映できます。

sudo nginx -t
sudo systemctl reload nginx

データベースのパフォーマンスチューニングは、主にメモリ割り当て、キャッシュ、そしてクエリ最適化が鍵となります。

MySQL

MySQLのパフォーマンスを左右する主要な設定はmy.cnfにあります。

• innodb_buffer_pool_size: InnoDBのデータやインデックスをキャッシュするためのメモリ領域です。ここを増やすだけで、ディスクI/Oが大幅に減り、レスポンスが改善されることが多いです。
• key_buffer_size: MyISAMエンジンのインデックスをキャッシュする領域。
• max_connections: 同時接続できる最大クライアント数。多すぎるとメモリを消費し、サーバーが不安定になることがあります。

現在の設定値は、MySQLのプロンプトで確認できます。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

⚠️注意点：innodb_buffer_pool_size は（DB専用サーバーなら）物理メモリの 60〜75%程度 を目安に設定します。一方で max_connections はメモリ割合では決めません。1接続あたりのメモリ使用量 × max_connections + グローバル領域 が物理メモリ内に収まるよう、ワークロードに合わせて見積もりましょう。メモリを割り当てすぎると、OSのスワップが発生し、かえって処理が遅くなる「スワップ地獄」に陥ることがあります。

クエリの最適化にはEXPLAINコマンドが非常に有効です。

EXPLAIN SELECT * FROM users WHERE username = 'testuser';

この結果を見ることで、インデックスが使われているか、無駄な全件スキャンが発生していないかなどを確認できます。

PostgreSQL

PostgreSQLのチューニングはpostgresql.confで行います。

• shared_buffers: PostgreSQLが共有して利用するメモリ領域。システムメモリの25%程度が推奨されます。
• effective_cache_size: OSのページキャッシュを含めた、PostgreSQLが利用できると期待するメモリの総量。ここを適切に設定すると、プランナーがより良い実行計画を立てやすくなります。

設定変更の効果を確認するためには、ベンチマークツールを使うのが有効です。

• Webサーバー向け
  • ab (Apache Bench): Webサーバーに負荷をかけ、リクエストの処理速度を測定します。Debian/Ubuntu系では apache2-utils、RHEL系では httpd-tools パッケージに含まれています。
  • wrk: よりモダンで、多数のコネクションを生成して高負荷なテストが可能です。
• データベース向け
  • sysbench: CPU、メモリ、ディスクI/Oなど、さまざまなシステムリソースのベンチマークが可能です。
  • pgbench: PostgreSQLに付属するベンチマークツールで、シンプルなトランザクション処理の速度を測定します。

これらのツールを使って変更前と変更後のパフォーマンスを比較することで、チューニングの効果を定量的に把握できます。

Webサーバーとデータベースサーバーのパフォーマンスチューニングは、サーバーの安定稼働に不可欠です。Apache/Nginxのチューニングは、同時接続数と静的コンテンツのキャッシュを意識し、MySQL/PostgreSQLでは、メモリ割り当てとクエリの最適化が肝心です。ただし、“リソースは余裕を持って”を意識しましょう。適切な値を判断するために、ベンチマークツールを活用するのがお勧めです。

この記事が、あなたのLinuxサーバー運用の現場で“少しでも”役立てば幸いです。ご覧いただきありがとうございました。