17

私はubuntu-serverとかなり高負荷のウェブサイトを持っています。サーバーは次のとおりです。

  • nginx 専用、php-fpm (Apache なし) を使用、mysql は別のマシンに配置
  • 8GBのRAMを搭載
  • 1 秒あたり約 2000 のリクエストを取得します。

topコマンドによると、各 php-fpm プロセスは約 65MB の RAM を消費します。

トップコマンド

空きメモリ:

admin@myserver:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          7910       7156        753          0        284       2502
-/+ buffers/cache:       4369       3540
Swap:         8099          0       8099

問題

最近、パフォーマンスに大きな問題が発生しています。応答時間が非常に長く、非常に多くGateway Timeouts、夜間に負荷が高くなると、ユーザーの 90% が Web サイトではなく「サーバーが見つかりません」と表示されます (これを再現できないようです)。


ログ

私のNginxエラーログは、以下のメッセージでいっぱいです:

2012/07/18 20:36:48 [error] 3451#0: *241904 upstream prematurely closed connection while reading response header from upstream, client: 178.49.30.245, server: example.net, request: request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "example.net", referrer: "http://example.net/articles"

UNIXソケットに切り替えてみましたが、それでもエラーが発生します:

2012/07/18 19:27:30 [crit] 2275#0: *12334 connect() to unix:/tmp/fastcgi.sock failed (2: No such file or directory) while connecting to upstream, client: 84.
237.189.45, server: example.net, request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://unix:/tmp/fastcgi.sock:", host: "example.net", referrer: "http
://example.net/articles"

そして php-fpm ログはこれらでいっぱいです:

[18-Jul-2012 19:23:34] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there  are 0 idle, and 75 total children

指定されたパラメータを まで増やしてみました100が、まだ十分ではないようです。


設定

これが私の現在の構成です

php-fpm

listen = 127.0.0.1:9001
listen.backlog = 4096
pm = dynamic
pm.max_children = 130
pm.start_servers = 40
pm.min_spare_servers = 10
pm.max_spare_servers = 40
pm.max_requests = 100

nginx

worker_processes  4;
worker_rlimit_nofile 8192;
worker_priority 0;
worker_cpu_affinity 0001 0010 0100 1000;

error_log  /var/log/nginx_errors.log;

events {
    multi_accept off;
    worker_connections  4096;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    access_log off;
    sendfile        on;
    keepalive_timeout  65;
    gzip  on;

    # fastcgi parameters
    fastcgi_connect_timeout 120;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 1000;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_intercept_errors on;

    client_max_body_size 128M;

    server {
        server_name example.net;
        root /var/www/example/httpdocs;
        index index.php;
        charset utf-8;
        error_log /var/www/example/nginx_error.log;

        error_page 502 504 = /gateway_timeout.html;

        # rewrite rule
        location / {
            if (!-e $request_filename) {
                rewrite ^(.*)$ /index.php?path=$1 last;
            }
        }
        location ~* \.php {
            fastcgi_pass 127.0.0.1:9001;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            include fastcgi_params;
        }
    }
}

問題を特定する方法と、これを修正するために調整できるパラメーターについてアドバイスをいただければ幸いです。それとも、この種の負荷には 8GB の RAM では不十分なのでしょうか?

4

5 に答える 5

1

いくつかの問題。このような忙しいサイトでそれらを修正する価値はまだあります. 今のところ、MySQL が根本的な原因である可能性があります。しかし、長期的には、より多くの作業を行う必要があります。

キャッシング

php アップストリームへの get リクエストを示すエラー メッセージの 1 つが表示されます。これは、トラフィックの多いサイト (前述のように 2000 r/s) では見栄えがよくありません。このページ (/readarticle/121430) は、完全にキャッシュ可能なページのようです。1 つには、そのようなページをキャッシュするために nginx を使用できます。fastcgi キャッシュを確認する

GET /readarticle/121430

php-fpm

pm.max_requests = 100

この値は、100 件のリクエストを処理した後、プロセスが php-fpm マスターによって強制終了されることを意味します。php-fpm はその値を使用して、サードパーティのメモリ リークに対処します。あなたのサイトは非常にビジーで、2000r/s です。子プロセスの最大数は 130 で、それぞれが最大 100 のリクエストしか処理できません。つまり、13000/2000 = 6.5 秒後にすべてがリサイクルされることになります。これは多すぎます (毎秒 20 プロセスが強制終了されます)。少なくとも 1000 の値から始めて、メモリ リークが発生しない限り、その数を増やす必要があります。誰かが本番環境で 10,000 を使用しています。

nginx.conf

  • 問題 1:

        if (!-e $request_filename) {
            rewrite ^(.*)$ /index.php?path=$1 last;
        }
    

    より効率的な try_files に置き換える必要があります。

        try_files $uri /index.php?path=$uri;
    

ロケーション ブロックと正規表現書き換えルールが一致する場合は、余分に節約できます。

  • 問題 2: unix ソケットを使用すると、ip を使用するよりも時間を節約できます (私の経験では約 10 ~ 20%)。そのため、php-fpm はこれをデフォルトとして使用しています。

  • 問題 3: nginx と php-fpm 間のキープアライブ接続の設定に関心があるかもしれません。例はnginxの公式サイトにあります

于 2013-03-19T05:02:49.827 に答える
1

nginx マイクロキャッシュの設定も役立ちます。これは、数秒間同じ応答を提供します。

http://seravo.fi/2013/optimizing-web-server-performance-with-nginx-and-php には、nginx のパフォーマンスに関する良い情報があります。個人的にはそれに従いましたが、とても満足しています。

于 2013-06-13T12:08:07.013 に答える
1

php.ini の設定を確認する必要がありますが、ソケット エラーが発生しているように見えるので、これは MySQL に関連しているとは思いません。また、これは一定期間後に発生し始めるものですか、それともサーバーが再起動するとすぐに発生しますか?

php5-fpm デーモンを再起動して、エラー ログの追跡中に何が起こるかを確認してください。

php.ini ファイルと、通常は /etc/nginx/fastcgi_params にあるすべての fastcgi_params を確認してください。あなたがやろうとしていることの例はたくさんあります。

また、apc php キャッシュ拡張機能を有効にしていますか?

ランプ スタックの場合、php.ini ファイルでは次のようになります。

extension=apc.so
....
apc.enabled=0

コマンド ラインから mysql 接続の負荷テストを行って、その結果を確認しても問題はないでしょう。

于 2013-03-19T22:55:54.460 に答える
0

この質問に対する答えを得るために:

You should check your MySQL server. Probably it's overloaded or it limits count of parallel MySQL connections. You should find the bottleneck. And according to your top screenshot it doesn't look like either RAM or CPU, then it's most likely I/O.- @VBrat

将来やりたいこと:

1- RAM サイズを増やします。

2-キャッシュを使用します。キャッシュがサイトを高速化する方法については、この記事を参照してください

3-実行されるクエリの数を減らします。

于 2013-03-18T23:27:25.760 に答える
0
  • PHP 用の APC エクステンションのセットアップ (チェック/構成)
  • MySQL - 構成、インデックス、遅いクエリを確認する
  • Varnish をインストールして構成します。これにより、ページ リクエストがキャッシュされ、作成する必要がある php リクエストと mysql クエリの量を減らすのに非常に役立ちます。cookie/ssl を使用する場合は注意が必要ですが、それ以外はそれほど難しくなく、実行する価値があります。
于 2013-04-05T02:22:15.543 に答える