単一サーバーのセットアップから拡張する方法

サーバーのセットアップを拡大する方法に関するリソースを探しています。

現在、英国にはラックスペースを備えた次の仕様の専用サーバーが1台あります。

HPDL385_G2_PrevGen
HPシングルデュアルコアOpteron 2214（2.2Ghz）
4GB RAM
2x 10,000 SCSIドライブ（RAID 1）

私たちのトラフィックは1か月あたり最大550,000 UVです。

このサイトは、PHPとMySQLのセットアップで実行されます。データベースは完全に破壊され、複数のテーブルを結合する多くの複雑なクエリがあります。

PHPキャッシングにはAPCを使用しています。

私はできる限り多くのDBとクエリの最適化を行った段階になり、次のステップはどうあるべきかと思います……

memcacheを確認しましたが、彼は大量のRAMと理想的には専用のボックスを必要とする印象を受けました。

2つのボックスを作成する次のステップも同様です。1つはデータベース用、もう1つはApache用ですか？または私が見落とした一歩はありますか。

負荷は通常2マーク前後ですが、現在は20です。

Muninのグラフの一部：

ハードウェアをいくつか購入しますが、データセンターではなくテストラボに配置します。次に、アプリケーションをさまざまなハードウェア/ソフトウェアの組み合わせで強調し、必要なことを実行する適切な組み合わせが見つかるまで待ちます。

もちろん、アプリのテストコピーを実行しているプロダクションのようなデータベースに対して偽のトラフィックを作成できるものを設計する必要があります。しかし、それは簡単だろうと誰が言った。

これを行わず、単に本番環境でいくつかのことを行う場合、それが機能するかどうかわからないため、キャッシュなどの実装にかなりのエンジニアリング作業を費やしている可能性があります（フェアシェアが付属します）。バグの！）助けにならない何かについて。

テスト、テスト、さらにテスト。問題を大幅に改善する可能性が高いことを示す優れたパフォーマンスデータが得られるまで、ハードウェア/ソフトウェアの変更を運用環境に投入しないでください。エンジニアリング作業は高価ですが、テストハードウェアは（特に）高価ではありません。

Memcachedは1つのオプションに過ぎず、データベースのキャッシングが最適に機能するようになるまで、それを考慮する必要はないでしょう。これは、妥当な量のRAM（4Gではなく、現在のラップトップにはそれがあり、32Gは間違いなく手頃な価格です）を備えた専用（もちろん64ビット）ボックスに置き、適切に調整することを意味します。

データベースの大きさについては言及していませんが、それが可能であれば、完全にRAM（または少なくともホットビット）で取得することをお勧めします。データベースを完全にRAMに配置すると、読み取りIO操作が完全になくなり、ボトルネックになることがなくなります。

データベースクエリのプロファイルを作成します。これを行うためにノックアラウンドするツールがあります-テスト環境で本番負荷をシミュレートできるはずです。秘訣は、遅いクエリを避け、頻繁に実行されるクエリが高速であることを確認することです。

パフォーマンスの問題がIO同期に関連している場合、データベースに対して実行するトランザクションが多すぎるため、正常に動作しているバッテリーバックアップのRAIDコントローラーを使用していることを確認してください（それらについてベンダーに相談してください）。これらは、バッテリでバックアップされていないものよりも多くのIO書き込み操作を提供します（データが必要になるのは、OSが確認を取得する前にデータをキャッシュに取得するだけだからです）。または、データがそれほど重要でない場合は、データベースの耐久性パラメーターを緩和することを検討してください（コミット時にinnodb同期）。

他の多くの人がここで提案しているように、キャッシングソリューションを検討することで、今日の負荷の約10％、おそらくそれ以下になると予想できます。

ただし、これはマシンで実行しているサービスの種類によって異なります。RAMをあまり使わずにmemcachedで多くのことができます。

MySQLのスロークエリログ（またはデータベースと同等のもの）を使用するか、mytopなどのツールを使用して、どのデータベースクエリが最も時間がかかるかをプロファイルするようにしてください。また、MySQLのEXPLAIN SELECT構文が役立つ場合があります。

選択したいくつかのMySQLクエリの結果をキャッシュすると（ほんの短い期間でも）、パフォーマンスが大幅に向上します。

私は多くのパフォーマンスとスケールアウト作業を行っており、私が発見したのは次のことです。

すべてのアプリケーションの負荷は固有です

RAMの追加、別のサーバーの取得、yの実行、xの試行などの一般的な応答は、多くの場合フラストレーションの教訓であり、複雑な設定に任せます。

正しいものを測定する

