Nginx、Apache、PHP、MySqlの最適化

突然、タスクは、特定のサイトが必要な速度で動作しない理由を把握することでした。 彼のCakePHPの中心で、ApacheおよびMySQLと連携しています。 この記事では、ボトルネックを見つけて、できる限り整理するプロセスについて説明します。



私はサイトの名前を輝かせません-プログラマー自身が見つけると思います。 これは、定期的に7万から15万人の訪問者がいるソーシャルネットワークのアプリケーションであるとしか言えません。 定期的に広告メールが行われ、数時間で約20万から30万人の訪問者が集まるという事実によって、すべてが複雑になっています。



だから、カットの下で、4日間の全体の闘争の説明。



この記事は、2つのグループの人々を対象としています。 1つ目は、もちろん、このような不名誉を払わなければならない管理者です。 時々、死にかけているサーバーをほとんど耳で引っ張ります。 視聴者の2番目の部分は、すべての資料を確実に読むことを望んでいますが、プログラマです。 友だち、私は言います。プロジェクトを正しく設計していれば、このような不名誉はないでしょう。多くの事件は回避できたでしょう。 特に、あなたがあなたのプロジェクトを書いている聴衆を知っています。



私は自由にヘッツナーサイトにEX10サーバーを設置していました。 知らない人のために、これは64 GBのRAMと6コアプロセッサです。 それをシステムのコアと呼びます。 さらに2つのサーバーがあり、1つは静的サーバー、もう1つはバックエンドベースです。 小さなアプリケーション、InnoDB 500MBデータベース。



後で判明した70-100のオンラインセッションでの一定の負荷では、状況は次のとおりです。各コアのCPU負荷が100％。 もちろん、MySQLとApacheはシステムリソースをめぐって争っています。

Nginx

最初の試みは、Apache出力をキャッシュして静的出力を削除することにより、サーバーの負荷を減らすことでした。



非常に簡単な構成でインストールされました：彼はすべてのマスクされたファイルを試して特定のフォルダーから選択する必要がありました。ファイルが存在しない場合は、プロキシサーバーから選択し、このフォルダーに入れてクライアントに渡します。

 http {
 proxy_cache_path / var / tmp / nginx_cache / levels = 1：2 keys_zone = ok：100m inactive = 1d max_size = 1024m;
サーバー{
         location〜* \。（js | jpg | jpg | png | jpeg | gif | zip | tgz | gz | rar | doc | xls | exe | pdf | ppt | txt | wav | bmp | rtf）$ {
                有効期限は1年です。
                 open_file_cache_errors off;
                 error_page 404 = @fetch;
                 root / var / tmp / _fetch_ok;
                 }

        場所@fetch {
                 proxy_store_accessユーザー：rwグループ：rw all：r;
                 proxy_store on;
                 proxy_pass http://127.0.0.1:80;
                 proxy_temp_path / var / tmp / _fetch_ok_temp;
                 root / var / tmp / _fetch_ok;
                 }


       場所/ {
                 proxy_cache ok;
                 proxy_pass http://127.0.0.1;
                 proxy_cache_valid任意の10m;
                 proxy_buffer_size 8k;
                }
 }
 }

構成は完全には与えられませんが、この例に必要なブロックのみが与えられます。



残念ながら、これは結果につながりませんでした。

3つのプラスのみがありました。

• Apacheは画像の表示を停止しました。つまり、負荷が少し少なくなりました。
• Apacheは外界との直接の通信を停止したため、キープアライブをオフにして子の数を減らすことができました。
• 最初のボトルネックが見つかりました。サイトへのすべてのリクエストは、.htaccessがリクエストをリダイレクトするPHPスクリプトによって制御されます。 含めて、あなたは信じられない、すべての静的、さらにはCSS。

MySQL

現時点では、SQLクエリと最適化の経験があまりないため、これは最も困難です。

MySQLのドキュメントを読むことから始めました。



