ステロイドサーバー：FreeBSD、nginx、MySQL、PostgreSQL、PHPなど

はじめに

このバンドルの最適化に関する以前の記事を書いてからかなりの時間が経ちました。 512 MBのメモリを備えたPentium 4は、フォーラムで最大1,000人、トラッカーで最大150,000人のピアにサービスを提供していますが、長い間ドイツ語のスレッド、ダンプ、およびクラブが複数のサーバーに置き換わりました。 その中で述べられていることはすべて関連性がありますが、追加する価値があるものがあります。

記事は大きいため、論理ブロックに分割されます。

  0.何かを最適化する必要があるのはなぜですか？
  
 1. OS最適化（FreeBSD）
   1.1 7.xへの移行 
   1.2 7.2への移行
   1.3 amd64へのアップグレード
   1.4ネットワークサブシステムのアンロード
   1.5 FreeBSDと多数のファイル
   1.6ソフトアップデート、gjournalおよびマウントオプション
  
 2.フロントエンドの最適化（nginx）
   2.1フィルタを受け入れる
   2.2キャッシュ
   2.3 AIO
  
 3.バックエンドの最適化
   3.1 APC
   3.1.1 APCロック
   3.1.2 APCヒント
   3.1.3 APCフラグメンテーション
   3.2 PHP 5.3
  
 4.データベースの最適化
   4.1 MySQL 
   4.1.1 5.1への移行
   4.1.2 InnoDBへの移行
   4.1.3 MySQLビルトインキャッシュ-クエリキャッシュ
   4.1.4インデックス
  
 4.2 PostgreSQL
   4.2.1インデックス
   4.2.2 pgBouncerなど。
   4.2.3 pgFouine
  
 4.3データベースのアンロード
   4.3.1 SphinxQL
   4.3.2非RDBMSストレージ
   4.4エンコーディング
   4.5非同期
  
アプリケーション。 ささいなこと。
   1. SSHGuardまたは代替。
   2. xtrabackup
   3.メールを別のホストに転送する
   4.サードパーティソフトウェアとの統合
   5.モニタリング
  
  6.短所の最適化 

0.何かを最適化する必要があるのはなぜですか？

一般的に、あなたは成長できます：

• スケールアップ
• スケールアウト（中間層のフロントエンド/車の数を増やす）
• 最適化

最初のオプションは多額の資金がある場合に使用し、2番目のオプションは優れたアーキテクチャーに使用する方が適切です。 さて、私が説明する3番目のものは、1番目も2番目もないときに使用されますが、利用可能な鉄から最大を絞り出したいと思います。

1. OS最適化（FreeBSD）

1.1 7.xへの移行

FreeBSDの新しいバージョンにアップグレードすると何が得られますか？

私にとって、最も重要なことは次のとおりです。

新しいULE 3.0スケジューラとjemallocは 、マルチコア（> = 4）システムで非常に便利です。

MSI（Message Signaled Interrupts） -ドライバーでは、しばしば高速割り込みとも呼ばれます。



したがって、負荷がかかって曲がり始める従来の6.xシステムがある場合は、7.xに移行する価値があります。

1.2 7.2への移行

スーパーページ 、拡張KVA、最適化されたデフォルトsysctl'i。 最新のOSリリースにアクセスするだけで、これらすべてを完全に無料で利用できます。



進歩も止まっておらず 、現在FreeBSD 8.0のリリース準備が整い、パフォーマンスのさらなる向上が約束されています。 安定性の証拠として、 www.FreeBSD.orgは初期のベータ時代にFreeBSD-CURRENTに移行されました。 したがって、ステージングマシンでは、すでにドライブを開始できます。

1.3 amd64へのアップグレード

amd64に切り替えると、 巨大なサイズのKVAとShared Mem> 2Gbが追加されます。 しかし、これは最も重要なこととはほど遠い...



