web-dev-qa-db-ja.com

wordpress 404リクエストのために非常に高いSQLCPU

私はWordpressサイトをNginx、MariaDB、PHP-FPMで実行していて、多くのIPからのさまざまな404リクエスト（ランダムなURLをリクエストする1時間あたり約10.000の異なるIP）に襲われています。その結果、SQLの負荷が非常に高くなり、ランダムなダウンタイムが発生します）。

メインサーバーを別のNginxサーバーの背後に配置して、サイトのリバースプロキシキャッシングを実行して負荷を軽減しようとしましたが、404リクエストがNginxプロキシキャッシングサーバーを通過するため、メインサーバーの負荷は依然として非常に高くなります。

MYSQLDがすべてのCPUを使用して処理を行うため、サーバーで5XXエラーが発生し、PHP-FPMが不足し、Nginxの要求に応答しなくなったと思いますか？

エラーログにこれがたくさんあります：

2017/05/13 03:48:40 [error] 24894#24894: *2936187 upstream timed out (110: Connection timed out) while connecting to upstream

私のサーバーは16コア、64GB RAM、Ubuntu17.04を実行する200GBSSDディスク、MYSQLDは常にすべてのCPUを可能な限り使用しています。

私のメインサーバーのNginx構成：

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 2048;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    client_max_body_size 32M;
    disable_symlinks off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    gzip off;

    ### START SERVER CONFIG
    server {
        listen 80 default_server;
        root /var/www/html;

        index index.php index.html index.htm;

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        server_name _;

        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
            include snippets/fastcgi-php.conf;
            fastcgi_pass 127.0.0.1:9000;
        }

        location ~ /\.ht {
            deny all;
        }
    }
    ### END OF SERVER CONFIG
}

PHP-FPM構成：

[www]
user = www-data
group = www-data
listen = 127.0.0.1:9000
listen.owner = www-data
listen.group = www-data
listen.allowed_clients = 127.0.0.1
process.priority = -10
pm = dynamic
pm.max_children = 64
pm.start_servers = 32
pm.min_spare_servers = 2
pm.max_spare_servers = 32

どういうわけか状況を改善することができますか？私が言ったように、すべてのリクエストは非常に正当なリクエストで異なるURLをリクエストする多くの異なるIPから来ているので（ヘッダーはブラウザとまったく同じように見えます）、それをブロックするファイアウォールルールを作成することはできませんが、私はそれらを知っています自動化されたリクエストを再作成します。これは、IA64アーキテクチャからのものであると言っているユーザーエージェントがいるためです。これは、私の訪問者の誰もが持っている方法ではありません。

いいえ、何らかの理由で自動リクエストを防ぐためにCloudflareまたは同様のサービスを使用することはできません...したがって、JavaScriptまたは同様の方法をテストして、実際のブラウザの負荷であるかボットであるかを検出するNginxプラグインはありますか？地点？

nginxmysqlphp-fpmwordpress
1
minhng99

最初は、入ってくるリクエストを調べます。それらは本当に攻撃ですか、それともアプリケーションに多くの壊れたリンクがありますか？あなたが原因を修正することができれば、それは常により良いです。

Fail2Banも私がお勧めするものですが、すべてのIPが1つのリクエストだけを実行する場合はあまり効果がありません。

とにかく、Wordpress/PHP/MySQLに到達するために404を避けたいと思うでしょう。一致できるリクエストにパターンがある場合、ウェブサーバーがそれを処理できます。明確なパターンがない場合、それはよりトリッキーですが、それでも行うことができます。

MySQLに関するこれらの手順は、Nginxに適合させることができます。

https://www.pipeten.info/2015/10/better-handling-wordpress-404-errors/

しかし、さらに良いのはRepsheetです。

https://getrepsheet.com/

リクエストが必要かどうかを判断し、別の方法で処理するのに役立ちます。ランダムな404を実行するこれらのIPは、明らかに通常のユーザーの動作を模倣していません。 Repsheetはある程度の学習の後でそれを知ることができ、それが完全なWebスタックに到達する前に404または403をディッシュすることができます。

RepsheetにはNginx用のモジュールがあります： https://github.com/repsheet/repsheet-nginx

逆に、実際の（リピート）ユーザーを優れたアクターとして認識するようになり、ルールを設定してそれらに優先順位を付けることができます。

最後に、ほとんどのHTTPボットは非常に愚かなので、NginxのTest Cookie Moduleを使用して、これが真のユーザーエージェントであるかどうかをテストできます。

https://github.com/kyprizel/testcookie-nginx-module

（ただし、Googleのような優れたボットをブロックする場合は注意が必要です。SEOを強制終了しないでください。ホワイトリストに登録してください！）

0
JayMcTee