InnoDBが手元にあるので、開始位置の標準配信my-innodb-heavy-4G.cnfから構成ファイルを取得しました



以下では、負荷の高いプロジェクトに注意する必要がある構成パラメーターについて説明します。



back_log = 5000

max_connections = 1600

最初のパラメーターは、サーバーが新しい要求への応答を停止するまでキューに入れることができる接続の数に責任があります。 2番目は、サーバーが受け入れることができる接続の数です。

私にとっては、これらの値は非常に大きく、平均で1300までの競合セッションがありますが、各接続には一定量のRAMが必要な場合があるため、必要以上にベットする価値はありません。 それについては後で詳しく説明します。



max_connect_errors = 50

ここでは簡単です-切断を受信する前にクライアントが行うことができるエラーの数。 プロジェクトは開発中であり、リクエストが間違っている可能性が高いため、増やす必要がありました。



table_cache = 2048

テーブルを開くにはいくつかのリソースが必要であるため、このパラメーターは、最後の接続後しばらくして次の接続を待機している開いているテーブルの数を決定します。

変数で変更する必要があるかどうかを調べる

SHOW GLOBAL STATUS LIKE 'Opened_tables';





できるだけ小さくしないでください。

ここによく書かれています： http : //www.mysql.ru/docs/man/Table_cache.html



max_allowed_pa​​cket = 16M

最大パケットサイズ。 大きなBLOBを使用しない場合、変更する意味はありません。



binlog_cache_size = 1M

トランザクションのバイナリログキャッシュのサイズ。 公式文書では、大規模な取引がある場合は増やすことを推奨しています。

dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_binlog_cache_size



max_heap_table_size = 64M

tmp_table_size = 64M

私の知る限り、小さい方が考慮されます。 このパラメーターは、メモリーに収まる一時テーブルの最大サイズを決定します。 テーブルがそれに達すると、ディスクに配置されます。 したがって、ディスク上にできる限り少ないテーブルを作成する必要があります。 一時テーブルとディスク上のテーブルの現在の比率を表示するには、リクエストしてください

show status like '%tmp%tables';





www.mysqlperformanceblog.com/2007/01/19/tmp_table_size-and-max_heap_table_size



sort_buffer_size = 8M

だれもだまさないために、私は翻訳することを約束しません。 次の場合にのみ、ドキュメントでこのパラメーターを確認することを推奨していることのみを明確にします。

'％Sort_merge_passes％'のようなステータスを表示します。 ゼロ以上

dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_sort_buffer_size



join_buffer_size = 2M

私の知る限り、インデックスを使用しない操作用に設計されたバッファの最大サイズ。 まだ触れていません。

dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_join_buffer_size



thread_cache_size = 4096

クエリが完了した後に再利用するために残っている取引の最大数。 MySQLが新しい取引をできる限り少なくし、古い取引を使用するように十分な状態を保つことは便利です。 Threads_created / Connectionsパラメーターに関連して、このパラメーターの有効性を理解できます。

dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_thread_cache_size



query_cache_size = 256M

query_cache_limit = 8M

この翻訳の著者である私の同僚であるhabrahabr.ru/post/41166よりも優れていると思います。

これはおそらく最も重要なパラメーターなので、読み直すことをお勧めします。



thread_stack = 192K

このパラメーターの目的については説明しませんが、各接続でも際立っているため、消費されるRAMの量にも影響するという事実にのみ注意を払います。 したがって、再び最大接続数を掛けます



long_query_time = 2

log_long_format

log-queries-not-using-indexes

MySQLサーバーには、データベースのパフォーマンスを評価するための非常に便利なツールがあります。 これは長い要求ログファイルです。 私の経験では、これらはほとんどの場合、非効率的なクエリまたは非インデックスクエリです。

このログファイルを使用してプログラマに行くことをお勧めします。



key_buffer_size = 1G