2009年には既にラップトップに4 GBのメモリを搭載しており、データベースを備えたサーバーにこれほど多くのメモリを搭載するのはばかげていることに注意してください。 もちろん、これは小さなデータベースでは正常ですが、成長してメモリに収まらなくなった場合はどうすればよいですか？ PAEは別のグリッチであるため、より多くのメモリを提供するC i386 OSには問題があります。 はい。INT64は長い間使用されてきており、データベースやOpenSSLなどのアプリケーションのパフォーマンスを向上させます。 （誰かが適切なベンチマーク「*** SQL i686 vs amd64」へのリンクを持っている場合-コメントを投げてください）。

1.4ネットワークサブシステムのアンロード

ここFreeBSDでは、それは単なるフィールドではなく、全体のテスト場です。

すべての最適化は、 ifconfig



パラメーターのチューニングとsysctl.conf/loader.conf



2つの部分に分けることができます。この順序で行きましょう。

最初に、ネットワークカードの機能を確認する必要があります。これには、次のコマンドを使用できます。

  ＃ifconfig -m
機能= 399b <RXCSUM、TXCSUM、VLAN_MTU、VLAN_HWTAGGING、VLAN_HWCSUM、TSO4、WOL_UCAST、WOL_MCAST、WOL_MAGIC> 

クラスem（Intel Gigabit）/ bge（Broadcom Gigabit）の優れたネットワークカードがある場合は、ifconfigオプションを試すことができます。

• tso
  
  
  
  （ tso4
  
  
  
  、 tso6
  
  
  
  ）-TCP Segent Offloading
• lro
  
  
  
  大規模な受信オフロード
• txcsum
  
  
  
  、 rxcsum
  
  
  
  -RX / TXチェックサムオフロード
• link0
  
  
  
  、 link0
  
  
  
  、 link2
  
  
  
  ドライバーに依存するため、そのコードを確認する必要があります。 最適化が含まれている場合もあれば、ギガビットリンクでネットワークカードを単にMASTERに切り替える場合もあります。

また、 em



ネットワークカードとマルチコアprocでは、 Yandexのドライバーを試すことができます。これは、いくつかのストリームでパケットを処理します。 また、ネットワークサブシステムの調整に関する多くのことはnag.ruで読むことができます。



サードレートのre/rl/sk/nfe



（ re/rl/sk/nfe



...）を使用している場合、上記のオプションが正しく機能せず、サーバーがフリーズする可能性があるため、 ポーリングに re/rl/sk/nfe



方が良いでしょう。



そして最後に、 「Sysoevによる」FreeBSD 7チューニングの更新版とsysctlシートをコメント付きで見ることを皆に勧めます。

1.5 FreeBSDと多数のファイル

FreeBSDには、ファイル名をディレクトリにキャッシュするための優れた技術があります。 そのため、1つのディレクトリに多数のファイルがある場合、目的のファイルを検索するためにツリー全体を常にスクロールイン/アウトするのではなく、ハッシュテーブル検索を使用することをお勧めします。 ただし、最大 vfs.ufs.dirhash_maxmem



割り当てられるメモリの量（このテクノロジが呼び出されるため）はvfs.ufs.dirhash_maxmem



によって制限され、デフォルトでは、2MBなど、非常に小さいです。 vfs.ufs.dirhash_mem



が「天井」に対して停止するまでメモリを増やすことをお勧めします。

1.6ソフトアップデート、gjournalおよびマウントオプション

新しいテラバイトのネジは単に豪華です-それらは安価であり、その性能は単なるレジです。 ただし、1つの注意点があります。データセンターで電力が遮断された場合、そのようなテラバイトのfsckは1時間以上かかることがあります。 softjupdatesを使用してこの問題を解決するか、gjournalを介してシステムへのロギングを固定できます。 正確にあなた次第です 。

いくつかのジャーナリングのヒント：パフォーマンスを失わないためには、ジャーナルパーティションを別のディスクに設定することをお勧めします。また、オーバーフローによるパニックをキャッチしないためには、ジャーナルセクションを大きくすること（RAM +スワップなど）をお勧めします。

