DiPHOST.Ruの負荷との戦い。 サクセスストーリー

そのままの負荷とリソース。

1年前、負荷について退屈なレポートを作成しました。http ： //vimeo.com/7631344で確認できます。

その主な規定を簡単に説明します。

• プロビジョニング戦略に従って、リソースを保証および共有できます。 それらの間にホリバーはありません-それらはそのようなものです。 独自の特性を備えています。
• リソースは機能別に分割する必要があります。 機能の意味で分離された完全に選択されたサービスほど、リソース制御への対処が容易になります。 「束」を使用すると、理解するのが常に難しくなります。
• 共有リソースは完全なパフォーマンスで実行する必要があります。 リソースを「減速」することはできません。 「エントリポイント」を最適に選択し、それだけに制限する必要があります。

問題。

このケースでは、共有リソースを使用した仮想UNIXホスティングを検討しています。 つまり 1つのサーバーまたはサーバーのグループ上の多くの異なるサイト。



共有ホスティングの最も顕著な問題の1つは、制御できない、正式ではない出席、特に急激なジャンプです。 その結果、Webサーバーへの接続が定期的に爆発的に増加し、結果としてデータベースやディスクに負荷がかかり、理由の合計による結果の出力が遅くなります。 フィードバック-処理が遅くなるため、Webサーバーへの接続が増加しました。



90％のケースで、これはさまざまなロボット、白いロボット（Yandex、Googleなど）と灰色のロボット（他のインデックスサービス-sape、linkfeedなど）、さらには（ああ、なんてこった！） 「-コンテンツを盗むロボット。 ブラックロボットは通常、「一度に」コンテンツをプルしようとするため、多数の同時ストリームでサイトにアクセスするため、かなりの問題が発生します。



ほとんどすべてのサイトへの接続の流入時にWebサーバーにアクセスしたい人のキューが増加しているという事実によって、状況はほとんど常に悪化します。 「犯人」が静かなときでも、解放されたリソースは蓄積された「キュー」を急激に占有しようとしています。 これは、いわゆる「うねり」につながります。 私の実践では、1つのサーバー（3つのサイト）に関してさえ、しばしば問題のあるケースがありました。



Webサーバーの前にシンプロキシ（nginxなど）をインストールすると、問題の多くの症状がなくなります。 問題自体は残っています。



データベースを別のマシンに「削除」すると、悪影響の順序が減りますが、それは除去されず、すべての場合において経済的に正当化されるわけではありません。



サイトページをキャッシュするオプションがあります。 しかし現実的に考えてみましょう-ほとんどの開発者は、開発の実行環境について何も知らず、知りたくないし、知りません。 5番目のサイトについては、キャッシュされているもの、キャッシュされていないもの、サイトの構造を変更したばかりのもの、またはその他のものを既に忘れています。

理論

明らかに、説明されている状況では、「エントリポイント」はWebサーバーへの接続であり、それを制限する必要があります。 問題はすぐに発生します-到着した「余分な」接続に対して「言いたい」ことは何ですか？ 503エラーや接続のリセットなど、彼に何かを「言う」と、最終的には不特定多数の訪問者が混oticとした「壊れた」サイトになります。 既製のソリューションの中で、nginxにはlimit_reqのみがあり、高バーストです。 しかし、問題が発生します-クエリ速度パラメーターを選択する方法？ もちろん、limit_connをlimit_reqからburstパラメーターに変更できます。 しかし、両方のソリューションには問題があります-「シンプロキシ」へのエントリポイントは限られています。



私たちの意見では、「シンプロキシ」のエントリポイントは最適な場所ではありません。 Apacheの既製のソリューションには共通の問題があります-それらは何かを返します。 理論的にも改良は不可能です。Apacheハンドラーに「許可」を待たせないことは、アイデアの全体を無効にします。

背景

mod_wsgiを介してPythonでアプリケーションをホストするためのサービスを提供します。 Apacheは、各サイトに対して、常にメモリ内にあるいくつかの特別なハンドラーを実行します。 そのようなサイトでの「流入」効果に特に気づいていないことに気付いたときの驚きは何でしたか（たとえば、 http：//twihoo.ruは、トラフィックは非常に大きいですが、サーバーの負荷に関しては最大ではありません！）。



よく見てください。 明らかです-ApacheはUnixソケット上のハンドラーと通信し、すべての「余分な」接続はそれらが処理されるのを待ちます。 その結果、不必要なジェスチャーをすることなく、時間とともに負荷が「広がり」ます。 この慣行により、記憶に常にあるユーザープロセスに対する宗教的な恐怖が大幅に減少し、解決策を探し始めました。

ユーレカ！