このパラメーターは、インデックスをメモリにキャッシュし、この値を最適化するために、Key_read_requests、Key_readsを参照します。 2番目のパラメーターは、バッファーではなく、ディスクからの読み取り回数に責任を負います。

mysqltips.blogspot.com/2007/03/key-buffer.html



read_buffer_size = 1M

boombick.org/blog/posts/3-このテキストを読んだ後、私は自分が正しいかどうかわからないので、何も追加する危険はありません。



read_rnd_buffer_size = 24M

このパラメーターは、ソート操作の速度に影響します。 残念ながら、その有効性を評価する方法が見つかりませんでした。

dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_read_rnd_buffer_size

www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size



myisam_sort_buffer_size = 128M

myisam_max_sort_file_size = 10G

myisam_max_extra_sort_file_size = 10G

パラメーターはソートに影響しますが、変更することを敢えてしませんでした。 これにより複雑なクエリのパフォーマンスが向上すると仮定して、最初の値を増やしました。



sync_binlog = 0

私たちの場合、それはシステム機能を介してバイナリログをディスクに同期しないことを意味します。 パラメーターがゼロより大きい場合、サーバーはn要求ごとにデータを同期します。

dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_sync_binlog



innodb_buffer_pool_size = 4G

この設定を増やすと、ディスク操作が減少します。 残念ながら、私はそれをより良く測定する方法も見つけませんでした。 ベースが小さいので、あまり大きくしないことにしました。 大規模なデータベースの場合、アドバイスのどこかでこのパラメーターをRAMの70％に増やします。

dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_buffer_pool_size



innodb_log_buffer_size = 32M

説明によれば、重いトランザクション中のディスク操作を削減します。

dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_log_buffer_size



innodb_log_file_size = 1024M

ドキュメントを信じている場合は、ログファイルを増やすとIOディスク操作の負荷は軽減されますが、障害が発生した場合の復旧時間は長くなります。

dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_log_file_size



innodb_flush_log_at_trx_commit = 0

0に設定すると、バッファは毎秒1 秒に 1回フラッシュされ、各挿入の後ではありません。

dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit



innodb_thread_concurrency = 14

彼らは、コアの数より少し多く置くことを推奨しています。



innodb_sync_spin_loops = 10

私が理解しているように、ロックされたデータへのアクセス試行回数に影響します。 この値を増やすと、プロセッサ時間が失われ、データベースへの書き込みの信頼性が低下します。

www.mysqlperformanceblog.com/2006/09/07/internals-of-innodb-mutexes

dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_sync_spin_loops

DBおよびRAM

データベースで何を変更する必要があるかについての基本的な理解を与える素晴らしいperlスクリプトがあります。 mysqltuner.pl/mysqltuner.pl

多くの場合、このスクリプトはmysqlサーバーの最大メモリ消費を誓います。

ソースを見ると、これはこのプログラムがメモリ使用量をどのように考慮するかです：



per_thread_buffers = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size;

total_per_thread_buffers = per_thread_buffers * max_connections;

server_buffers = key_buffer_size + max_tmp_table_size;

server_buffers + = innodb_buffer_pool_size;

server_buffers + = innodb_additional_mem_pool_size;

server_buffers + = innodb_log_buffer_size;

server_buffers + = query_cache_size;

total_possible_used_memory = server_buffers + total_per_thread_buffers;



値を正しく指定しなかった場所を理解しておくと役に立ちました。

ちなみに、すぐにパラメーターを過小評価します。スクリプトが大量のRAMベースを消費すると誓った場合、それは価値がありません。 多くの人がこれは単なる理論的な指標であると言っているので、データベースはそれ自体にそれほど多くのメモリを使用しようとはしないかもしれません。

データベース構造の最適化。

可能な限りすべての設定を行っても、まだ良い結果が得られなかった場合は、スローログファイルを使用します。

mysqlには、標準でmysqldumpslowが付属しています。

実行することにより