BPUでraidを使用している場合、または失うものが何もない場合は、 /etc/fstab



async



オプションを追加できます。 そして、 noatime



などのオプションは、 ほとんどすべての人に恐れることなく推奨できます。 （ ここで ginerのコメントを読む）

2.フロントエンドの最適化（nginx）

実際、私は、フロントエンドの最適化を含む過度のおよび/または時期尚早な最適化に極端に反対しています。 通常、nginxが静的変数だけでなく、使用の性質に応じて1％〜5％のCPUを消費するWebプロジェクトでは、残りはphpによって消費されます。

ただし、nginx構成の最適化はサイトの全体的な応答時間に影響を与える可能性があるため、説明する価値のある点がいくつかあります。

標準的な最適化から、私はお勧めできます

  reset_timedout_connection on;
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on; 

まあ、労働者の数で遊んで、CPU /ネジの数だけでそれらを配置しません。 また、ServerfaultのこのドキュメントとNginxのベストプラクティストピックに誰もが慣れ親しむことをお勧めします。何か新しいことを学ぶ可能性が高いです。

2.1フィルタを受け入れる

FreeBSDには、1）データが到着した場合、2）有効なhttp要求がある場合にのみ、カーネルからプロセスにパケットを転送できる技術があります。 このテクノロジーは、 受け入れフィルターと呼ばれます。 このようなフィルターは、多数の接続の場合にサーバーをアンロードし、DDoS'aから少し保護するのに役立ちます（ ハブでngx_http_limit_req_moduleが複数回記述されていますが）が、2番目のサーバーの管理に優れています）

フィルタを使用して接続処理を有効にするには、まずカーネルモジュールをロードする必要があります。

  #ls / boot / kernel / | grep acc
    accf_data.ko
    accf_http.ko
 #kldload accf_http 

次に、 nginx.conf



config nginx.conf



、 httpready



フィルターを有効にします。

  listen 80 default accept_filter = httpready; 

2.2キャッシュ

Nginxには、 fastcgiとプロキシバックエンドの両方からの非常に柔軟な応答キャッシュシステムがあります。 ドキュメントをすぐに読む人は皆、プロジェクトでキャッシュを使用するためのいくつかのシナリオを持っていると思います。 一般的なアドバイスしかできません：

rssがphpスクリプトを介して与えられるのを神は禁じています その場合、応答を3〜5分間安全にキャッシュできます。

ゲスト用のサイトのほぼ全体のバージョンも約5分間キャッシュにプッシュできると思います（もちろん、ニュースサイトがない限り）



サーバーキャッシュに加えて、クライアントキャッシュもあります。 すべての統計情報について、月ごとに期限切れにすることをお勧めします。

    
        場所〜* \。（jpg | jpeg | gif | png）$ {
    	    root / var / nnm-club;
    	   有効期限は30日です。
         } 

2.3 AIO

NginxはすでにnginxでのAIOの導入について書いていますが 、そこのコメントには非常に興味深い議論があります。 要するに、AIOは非常に特定の負荷に対して有用であり、また、ワーカーの数を減らしながら応答時間を維持するのにも役立ちます。

aioを使用するには、aio.koカーネルモジュールをロードする必要があります。

# kldload aio





次に、 nginx.conf



aioとsendfileを有効にしnginx.conf

 
  sendfile on;
  aio sendfile; 

nginxの新しいバージョンでは、sioをsendfileで使用できます。 この構成に関して、ドキュメントには次のように記載されています。

この構成では、SF_NODISKIOフラグが使用され、sendfile（）はディスク上でブロックされませんが、メモリにデータがないことを報告します。その後、nginxは1バイトのみを読み取ることで非同期データロードを開始します。 同時に、FreeBSDカーネルは最初の128Kファイルをメモリにロードしますが、その後の読み取りでは、ファイルは16Kだけの部分でロードされます。 したがって、このモードは、最大128Kの小さなファイルの配布に最適です。

