1つの高負荷リソースの開発と最適化の歴史





はじめに


それはすべて、私が州のインターネットサービスプロバイダーのシステム管理者になったことから始まりました。 さまざまな種類のリソースを管理することに加えて、私は若くて急速に成長しているリソースを1つ手に入れました。 リソースは古典的なLAMPプロジェクトでした。 コンテンツジェネレーターが通常のユーザーであるサイト。

*ところで、その時点では、nixシステムでは何も理解していませんでしたが、取得したすべてのサーバーはその上にありましたが、それについては十分に早く知っていました。



通常、リソースが人気を得ているように、すべてが回転している腺は対処しなくなります。 リソースは、ユーザー向けのほぼすべてのサービスが実行されていた古いデュアルプロセッササーバー上にありました。 当時、当局はこの資源を投資価値のあるものとは認識していなかったため、残念なことに(そして幸いなことに)新しい鉄片にお金を割り当てませんでした。





nginx + php-fpm


Googleが助けになりました。 結局のところ、高負荷のプロジェクトでは、人々はphpをfast-cgiモードで使用します。 この体制を実装するためのいくつかのスキームがあることが判明しましたが、最終的には、ロシアの開発、 nginx (Igor Sysoev)とphp- fpm(Andrey Nigmatulin)の束が優先されました。 Apacheおよびそのmod_phpと比較してパフォーマンスが向上するのは、php-fpmがn個のphpプロセスを作成し、その後システムでハングし、Webサーバーから転送されたスクリプトを処理するためです。 このスキームでは、PHPインタープリターを呼び出す際の時間とシステムリソースが節約されます。 私がspawn-fcgi c lighttpdを選択しなかった理由を尋ねないでください。このトピックでholivarovを開始したくありません。それは重要ではありません。 システムのパフォーマンスは向上し、負荷は落ち着きました。しばらくの間、私は安reliefのため息をつきました。



eAccelerator


高性能に向けた次のステップは、PHPアクセラレータをインストールすることです。 彼の仕事の本質は、スクリプトのバイナリコードをキャッシュすることです。 実際、呼び出しごとにスクリプトをバイナリコードに変換する貴重なプロセッサ時間を無駄にするのはなぜですか? 同じスクリプトを毎秒最大100回呼び出すことができるため、 eAccelerator役に立ちました。 それをインストールした後、システムのパフォーマンスが再び向上し、負荷がかなり低下し、ページ生成時間が急激に減少し、ユーザーは再び加速されたリソースに満足し始めました。



MySQLインデックスの


会社で働く前に、私はphpに手を出していたので、リソースコードを非常によく知っていて、それが必要な理由と理由を理解していましたが、どのコードでもボトルネックがあることを理解し、それらの検索を開始することにしました。 PHPランタイムとSQLクエリランタイムをカウントするプロジェクトにタイマーを追加すると、すぐにボトルネックが見つかりました。 リソースは1つのオープンソースCMSに基づいており、コードから判断すると、開発者の一部はMySQLのインデックスについて何も考えていませんでした。 さて、長いクエリの拡張と問題のあるクエリのリワークが始まり、本当に必要な場所にインデックスを追加しました。 EXPLAINは数日間私の仲間になりました。 その結果、場所でのSQLクエリの実行時間は10〜20倍に短縮され、親愛なるユーザーにとって幸せな日が再び始まりました。



Memcached


棚に荷物が戻ってくるまでに、当局はすでにリソースに本格的なサーバーを割り当てていました。 しかし、私はすでにスポーツに興味を持っています。 ページ生成時間が2秒から0.5秒に短縮されると、非常に刺激を受けますが、もっと欲しいと思いました。 重いSQLクエリを完全に取り除き、重要な最小限のものだけを残したかったのです。 オープンスペースをサーフィンすると、Andrei Smirnovのレポートに出くわしました:「Web、キャッシング、memcached」(HighLoad ++ 2008でのプレゼンテーション)。 確かに、これはあなたが必要とするものです! Memcached-livejournal.comのために一度に開発された、最もシンプルで同時に高性能なキャッシュサーバーは、私のスキームに完全に適合します。 残念なことに、memcacheを最大限に使用することは、私には不可能と思われました。私の仕事はこのWebリソースに限定されず、それでも多くのことが行われたからです。 memcachedを使用して、SQLクエリの結果をキャッシュしたり、既製のレンダリングブロックを保存したりしました。 サイトの多くのページで、それらの生成時間は非常に小さな数-0.009秒に短縮されました! これは史上最大の発見と成果でした。