決定は完全に予想外に行われました。 私はパートナーのサーバーの構成に参加し、いくつかの個別に構成されたApache Webサーバーを提供したいと考えました。 FreeBSDパッケージコレクションのapache起動スクリプトを見て、突然「すぐに」そのような機会を提供することがわかりました。 パートナーのサイトはねじれがなく、訪問済みで、重いです。 パートナーは要求が厳しく、サイトの品質に完全に依存しています。 WSGIホスティングの経験を考慮すると、「戦闘中」の実験を行う誘惑が勝ちました。



「彼自身のアパッチへ」は非常に良い考えでした。 最近では、FreeBSDスケジューラはプロセスの数に依存していました（デフォルトはバージョン7.1）が、進歩的な企業として、新しいスケジューラでFreeBSDの新しいバージョンをすでに使用しています。 この実験では、3〜4個のApacheプロセスのリソースを使用して、「重い」サイトであっても非常に多くのトラフィックに耐えることができることが示されました。 このようなソリューションには、mod_peruserやmo​​d_itkなどの特殊なソリューションよりも多くの明らかな利点があります。これらのモジュールのスラーコードの欠如、Apacheモジュールの数を制御する機能、およびこれらのモジュールの特殊な設定を行う機能です。





これまでのところ、Dmitry Koterovによるわずかにやり直された非常に最初のパッチでホストするためにapache 1.3.xを使用しました-apacheは各リクエストに対してvfork（）を行い、リクエストを処理した後にsetgid（）およびsetuid（）-_exit（）を行いました 新しい方法により、これらの手順に費やされるCPU時間を節約できます。



しかし、マイナスがあります-常に占有メモリの量の要件。 最近の仮想メモリマシン、特にマッハOSから継承されたものは非常に複雑です。 実際に使用される物理メモリの量を事前に計算して見積もることはできません。



ちなみに、一部のロシアおよび一部の外国のホスティングプロバイダーは、専用のWebサーバーの同様のスキームを使用しています。 例：GridContainersサービスを使用するMediaTemple（ http://mediatemple.net/webhosting/gs/features/containers.php ）。 仮想化では真実はやや複雑ですが、一般的な考え方は似ています。

とげを通して星へ。

私たちはチャンスをつかむという強い意志を持っています。 1か月間、パネルに従って構成を構築し、変更に対応し、Webサーバーを起動および停止し、実行中の何百ものWebサーバーのステータスを自動的に監視し、ログをローテーションし、シンプロキシ-nginxの構成を変更するプログラムを作成しました。 同時に、再構成に関係するすべてのノードを組み合わせて最適化しました。



最初の失敗は... phpで待っていました。 Webサーバーの起動時間と、理論的にはランタイムのオーバーヘッドを減らすために、Apacheを使用してphp 5.2.xを静的にビルドしようとしました。 残念ながら、PHPビルドシステム内でトリッキーな編集を行わないと、これを行うことができませんでした。 時間をかけて適切に修正することができず、一時的に事業を放棄しなければなりませんでした。 ちなみに、希望する人がいる場合、この問題はLJで説明されています 。適切な方法（ community.livejournal.com/ru_root/1884339.html）を使用して解決することができます 。



しかし、最終的にシステムの準備ができました。 私たちはいくつかの「私たちの」サイトをそれに移しました。 結果は勇気づけられるものでした-3人のApacheハンドラーがdrupalの重いサイトに十分であり、ユニークな参加者は1200人まででした。 特別なテストとして、このサイトで小さな「dos-attack」を試みました（100リクエストで10,000リクエスト）-サイトの速度は低下しましたが、他のサイトの運用にはほとんど影響がありませんでした。 記憶の分布の顕著な変化を診断しませんでした。 また、新しいシステムに移行したホスティングサイトは、トップ出力にまったく表示されませんでした。 そして、3晩、他のすべてのサーバーを新しいシステムに喜んで移しました。 なぜ夜に？ 夜間にはサーバーが通常空であり、これにより、すべての変更が最も迅速かつ静かに行われるためです。



月曜日の朝が来ました...

完全な失敗。

サイトの数が最も少ないサーバーの動作は著しく改善されましたが、著しく遅くなりました。 OSのi386アーキテクチャを備えたサーバーでは、メモリ不足は診断されませんでしたが、突然mysqlがすべてのディスクアクセスを引き継ぎ、ほぼ麻痺させました。 最も強力なサーバーはギガバイトのスワップを行い、ディスクをほとんど麻痺させました。



「過負荷」サーバーのこの状態には利点があります。 ストレスの多い状況は、一般的にメンタルワークに貢献します。 mysqlで数百メガバイトの一時テーブルを作成するすべての人をすぐに捕まえ、1秒間に数百のデータベース更新を行ういくつかのサイトを捕まえました。 すべてのmysqlサーバー設定を完全に整理しました。 同時に、彼らはmytopユーティリティを修正しましたが、それは以前は手の届かないものでした： schors.livejournal.com/652161.html 。 しかし、具体的な改善をもたらすものはありませんでした。 ちょっとしたパニックの中で、Apacheログを書き込むための大きなバッファを作成しようとしました-頻繁に記録するためのバッファは一般的に便利です。 与えられた状況での実践では、結果はゼロです。