ここでこの問題を解決するためのFreeBSDのパッチは、おそらく-CURRENTに移行し、8.0および7.xに移植されるでしょう

3.バックエンドの最適化

たとえば、javaには、シリーズ「-Xms768m -Xmx1280m -XX：+ UseConcMarkSweepGC -XX：+ CMSIncrementalMode -XX：+ UseCompressedOops -Djava.net.preferIPv4Stack = true -XAnal + Javaプログラマーのみが理解でき、PHPには50％の最適化のオペコードキャッシングがあり 、残りはデータベースからの応答のキャッシングから観察されます。 したがって、トピックのこの部分は非常に意地悪です。

3.1 APC

Facebook開発者は、APCの最適化について話しました。 時間があれば、読むことを強くお勧めします。

3.1.1 APCロック

古いファイルのロック。これはまさにAPCの代わりにeAcceleratorが使用されているため、「ブレーキ」です。 そのため、多くの場合、デフォルトのロックをスピンロックまたはpthreadミューテックスに変更することをお勧めします 。 私の知る限り、pthread mutexは3.0.16からデフォルトになったため、古いAPCのサーバーがある場合は、更新することをお勧めします。

3.1.2 APCヒント

多くの.phpファイルがある場合、またはAPCユーザーキャッシュに多くキャッシュする場合、値を上げる必要がある可能性が非常に高くなります。

それぞれphp.ini



apc.num_files_hint



およびapc.user_entries_hint



これらの値は、APCテーブルのハッシュサイズに影響を与え（実際、アプリケーションの前に2倍になります）、 負荷係数 > = 0.75ではハッシュテーブルの動作が非常に悪いことがわかります。

3.1.3 APCフラグメンテーション

APCの断片化は非常に重要です。そのため、このキャッシュを取得し、くしゃくしゃにして、ウィンドウの外に放り出したいと思います。 APCは、TTLまたはLRUを使用してレコードを自動的に削除できないため、通常のKey-Valueの代わりにはなりません。 つまり、GCがなく、そこからキャッシュに入れられたエントリは、次の2つの場合にのみ移動できます。

• 彼らのTTL期限切れ後に彼らが近づいたとき
• すべてのメモリが不足し、APCは緊急対策に頼りました。キャッシュ全体をフラッシュします。

要約すると、次のように言えます。高フラグメンテーションは、APCが他の目的で使用されていることを示しています。

ここで、3.1.xのコメントで判断してメモを追加する必要があります。メモリ割り当ての点で多くの点が修正されましたが、 これで判断すると、3.1.xはすべてのユーザーに対して機能しません。

3.2 PHP 5.3

ここではすべてが簡単に思えます-PHPを更新すると、パフォーマンスが向上します。 ただし、5.3で廃止された関数のリストを見ると、まだ機能するため、恐ろしい場合があります。

その単純さにも関わらず、5.2から5.3への移行は、特に本番環境では非常に長くなると思います。

4.データベースの最適化

実際、クラブで最適なデータベースの最適化は次のとおりです。

• RDBMSをまったく使用しない（sphinxsearch）
• データベースを使用しない（キャッシュ）
• バッチリクエスト（（...）、バッチの挿入/更新）
• データベース（memcacheQ、apacheMQ、AQMP、crontab）との非同期作業

ただし、上記のツールのほとんどは、アプリケーションの大幅な書き換えが必要です。

4.1 MySQL

インターネットには、MySQLを最適化するためのマニュアルがたくさんありますが、読み書きのできるマニュアルがありますが、それほど多くありません。 いずれにせよ、Webプロジェクトの存続期間中、そのベースはメモリ、ディスク、そして場合によってはプロセッサに置かれる時間があるため、簡単なハウツーを行うことはできず、会議を見て 、プロファイラ（oprofile、 systemtap 、dtrace）を学ぶ必要がありますそして、多数の追加ソフトウェアを使用します 。 言い換えれば、インデックス、ソート、グループ化が何であるかを理解するだけでなく、MySQLが内部的にそれらをどのように使用するかを理解し、 EXPLAIN、クエリキャッシュ、さまざまなストレージエンジンの長所と短所を理解し、一般的に、あなたのプロジェクト。