最大の課題の1つは、どのベンチマークが重要かを判断することです。多くの場合、これには一歩下がる必要があり、クライアントの立場に立つ必要があります。場合によっては、単純化されたサイトデザインが変更され、Web訪問者に大きなメリットをもたらすこともあります。これが、YSlowのようなツールが好きな理由です。サーバーレベルではなく、エンドユーザーのエクスペリエンスに重点を置いています。サイトに適したベンチマークを決定したら、チューニングを開始できます。ベンチマークは、合計ページ読み込み時間、合計ページサイズ、キャッシュの有効性、サイトの待ち時間などです。アプリケーションに適したものを選択する必要があります。

仕組み

適切なベンチマークを追跡している1つは、非常に低いレベルから始めます。sysstatを使用したい。sysstatから豊富な情報を取得し、システム全体がアプリケーションの全体的なパフォーマンスを制限している可能性があることを区別するのに役立ちます。一般に、パフォーマンスの問題は次のように煮詰めます。

• ネットワークスタック
• メモリスタック
• ディスクio
• アプリケーション層
• OSレイヤー

sysstatおよびその他のツールを使用して、ヘアを分割し始め、パフォーマンスを制限しているシステムを見つけることができます。

たとえば、アプリケーションの構成方法が原因で、負荷の高いサーバーが失敗することを確認しました。キャッシュの不足、静的コンテンツの有効期限ヘッダーの欠如、HTTP vs.ファイルインクルードの使用などがすべて、アプリケーションのパフォーマンス低下の原因でした。これらのアプリケーションの問題を修正するために、ハードウェアを変更する必要はありませんでした。他の場合では、大量のキャッシュにもかかわらず、ディスクがいっぱいになったのを見てきました。より高速なディスクに移動すると、問題が修正されました。

すすぎと繰り返し

多くの場合、アプリケーションのチューニング中に、1つのボトルネックを解除して、別のボトルネックのみを見つけます。これが、チューニングしているものを監視することをお勧めする理由です。

たとえば、ディスクIOの問題を修正したが、アプリがまだ遅いとしましょう。あなたは自分の努力を無駄にしたと思うかもしれませんが、何が起こっているかというと、単純に別のボトルネックにぶつかっただけです。ディスクIOを注意深く監視することにより、重要なアプリケーションパフォーマンスモニターが変化していなくても、ディスクIOを確実に向上させることができます。

適切なツールを入手する

ジョブに適したツールを使用していることを確認してください。監視、テスト、ベンチマーク、プロファイリング、およびその他の最適化手法には、さまざまなツールがあります。状況に最適なツールを見つけてください。

経験則

すべてのアプリはユニークですが、いくつかの標準的な出発点を見つけます。

• メモリデータベースはメモリを愛する
• RAID 10以外のディスクIOを使用すると、データベースのパフォーマンスが低下する可能性があります
• 間違った最適化-大きな値は大きなパフォーマンスに変換されません
• アプリケーション-サーバーの設計が悪いと非難する

次のステップ

ボトルネックが見つからない場合は、サーバーを追加してもあまり効果がない場合があります。ディスクIOを解決するには、別のサーバーまたはSANが必要になる場合があります。RAMのボトルネックがある場合、別のサーバーがRAMを追加するという点でのみ問題を解決します。既存のサーバーにRAMを追加するだけの場合と比べると、かなりコストがかかります。

クイックフィックス

過剰展開。アプリケーションスタックに問題があると思われる場合は、これを行わなければなりませんでした。基本的に、CPU、RAM、ディスクIO（RAID 10、15K SCSIまたはSSD）にロードします。ハードウェアを大きくして、チューニングを開始します。これにより、問題を解決するまで浮かぶことができます。

次のステップは、キャッシング（機能に応じてデータキャッシングまたはページキャッシング、あるいはその両方）である必要があると思います。memcachedが複雑すぎると思われる場合は、PEAR Cache Liteのような単純なデータキャッシングソリューションから始めることができます。ページ（またはページパーツ）キャッシングは、Smartyテンプレートエンジンなどでサポートされています。

キャッシングでそれ以上カットされなくなったら、他に何も残っていないのでサーバーの量を増やすことができます。

十分な空きRAMがある場合、memcachedは同じボックスでも役立ちます。最も重いクエリをいくつかキャッシュして、何が起こるかを確認してください。また、Apacheは重すぎます。代わりにnginxまたはlighttpdを使用してください（FastCGIを介して動作するPHPアプリケーションでは、php-fpmを参照）。

キャッシングを開始しますが、現時点ではMySQLを無視します。まじめに。

ルールは-できるだけ早くリクエストを停止する必要があります。したがって、リバースプロキシまたは適切なApacheレベルのキャッシュにより、最良の結果が得られます。次に、SQLレベルの結果がアプリケーション内でキャッシュされ、次にSQLレベルのキャッシュになります;）

リクエストを早く停止するほど、オーバーヘッドが少なくなります。出力キャッシュレベル-いわばPHPも実行する必要はありません。