一日の終わりには、すべてをロールバックする準備を整えました。 しかし、ロールバックはポジションの放棄です。何が起こっているのかまだ理解していないからです。 これは、新しいシステムと問題の解決策がすぐに表示されないことを意味します。 もう少し時間がかかりました。 ほぼ1日がシステムの完全な診断とすべての可能なマニュアルとマニュアルの香に費やされました。



理論上の結果は当たり前であることが判明しました-結局のところ、十分なメモリがありません。 すべてのメモリがディスクスワップに入れられるとは限りません。他のツールを使用して十分なメモリがない場合（たとえば、一時テーブルとキャッシュを備えたmysql）、すべてのプログラムがこれを報告するわけではありません。 追加のRAMのコストを考慮して、機器のアップグレードをためらわないことにしました。 そして推測した。



メモリの2倍の増加がすべてです。 この後のすべてが奇妙に見えることに注意してください-最初は十分なメモリがないかもしれないことが明らかでした。 しかし、すべてが不明瞭でした。 何も欠けている可能性があります-スケジューラーが対処できなかった、プロセッサーが対処できなかった、十分なメモリがなかった、apacheハンドラーがなかった、バッファがなかった、ディスクがなかったかもしれません。 一般的に、後者は私たちを混乱させました。 メモリ使用率とディスクアクティビティを直接相関させるのではなく、プログラムがそれを使って何をするかに関わらず、「そのようなディスクをロードするもの」の問題を急いで解決しました。



そして、予想外に後ろで私たちを襲った... php。 Php 5.2.11、staticsによってコンパイルされ、突然gdモジュール（グラフィック）で正常に動作することを拒否しました。 さらに、彼は一般的に私たちが持っているライブラリのセクションで作業することを拒否しました。 眠れない夜のための魔法の方法により、動的にロードされた拡張機能を持つphpのみを稼働状態にすることができました。 この問題はwww.google.com/#hl=en&newwindow=1&q=gd-png+fatal+libpng+error+freebsd+imagecreatefrompng&lr=&aq=f&oq=&fp=7b635a504e075d30にあります。 これがどの依存関係にあるかを理解することはできませんでした。 問題は未解決です。

世界支配への道。

結果は素晴らしかった。 負荷を平準化しました。 「オウム」負荷平均のグラフを示します。 第44週のエリアでは、明らかに均等化された15分間の負荷がはっきりと見え（「ノール」が滑らかになっています）、これは週の終わりに機器のアップグレードにより予想通りに減少しました。





一定のvfork（）の拒否により、プロセッサ時間を獲得しました。 グラフは、CPUの使用が44週の初めに著しく減少したことを示しています。週の終わりに機器がアップグレードされた後、変更はあまり目立ちませんでした。





1つの質問が残っています-ユーザーごとに3つのApache Webサーバーハンドラーの制限でそれを上書きしましたか？ 平均して、病院では、各ユーザーが2つのサイトを配置します。 しかし、いくつかはしばしば10を持っています。 監視メッセージを注意深く監視します。 実行中の各Apacheについて、60秒のタイムアウトで接続を確認する必要があります。 そのため、サイトは正確に「レイアウト」されていると判断します。 もう2週間が過ぎました。 モニタリングは、個別のケースで計算されます。 特徴的なのは、文字通り何百ものクライアントのうちの3つです。 通常、これは何かを「ロック」したい非標準的な流入から、またはデータベースのバックアップ中に、またはサイトの更新プロセス中に犯したミスから発生します。



新しいシステムは私たちに嬉しい驚きをもたらしました。 「正直なトップ」を獲得しました。 一番上のプログラムには、システム内のプロセスが表示されます。デフォルトでは、奇妙なパラメーター（プロセッサー使用率のパーセンテージ）でプロセスがソートされています。 これは、かなり複雑な推定アルゴリズムを使用してカーネルによって一定期間にわたって計算され、実際には純粋なパーセンテージではありません。 1つのWebサーバープロセスが異なるユーザーのサイトへの接続を処理できる場合、プロセスの最後の使用の「残留」割合が表示されます。 vfork（）を実行する場合、通常、調査に参加できるプロセスのみが表示されます。 新しいシステムでは、これは明らかに起こりません。 最上部に表示されるこれらのプロセスは、実際に最も要求の厳しいリソースです。



そのため、新しいものに対する潜在意識の恐怖を乗り越え、完全に機能するホスティングアーキテクチャよりもやや少ないものをやり直し、「月曜日の効果」を取り除きました。