次に、最小限のコード変更（またはコード変更なし）でMySQLを最適化する方法を説明します。

前の部分で述べたように、MySQLのチューニングの50％は、2つのユーティリティだけで半自動で実行できます。

• チューニングプライマー
• mysqltuner
• mysqlsla

4.1.1 5.1への移行

5.1への移行は多くのボーナスをもたらします。特に興味がありました。

• オプティマイザーの最適化（特にGROUP BY）
• InnoDBプラグイン
• パーティショニング
• 行ベースのレプリケーション

これによりパフォーマンスが向上するため、5.1を超える価値があります。 5.1が安定していないという事実にまつわるノイズについては、これはもはや関係がなく、最初は肥大化しすぎていました（5.1への切り替えの禁忌または悪意があれば、コメントしてください）。

もちろん、最も極端なものは5.4を長期間テストしており、パフォーマンスは非常によく向上していると言っています（GoogleとPerconaからのパッチの助けなしではないと思います）。 しかし、生産5.4はまだ長い道のりです。

4.1.2 InnoDBへの移行

MyISAMを使用している場合、 なぜですか？ 実稼働サーバーがMyISAMにどのように存在するかわかりません（そのような存在があると言いますが）、トランザクションがない場合（大きな更新中にサーバーがクラッシュした場合、データの半分が変更され、半分は変更されません）、TABLE LOCKがあります（記録中）テーブルおよびその逆を読み取るためにブロックされます）、データセンターで電力が失われた後の修理には数十時間かかる場合があります。 MyISAMを節約できるのは、フルテキストインデックスが存在することだけですが、sphinxsearchで品質と速度を競うことはほとんどできません。





はい、InnoDBには欠点（デッドロック、大きなインデックス、FTSの欠如）がありますが、もっと多くのボーナスがあります、私見：最初に、InnoDBは完全にACID互換です 。データは、1つのトランザクションで実行でき（ mysqldump --single-transaction



オプション）、次に、行レベルのロック（myisamのTABLE LOCKに対して）があります。つまり、複数のデータで同時にデータを読み書きできます。互いにブロックすることなくスレッド。

繰り返しになりますが、スタートアップの心のパフォーマンスを非常に心配している人々はXtraDBを使用できます。彼らはそれがI / Oバウンドワークロードで大いに役立つと言います。

4.1.3 MySQLビルトインキャッシュ-クエリキャッシュ

クエリキャッシュは、MySQLの最も「誤解された」部分の1つです。 多くの人は512Mbでそれを置き、「すべてが今すぐ飛んでいる」と考えます。多くの人は「とにかく機能しない」ため、完全にオフにします。 このパラメーターの値に光を当てようとします。 そもそも、この場合はもっと良くないので、彼を持ち上げないでください。 次に、クエリキャッシュは完全に並列化されたサブシステムではないことを明確にする必要があります。そのため、処理速度が低下するだけなので、プロセッサ数= 8で無効にすることをお勧めします。 最後になりますが、最も役に立たないわけではありません-クエリキャッシュの本質は、このテーブルへの変更が発生すると、テーブルに関連するコンテンツが完全にリセットされることです。 つまり、実際には、クエリキャッシュは適切に正規化されたテーブルでのみパフォーマンスを向上させます 。

QCの詳細については、 こちらをご覧ください 。

4.1.4インデックス

インデックスがないことはSELECTにとって悪いことなので、余分なインデックスはINSERT / UPDATEにとって悪いです。 一度作成された古いインデックスが1年以上データベースに存在し、貴重なメモリを占有し、データの変更が遅くなることがよくあります。 簡単なSQL クエリが役に立ちます 。 役に立ちましたか？ これらのヒントの多くはここで見つけることができます 。