SysctlおよびUNIXソケット


リソースの品質をめぐる闘争で重要ではないもう1つの瞬間は、 sysctlのチューニングです。 高負荷の場合、デフォルトの構成では多くのことが望まれます。 ネットワークサブシステムの最適なパラメータを見つけるのに数週間かかりました。 また、可能であれば、php-fpm、memcached、MySQLはunix-socketsでハングしました。 その結果、負荷がピークのとき、サーバーは負荷なしでコンテンツを配信します。



スフィンクス


キャッシングをマスターする頃には、他の速度を上げることは可能だろうと思っていました。 当然! 検索は最も弱いサイトでした。 なぜだと思う? そう! ひどい悪がありました-SQLクエリでのように。 その後、 Sphinx検索エンジンが助けになりました! 残念ながら、私の場合、サフィン(検索中のツールチップ)にのみSphinxを使用することが判明しました。 メインのsqlテーブルの更新は非常に頻繁に行われ、データの関連性は非常に重要だったため、それを放棄しなければなりませんでした。 ただし、この点を詳細に分析する時間があれば、おそらくこの問題に対処できた可能性があり、Sphinxはサービスの開発におけるもう1つの重要なポイントになるでしょう。



MySQLからtmpfs


すべてのチューニングと最適化から多くの時間が経過しました。 リソースは会社にとって重要になり、そのサポートにお金が割り当てられ、2つのサーバーが既にそれを提供していました。 最初はWebサーバーとして機能し、phpを処理し、2番目はMySQLで使用されました。 しかし、開発は止まっておらず、リソースは毎秒600コールに達し、リソースの両方の部分が対処しなくなりました。 PHPレベルとMySQLレベルの両方のプラグイン。 3番目のサーバーを受け取った後、そのスケーリングについて疑問が生じましたが、理想的なオプションを考えることができませんでした。 そして、ハブのページでtmpfsのMySQLに関するトピックを見ました。 そして、なぜだと思いました。 基地との準備作業を行いました。 重要ではないが「食いしん坊」の機能を削除することで、可能な限りDBを削減しました。 データベースの一部のログ機能を削除しました。 最終的に、データベースの重量は11 GBから2.5 GBに削減されました。 そのため、phpで2台のサーバーを使用し、3回目にはドーピングを使用してMySQLを起動することにしました。 標準のmysqlhotcopyユーティリティはバックアップをうまく処理します(1.5秒で完了です!)。 そうしました。 MySQLの負荷は4倍減少し、生産性も向上しました。



おわりに


なぜ私はこれをすべて伝えることにしたのですか? おそらく、この記事は、同様の問題に直面している特定の人々にとって興味深いものになるでしょう。 私の時間に似たようなものを見つけたなら、それは私を大いに助けたでしょう。 別のリソースが大幅に変更されます。 すべてが書き換えられ、コンテンツとユーザー以外の古いものは何も残りません。 私にとっては、すべての開発の日没が見えますが、それらのおかげで私は膨大な経験を積んでおり、経験は非常に貴重です。 そして、この記事は、私がかつてやったことの記憶になります。



仕事の過程で、私の同僚( CentAlt )が私を大いに助けてくれました。彼はあらゆる方法であらゆる面で私を支えてくれました。 ところで、多分あなたの何人かは彼を知っています。 nginx、php-fpm、unbound、clamav、postfix、dovecotなどの最新バージョンを見つけることができる非常に便利なCentosリポジトリを 1つ保持しています。



この記事は、優れているまたは人気があると主張していません。 これは、実行方法または実行すべきでない方法に関する指示ではありません。 これは、私がたまたま開発して管理していた、非常に負荷の高いプロジェクトの話です。



最後まで読んでくれてありがとう!



All Articles