サーバーのメンテナンスにおける同時実行性の高さの処理によって発生するいくつかの一般的な問題を解決する方法

ここではシナリオでいきましょう、結局のところ、実用性を体験するにはシナリオが一番です。まず、サーバーの構成と環境について説明します

Alibaba Cloud ECS クラウド ホスト、8G メモリ、4 コア CPU、20M 帯域幅、20G システム ディスク + 200G データ ディスク、CentOS 6.564 ビット、統合 lnmp 環境をインストール

シナリオ: 送信WeChat の赤い封筒

このシナリオは非常に一般的で、現時点では、顧客は WeChat 公式アカウントに広告をプッシュします。この時点でのサーバーの同時実行数は約 3000 ～ 5000 です。そういえば、これは実際には高い同時実行性とはみなされていませんが、それでもサーバーがクラッシュし、通常に戻るまでに約 5 分かかりました。これは少し不適切です。その理由を分析してみましょう。 CPU 使用率は高くなく、メモリ使用量は正常です。Alibaba Cloud コントロール パネルでは、ネットワークの送信トラフィックがいっぱいであることが問題の原因であると考えられます。

まず、静的リソースを確認したところ、ほとんどの写真が最適化されていないことが判明したので、それらを削除して、おそらくサイズが約 1M 省略されたと考えられますが、送信後もクラッシュし、サーバーは頻繁に 502 を表示しました。 。

ページの静的リソースのcssとjsを再度確認し、リクエスト数を減らすためによく使うjsライブラリをCDNに置き換えると、送信後もあまり変化はなく、502のままです。

そこで、nginx 接続の数を確認し、コマンド

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

を使用します。結果は、

TIME_WAIT 3828SYN_SENT 1FIN_WAIT1 107FIN_WAIT2 27ESTABLISHED 661SYN_RECV 23CLOSING 15LAST_ACK 284

を示します。良い子、TIME_WAITE は非常に高いです。 ここで TIME_WAITE の意味について必ず話してください。 TIME_WAIT: 反対側。リリースを初期化しました。これはどういう意味ですか？これは、サーバーがアクティブにシャットダウンされており、クライアントからの応答を待っていることを意味します。クライアントが応答しない場合、待機が発生し、この値が増加します。明らかに、この時点で TIME_WAIT の値を減らす必要があります。

ここでは、sysctl.conf の一部のパラメータを変更するだけです。/etc/sysctl.conf ファイルを編集して、該当する設定になっているかどうかを確認してください。

対応するものが見つからない場合は、最後に追加するだけです。ファイル。保存後、

/sbin/sysctl -p

設定を実行して有効にします。

20 分後も nginx 接続数を確認し続けます。結果

TIME_WAIT 87SYN_SENT 1FIN_WAIT1 60FIN_WAIT2 19ESTABLISHED 477SYN_RECV 12CLOSING 2LAST_ACK 100

は正常に戻り、ネットワーク帯域幅も低下しました。

しかし、楽しい時間は長くは続きませんでした。2時間目に赤い封筒を掴み始めたとき、502が再び現れました。プロセスをチェックすると、mysqld の CPU 使用率が非常に高く、CPU が完全に負荷され、サーバーがクラッシュすることがわかりました。 mysql 設定ファイルを変更し、max_connection を 30000 に調整します。他の関連パラメータが調整および最適化され、状況は緩和されましたが、数分以内に CPU に再び完全な負荷がかかりました。

変だ！そこでmysqlで処理を確認したところ、頻繁にSQLクエリが発生しており、クエリされた複数のテーブルのデータ量が10万程度になっていたのは、インデックスが設定されていないことが原因であると判断されました。バックエンド開発に相談したところ、主キーのみが設定されていることが判明しました。すぐに修正してください。送信してから 5 分後には CPU が低下し、10% 程度で安定し、502 は表示されなくなりました。

以上がサーバーのメンテナンスにおける同時実行性の高さの処理によって発生するいくつかの一般的な問題を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。