4.2 PostgreSQL

私にとって、Postgresはかなり奇妙なシステムのままです。一方ではエンタープライズクラスのベースであり、Skypeはその上で動作します。他方では、デフォルト設定は携帯電話でも起動できるようになっています。 一般に、調整する必要があり、ほとんどすべてをここで調整できます。 ほぼ200の可能なパラメーターのうち、 主なものは45のチューニングを担当します=）

ちなみに、他に私が驚いたのは、設定内の行をコメントアウトするときに、PostgreSQLが「デフォルト」にリセットせず、「覚えている」ものを使用することです...

インターネット上のPostgresのチューニングには多くのことがあります（マニュアルの一部は古くなっているため、公開日と新しいバージョンではmaintenance_memに置き換えられるvacuum_memキーワードに注意してください）。 よくある質問のようなものがあります： 主なことについては 、高度なDB管理者のための非常に思慮深い論文があります...私は、管理者とプログラマーが資格のあるDBAを探している間にプロジェクトが立ち上がるのを助ける基本をお伝えします。

4.2.1インデックス

ここで、公正な質問があります。なぜ、MySQLインデックスが最後に、PosgreSQLが最初にあったのでしょうか？ この点での機能はMySQLの機能よりもはるかに高いため、すべてが単純です 。 Bツリー、ハッシュ、GiST、GIN、および式の複数列、部分、インデックス：これらはすべて、PostgerSQLをプログラムする人が理解する必要があります。 そして、それが存在することを知るためだけでなく、どの場合にある種のインデックスを使用する必要があるのか​​、そして他のどのインデックスを使用するのかを理解するためです。

監視に有用なSQLクエリ（インデックスの統計を含む）は、 ここにあります 。

4.2.2 pgBouncerなど。

pgBouncer （またはその代替）は、データベースを備えたサーバーに最初にインストールする必要があるものです。 接続マネージャーの単純なインストールによる負荷の10倍の低下を示すサボテングラフを十分に見ました。 接続プーラーがない場合、データベースへの接続ごとに個別のプロセスが起動され、このプロセスは少なくともwork_mem



のwork_mem



食い尽くし、SQLクエリを実行して独自の種類のCPUとハードドライブの戦いを開始します。 すべては問題ありませんが、そのようなプロセスの数が200〜500の規模から外れると、サーバーは非常に強力なサーバーであってもタイトになります。 とてもきつい。 pgBouncerはこれから私たちを救います。

また、PostgreSQLを操作するための便利な、または不可欠なアプリケーションのリストは、 postgresqlrussia.orgにあります。

4.2.3 pgFouine

pgFouineは、そのようなかけがえのないプログラムの1つにすぎません。 これは、phpの非常に高度なmysqlslaアナログです。 Playr （ログのリプレーヤー生成）を使用すると、ステージングサーバー上のリクエストをほぼ「戦闘」状態で最適化できます。

4.3データベースのアンロード

前述したように、データベースを最適化してパフォーマンスを向上させる最良の方法は、できる限りアクセスしないことです。

4.3.1 SphinxQL

前回の記事では、 sphinxsearchに基づく検索を導入したという事実について説明しました。 しかし、誰もがSphinxAPIの使用を開始するために数千行のコードを検索し、バグのテストとキャッチにさらに1〜2回の反復を費やすことができるわけではありません。 この問題は非常にエレガントに解決されました。SphinxSearchはMySQLサーバーのふりをすることを学びました。 sphinx.conf



、 sphinx.conf



を作成し、cronでインデクサーのエントリを作成し、検索を別の「mysql」のようなデータベースに切り替えるだけです。 コードをさらに編集する必要がない可能性があります。

スフィンクスに切り替えると何が得られますか？ 検索の速度と品質を改善することに加えて、MyISAMとそのFTSを取り除くことができます。非常に興味深いのは、検索用の新しいアプリケーションを考案することです 。そのため、検索とRSSを組み合わせました。これは非常に便利でした。