mysqldumpslow -sc <スローログファイルへのパス>エントリの数でソートされました。データベースクエリのリストが長すぎるか、インデックスを使用していませんでした。 通常、正しいインデックスを追加すると、両方の問題が修正されます。



ほとんどの場合、このプログラムの出力（カウント変数）に多数の長いクエリが表示されている場合、このクエリの一部をコピーし、ログファイルのテキストでそのようなクエリの例を探します。

次に、データベースクライアントに移動してこのクエリを実行し、最初にExplainという単語を追加します。

また、こちらで詳細を読むこともできます。

habrahabr.ru/post/31072



これにより、クエリがインデックスを使用しているかどうかを確認できます。

テーブルに十分なインデックスがない場合は、無理に追加することはできませんが、インデックスを安全に追加できます。 whereとorderの後に使用される列にはインデックスが必要です。 各stobletsの一意のインデックスから始めます。 そうしないと、インデックスが機能しない場合があります。

ここでは、これらのインデックスがどのように機能するかをより詳しく知ることができます。

dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html



率直に言って、5つのキーリクエストを最適化した後、サーバーは50ではなく500〜700の接続を処理でき、PHPページの発行時間は8秒ではなく1秒に短縮されました。 最大負荷では、ページ配信時間は50秒ではなく5秒でした。 （これは、Apache Benchmark cを使用した約1000スレッドのパフォーマンス測定を指します）

nginxについてもう少し。

最適化後、負荷が大きいと、apacheではなくnginx自体が一定量以上リクエストをスローすることに気付きました。 ただし、メモリとCPUはロードされません。

彼は理解し始めました。 ログで、nginxサーバーが必要以上のファイルを開こうとしていることがわかりました。

私が対処しなければならなかったSuseでは、ファイルがこの制限を担当しています

/etc/security/limits.conf

そこで次の行を追加しました。

 nginxソフトnofile 300000
 nginx hard nofile 300000

サーバーの再起動は必要ありませんでした。

Apache2

まだ構成をあまり変更していません。 私がやったことは、キープアライブをオフにすることだけでした。 Apacheが穏やかに答えを出し、nginxがまだ低速チャンネルのクライアントにページを提供しているその時点で、次のリクエストに従事できること。

eAccelerator

このオプティマイザーには、変更可能な多数のパラメーターがあることも忘れないでください。



変更点は次のとおりです。

eaccelerator.shm_size = "2096"

使用できる仮想メモリのサイズ（メガバイト単位）



eaccelerator.shm_only = "1"-RAMのみを使用し、ディスクを使用しない、2 SatディスクのソフトウェアRAIDでのioの戦いで、そうすることを決めました。

読むのに役立つ他のものは次のとおりです。

habrahabr.ru/post/41166

habrahabr.ru/post/108418

dev.mysql.com/doc/refman/5.5/en/server-system-variables.html



この記事を読んで、文法的および文体的な誤りの山をすべて修正してくれた私の友人に感謝します。

あとがきの代わりに

友人たち、私はこの記事で与えられた結論に誤りや誤りがたくさんあることを理解しています。

記事をより良くするための第一人者への大きなコメントとコメント。

UPD。 コメントの要約

このような大きな関心をお寄せいただきありがとうございます。 期待していなかった。



良いリンク、私は読むことをお勧めします： www.percona.com/files/presentations/percona-live/dc-2012/PLDC2012-optimizing-mysql-configuration.pdf

ありがとうアルベルタム



PHPキャッシングシステムについて：

はい、確かにeAcceleratorが唯一のオプションではありません。

APCもあり、はい、彼らは本当にそれをPHPに埋め込むつもりです。

十分なテストを行っていないため、何が良いかを判断するつもりはありません。



MySQLに代わるものも存在し、多くあります。

もちろんキー：

ミリアド

パーコナ



個人的にパーコンを選びましたが、今のところ満足しています。



これが最終的な明るい結果ではなく、先に進む必要があるという事実に関して-注意深く読んだ人は、これが単なるパッチングの穴であることがわかります。