そして、sphinxsearchの存在から利益を得ることができるいくつかの例があります（ほとんど外出中に発明されたので、激しく叩かないでください）：

例1 ：長い間Starcraft 2を待っていましたが、次の形式のRSSフィードをいつでも追加できます：rss.php？Q = "starcraft 2"をGoogle Readerに追加し、それについて説明するすべての投稿を確認します。 また、フォーラムのメンバーとして、私のニックネームが言及されているすべての投稿を見たいです。 これも問題ではありません。URLを修正するだけです。

例1.5 ：サイトにアクセスしたユーザーが検索バーを見、クエリを入力し、何も見つかりませんでしたが、このリクエストのRSSへのリンクを含む「この検索を購読」リンクが表示されました。 したがって、ユーザーだけがあなたを離れることはありません=））

例2 ：映画21、または神の禁じられた映画9を見つけたいft_min_word_len



自殺ではなく、 ft_min_word_len



クエリの長​​さよりも長いと不平を言って、単にそのようなリクエストを拒否します。 スフィンクスは、ほぼ瞬時に結果を「Twenty One / 21」の形式で返し、2番目のケースでは、「District No. 9 / District 9」と「Nine / 9」から選択することもできます。

4.3.2非RDBMSストレージ

プロジェクトには、リレーショナルデータベースを使用できない場所が非常に多くあります。 単純なキーと値のストアで十分です。 これらの利点は今では十分です。

また、 Hive （SQLのようなQLとHadoop形式のバックエンドを備えたデータウェアハウス）などの非常に興味深いプロジェクトもあります。 一般に、データウェアハウスを使用すると、Oracle（MySQL、PostgreSQL、FoxPro、必要なものに下線を引く）だけでなく、どのように生きているかを実験することができます。

また、その速度のために、キーと値のデータベースは、リレーショナルデータベースからサンプルをキャッシュするために使用されます。 キャッシュ自体について：プレゼンテーションをスクロールし、ビデオを見て、 Andrey Smirnovのブログからレポートの全文を読んだ後、私は実質的に追加するものがありません。 ほんのいくつかのヒント：

PHPに非常に大きなプロジェクトがある場合は、オペコードキャッシュがカスタムデータを保存する機能を忘れないでください。 最も一般的に使用されるグローバル変数をその中に保存できます。まず、それらの多くはなく、小さいため、メモリを少ししか消費しません。次に、サンプリングレートは、隣接マシンにあるmemcachedよりも高くなります。最も興味深いのは、大規模なプロジェクトでは、グローバル変数のブロックがmemcachedファームから1台のマシンに書き込まれる場合がありました。これらの変数はすべてのバックエンドを使用するため、このマシンへのトラフィックは不適切なサイズに増加し、マシンは非常に遅くなり始めました。そして、それとともにすべてのバックエンド。この状況から抜け出す方法は、APC / eAcceleratorタイプのオペコードキャッシュにグローバル変数を保存するか、memcachedファームからすべてのサーバーに変数を複製し、一貫性ハッシュアルゴリズムに例外を導入することです。

4.4エンコーディング

エンコーディングに関する簡単なメモ：

UTF-8は1つを除くすべての人に適しています-その中のロシア語のテキストは正確に2倍のスペースを占有するため、完全に単一言語のコンティンジェントがある場合、使用する前に考慮すべきことがあります。

4.5非同期

実際、同期データ処理は常に必要なわけではなく、非同期処理で置き換えることができる場合が非常に多くあります。

非同期処理は、1）サイト/アプリケーションの応答時間を改善する2）サーバーの負荷を軽減するのに役立ちます。

最初のものですべてが明確な場合、2番目はバッチ要求が単一の要求よりも速く実行されるという事実の結果です。

非同期はさまざまな方法で編成できます。大規模なプロジェクトでは、これは、メッセージキューを使用して行われる（ApacheMQ、RabbitMQの、ZeroMQ。AQMPはすでに何度か述べについてHabré）、罰金では、あなたがcronを行うことができます。

アプリケーション。ささいなこと。

1. SSHGuardまたは代替。

sshにブルートフォース対策をインストールすることは標準的な慣行であるという事実に加えて、完全に死んだボットによって攻撃され、数万のログインパスペアのブルートフォースを開始するときに、サーバーをLoad Avarengeの急激なバーストから保護するのにも役立ちます。

2. xtrabackup

LVMスナップショットはブレーキです。 mysqldump-テーブルをロックし、数週間復元できるテキストバックアップを作成します。非常に良い MySQLをバックアップするためのツールですxtrabackup Perconaによって。インターネットのロシアの部分がそれについて聞いたので、私はそれを強く塗りません。要するに、xtrabackupはInnoDB / XtraDBテーブルのノンブロッキングバイナリバックアップを可能にするツールであり、多くの設定があります。なぜそれが非常に良くて素晴らしいのではないのですか？私の意見では、最良のツールはZFSのクローンです。それらは即座に行われ、それらからデータベースを復元することは、マッスル設定内のファイルへのパスを変更するだけであり、リカバリが失敗した場合、ロールバックできます。クローンも使用できますカーネルのアップグレードが失敗した場合などに、システム全体を復元します。

一般的に、5.4では組み込みのオンラインバックアップが約束されているようです。

3.メールを別のホストに転送する

この最適化はささいなことのように思えますが、大量のスパムがサーバーに流れ込むと、トラフィックを大幅に削減し、多くのIOPを節約できます。

4.サードパーティソフトウェアとの統合

どういうわけか、オンラインゲームに関する記事がハブに掲載されました;おそらく、あなたが最も適切な手段を使用するために必要なすべてのために（誰かがそれが呼ばれたことを覚えていますか？）したがって、たとえば、ユーザーが添付ファイル付きの電子メールメッセージを交換できるようにするために、DB / FSの形式でバックエンドを使用してPHPスクリプトの作成を開始する必要はありません。これに使用できます。 imapして、簡単なアダプターを作成します。同様に、ユーザー向けのチャットは、サーバーをまったく読み込まないjavascriptクライアントを備えたジャバーサーバーに基づいて構成できます。マップ上のオブジェクトをマークする必要がありますか？ここでマッシュアップを書く方が簡単です。Yandex / Googleマップを使用します。興味深いことに、完成品用のアダプターに基づいて作成されたこのようなシステムは、少なくともPHPおよびMySQLソリューションよりも桁違いに優れていることがよくあります。

5.モニタリング

現在の状態がわからない場合、最適化するものはありません。パフォーマンス、遅延、空きリソースなどのメトリックをすべて監視し、ログに記録し、できればグラフに描画する必要があります。ツールの利点は十分です：Nagios、Zabbix、Cacti、Munin ....



いずれかを取得し、サーバーに配置して、サーバーの負荷に対する最適化の効果を観察します。監視は、パフォーマンスの問題の予測にも役立ちます。

6.短所の最適化

結局のところ、彼は誤ってそのように名付けられていません。クラブが新しい​​サーバーに移動したとき、私たちは自分のスキンでそれを感じ、ほとんどすべて（APC1、APC2、MySQL、nginx、xbtt）のバグを見つけることができました。OpenSourceの利点は、自分で簡単なものを修正できることです。

あとがきの代わりに

まあ、のように、それがすべてです。彼はほぼ1週間印刷しました...習得したもの、習得したもの、ZFS、分散FS、レプリケーション、シャーディングの舞台裏を残しました。これらは個々の投稿のトピックです。私の文法や句読点では、あまりにも悪い、私は確信していると、いくつかWordの回、そしてすべてにチェックがトートロジーあなたがそれを見つけその場合、 -に書き込みを個人的に補正。



あなたが投稿でカントを見つけたなら、あなたは私のプロジェクトの1つでカントを見つけた可能性が高いので、記事への批判を歓迎します。