検索

ホームページ  >  記事  >  php教程  >  Nginx との最初のコンタクト

Nginx との最初のコンタクト

高洛峰
高洛峰オリジナル
2016-12-01 13:15:541320ブラウズ

しばらく前、私は会社の Web サイトのテストに使用したサーバーにログインし、誤って access.log.gz ファイル パッケージを目にしました。好奇心に駆られて、それをリモート サーバーからローカル コンピューターにダウンロードし、解凍して開きました。それはアクセス ファイルでした。私はいつもアクセス ログについて頭の中で聞いていましたが、それが何なのかは知りませんでした。理解できないので、nginx サーバー ソフトウェアというものについて知りました。暇なときに簡単に理解した後、毎日の開発とデバッグ中に、最もよく使用されるポートを監視することもできるのではないかと考えました。一種の学習ですが、やはり本や資料を読むよりも自分でやったほうがより深い体験ができます。今日は構成についてのみ説明します。学習が進むにつれて、ロード バランシング、リバース プロキシ、最適化などについても触れていきます。間違っている点があれば、修正して、お互いに学び、一緒に進歩してください。

Apaceh や他のものと比較すると、Nginx には多くの利点がありますが、ここではあまり強調しません。それらは、高い同時接続、低メモリ消費、シンプルな設定ファイルにすぎません。等

(1) インストール

ubuntu システムへの nginx のインストールは非常に簡単で、コマンド 1 つで実行できます。 

sudo apt-get install nginx

ちなみに、インストール中にエラーが発生した場合、ターミナルに「パッケージ リストまたはステータス ファイルを解析または開くことができません」というメッセージが表示されます。詳細は次のとおりです。

E: Encountered a Section withいいえ パッケージ: ヘッダー

E: MergeList /var/lib/apt/lists/cn.archive.ubuntu.com_ubuntu_dists_natty_main_i18n_Translation-en に関する問題

E: パッケージ リストまたはステータス ファイルを解析または開くことができません。

解決策:

sudo rm /var/lib/apt/lists/* -vf //削除できない場合は、パラメータ -r を追加して強制削除を使用できます

sudo apt-get update

もう一つのポイントApache がコンピュータにインストールされ、すでに実行されている場合は、Apache と Nginx のデフォルト ポートが両方とも 80 であるため、Apache を停止します。

インストールが成功すると、実行可能なコマンドが表示され、ターミナルを開いてコマンド nginx -h を入力すると、いくつかのコマンド パラメーター情報が表示されます。

nginx -h コマンドヘルプを表示します

nginx -v バージョン情報を表示します

nginx -V バージョン情報と設定オプションを表示します

nginx -t 設定ファイルをテストします

nginx -T 設定ファイルをテストしてダンプします

nginx - q 構成テスト中にエラー以外のメッセージを抑制します

nginx -s signal シグナルをメインプログラムに送信します。シグナルには、stop、stop nginx、exit、open、open; が含まれます。

nginx -p prefix プレフィックスのパスを設定します。デフォルトは /usr/share/nginx/

nginx -c filename 設定ファイルを設定します。デフォルトは /etc/nginx/nginx.conf です

ngnix -g ディレクティブ設定は構成ファイルの範囲を超えています グローバル コマンド

注: これらのコマンドを使用するときにエラーが発生した場合は、権限の問題である可能性があります。root に切り替えて実行してください。

(2)設定ファイル

メインの設定ファイルはnginx.conf、デフォルトパスは/etc/nginx/

PHP関連はfastcgi_params、Python関連はuwsgi_paramsです

設定ファイルのパラメータとそれらの意味は次のとおりです:

ユーザー www www ;

Nginx ユーザーおよびグループ。

worker_processes 8;

ワーカープロセスの数がウィンドウで指定されていません。ハードウェアの調整に応じて、通常は CPU コアの合計数と同じか、コアの合計数の 2 倍になります。

error_log /var/logs/error.log crit;

エラー ログの保存パスとレベル。レベルは [debug|info|notice|warn|error|crdit] です。

各エラー ログ レベルについては、を参照してください。ブログ投稿 http://blog.csdn.net/solmyr_biti/article/details/50634533

pid /run/nginx.pid;

pid プロセス識別子のストレージ パス。 pid ファイルは、プロセスの ID を記録する内容が 1 行だけのテキスト ファイルです。 pid ファイルの目的は、プロセスが複数のコピーを開始しないようにすることです。 pid ファイル (固定パス、固定ファイル名) の書き込み許可 (F_WRLCK) を取得したプロセスのみが正常に起動し、自身の PID をファイルに書き込むことができます。同じプログラムの他の冗長プロセスは自動的に終了します。

nginx の pid ファイルを使用して、nginx をスムーズに停止、再起動、再起動します。例 コマンドの形式は次のとおりです:


kill-signal type `cat /run/nginx.pid`

シグナルのタイプは主に次のとおりです:

TERM, int すぐにシャットダウンします。 設定ファイルをロードします

USER1 再開します。ログ ファイルを切り取るときに非常に便利です

USER2 開くことができる最大の記述子。

このコマンドは、nginx プロセスによって開かれるファイル記述子の最大数を指します。理論値は、開いているファイルの最大数 (ulimit -n) を nginx プロセスの数で割ったものである必要があります。 ulimit -n の値は一貫したままです。

現在、Linux 2.6 カーネルで開いているファイルの数は 65535 であり、それに応じて worker_rlimit_nofile には 65535 を入力する必要があります。

これは、nginx のスケジューリング時のプロセスへのリクエストの割り当てがあまりバランスが取れていないためです。そのため、10240 を入力し、合計同時実行数が 30,000 ～ 40,000 に達すると、プロセス数が 10240 を超える可能性があり、502 エラーが返されます。

イベント

{

epoll を使用する;

epoll のネットワーク I/O モデルを使用します。 Linux は epoll を推奨し、FreeBSD は kqueue を推奨しますが、window では指定されません。

epoll、select、kqueue がいつ使用されるかに関する関連情報を確認できます。

worker_connections 204800;

ワーカー プロセスごとの最大接続数。ハードウェアに応じて調整し、前の作業プロセスと組み合わせて使用​​してください。ただし、CPU を 100% で実行しないでください。理論上、nginx サーバーごとの最大接続数は、worker_processes*worker_connections

keepalive_timeout 60;

keepalive timeout です。

client_header_buffer_size 4k;

クライアントリクエストヘッダーのバッファサイズ。これは、システムのページング サイズに応じて設定できます。通常、リクエスト ヘッダーのサイズは 1k を超えることはありません。ただし、システムのページング サイズはここで設定されます。

ページング サイズは getconf PAGESIZE コマンドで取得できます。

ただし、 client_header_buffer_size が 4k を超える場合もありますが、 client_header_buffer_size の値は「システム ページング サイズ」の整数倍に設定する必要があります。

open_file_cache max=65535 inactive=60s;

これは、開いているファイルのキャッシュを指定します。最大値は、開いているファイルの数と一致するように指定します。ファイルが要求されていない期間が経過したら、キャッシュを削除します。

open_file_cache_valid 80s;

これは、キャッシュされた有効な情報を確認する頻度を指します。

open_file_cache_min_uses 1;

open_file_cache ディレクティブの inactive パラメーター内のファイルの最小使用数。この数値を超えると、ファイル記述子は常にキャッシュ内で開かれます。非アクティブ時間内に一度も使用されなかった場合は削除されます。

}

##以下は、http サーバーを設定し、そのリバース プロキシ機能を使用して負荷分散サポートを提供する方法です

http

{

include mime.types;

MIME タイプを設定します。タイプはby mime.type ファイル定義

default_type application/octet-stream;


log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$ http_user_agent" "$http_x_forwarded_for"';

log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';

ログ形式の設定。

$remote_addr と $http_x_forwarded_for はクライアントの IP アドレスを記録するために使用されます。

$remote_user: クライアントのユーザー名を記録するために使用されます。リクエストの URL と http プロトコルを記録します。

$status: リクエストのステータスを記録するために使用されます。成功の場合は 200、

$body_bytes_sent: クライアントに送信されたファイルの本文のサイズを記録します。からアクセスされたページのリンクを記録するために使用されます;

$http_user_agent: 顧客のブラウザの関連情報を記録します;

通常、Web サーバーはリバース プロキシの背後に配置されているため、顧客の IP アドレスは取得できません。 $remote_add はプロキシ サーバーの IP アドレスを逆にします。リバース プロキシ サーバーは、転送されたリクエストの http ヘッダー情報に x_forwarded_for 情報を追加して、元のクライアントの IP アドレスと元のクライアントのリクエストのサーバー アドレスを記録できます。

access_log logs/host.access.log main;

access_log logs/host.access.404.log log404;

log_format ディレクティブを使用してログ形式を設定した後、access_log ディレクティブを使用してストレージ パスを指定する必要がありますログ ファイルの;

gzip on:

gzip 圧縮出力を有効にして、ネットワーク送信を削減します。

gzip_min_length 1k

圧縮が許可されるページの最小バイト数を設定します。ページのバイト数はヘッダーのコンテンツ長から取得されます。デフォルト値は 20 です。バイト数を 1k より大きく設定することをお勧めします。1k 未満の場合、圧縮がさらに進む可能性があります。

gzip_buffers 4 16k

gzip 圧縮結果のデータ ストリームを保存するために複数ユニットのキャッシュを取得するようにシステムを設定します。 4 16k は、16k 単位でインストールされる元のデータの 4 倍のサイズのメモリを 16k 単位で申請することを意味します。

gzip_http_version 1.0

初期のブラウザは Gzip 圧縮をサポートしておらず、文字化けが発生する可能性があるため、Nginx のリバース プロキシを使用する場合にこのオプションが追加されました。 Gzip 圧縮も有効にするには、最終通信が http/1.0 であるため、1.0 に設定してください。

gzip_comp_レベル 6

gzip 圧縮率、1 は圧縮率が最小で処理速度が最も速く、9 は圧縮率が最大ですが処理速度が最も遅くなります (送信は速いですが CPU の消費量が多くなります)

gzip_types

指定されているかどうかに関係なく、圧縮の MIME タイプと一致しますではなく、「text/html」型は常に圧縮されます。

gzip_proxied any

Nginx がリバース プロキシとして使用される場合に有効になり、バックエンド サーバーから返される結果の圧縮を有効にするか無効にするかを決定します。照合の前提条件は、バックエンド サーバーが「Via」を含むヘッダーを返す必要があることです。 。

の

gzip_vary は http ヘッダーに関連しています。Vary: Accept-Encoding が応答ヘッダーに追加され、フロントエンド キャッシュ サーバーが gzip 圧縮されたページをキャッシュできるようになります。たとえば、Squid を使用して Nginx をキャッシュします。圧縮されたデータ。 。

server_names_hash_bucket_size 128;

サーバー名を保存するハッシュテーブルは、server_names_hash_max_size およびserver_names_hash_bucket_size の命令によって制御されます。パラメータのハッシュ バケット サイズは常にハッシュ テーブルのサイズと等しく、プロセッサ キャッシュ サイズの倍数です。メモリ内のアクセス数を減らした後、プロセッサ内のハッシュ テーブルのキー値の検索を高速化することができます。ハッシュ バケット サイズがプロセッサ キャッシュのサイズと等しい場合、キーを検索するとき、メモリ内の検索回数は最悪の場合 2 回になります。 1 回目はストレージ ユニットのアドレスを決定し、2 回目はストレージ ユニット内のキー値を見つけます。したがって、Nginx がハッシュ最大サイズまたはハッシュ バケット サイズを増やす必要があるというプロンプトを表示した場合、最初に行うことは、前のパラメーターのサイズを増やすことです。

クライアント リクエストのバッファ サイズです。ヘッダ。これは、システムのページング サイズに応じて設定できます。通常、リクエストのヘッダー サイズは 1k を超えないため、ページング サイズはここで設定されます。ページング サイズは、getconf PAGESIZE コマンドで取得できます。

large_client_header_buffers 8 128k;

クライアントリクエストヘッダーバッファサイズ。デフォルトでは、nginx は client_header_buffer_size バッファーを使用してヘッダー値を読み取ります。ヘッダーが大きすぎる場合は、large_client_header_buffers を使用してそれを読み取ります。

open_file_cache max=102400 inactive=20s;

このコマンドは、キャッシュが有効かどうかを指定します。キャッシュの最大数とキャッシュ時間も指定されます。 20 秒以上非アクティブになった後にクリアできるように、比較的長い最大時間を設定できます

open_file_cache_errors on off

デフォルト値: open_file_cache_errors off 使用するフィールド: http、server、location、このディレクティブは、ファイル ログ キャッシュ エラーを検索すると、

open_file_cache_min_uses

構文: open_file_cache_min_uses 数値 デフォルト値: open_file_cache_min_uses 1 使用フィールド: http、server、location このディレクティブは、無効なパラメーターの特定の時間範囲内で使用できる最小値を指定します。 open_file_cache ディレクティブ。より大きな値を使用すると、ファイル記述子は常にキャッシュ内で開かれます。 構文: open_file_cache_valid time デフォルト値: open_file_cache_valid 60 このディレクティブは、いつを指定します。 open_file_cache でキャッシュされたアイテムの有効な情報を確認します。

client_max_body_size 300m;

nginx を通じてアップロードされるファイルのサイズを設定します。

効率的なファイル転送モードを有効にします。ファイルを出力する機能により、ユーザー空間からカーネル空間へのコンテキストの切り替えが減少します。通常のアプリケーションではオンに設定し、ダウンロードなどのディスク IO 負荷の高いアプリケーションで使用する場合はオフに設定すると、ディスクとネットワークの I/O 処理速度のバランスをとり、システムの負荷を軽減できます。

tcp_nopush on;

このオプションは、sendfile を使用する場合にのみ使用されます。ハンドシェイクを開始するためのタイムアウトです。応答を待っています

proxy_read_timeout 180;

接続が成功した後、バックエンド サーバーが応答するまでの待ち時間。実際には、処理を待機しているバックエンド キューにすでに入っています (バックエンドの時間とも言えます)。

proxy_send_timeout 180;

バックエンドサーバーデータ 戻り時間は、バックエンドサーバーが指定された時間内にすべてのデータを送信する必要があることを意味します。

proxy_buffer_size 4k; 最初のバッファサイズを設定します。プロキシ サーバーから読み取られた応答の一部。通常、応答のこの部分には小さな応答ヘッダーが含まれます。デフォルトでは、この値のサイズは proxy_buffers ディレクティブで指定されたバッファーのサイズですが、より小さい値に設定できます。

proxy_buffers 4 32k;

は応答を読み取るように設定されます(プロキシサーバーのバッファの数とサイズから)、デフォルトはページングサイズでもあり、オペレーティングシステムに応じて4kまたは8kになる可能性があります

proxy_busy_buffers_size 64k;

高負荷時のバッファ サイズ (proxy_buffers*2)

proxy_temp_file_write_size 64k;

プロキシ サーバーの応答を一時ファイルにキャッシュする場合、このオプションは毎回書き込まれる一時ファイルのサイズを制限します。 proxy_temp_path (コンパイル時に指定可能) に書き込むディレクトリ。

proxy_temp_path /data0/proxy_temp_dir;

proxy_temp_path と proxy_cache_path で指定されたパスは同じパーティション内にある必要があります

proxy_cache_path /data0/proxy_cache_dirlevels=1:2keys_zone=cache_one:200m inactive=1d max_size=30g;

#メモリキャッシュスペースのサイズを200MBに設定し、1日間アクセスされなかったコンテンツは自動的にクリアされます。ハードディスクのキャッシュスペースのサイズは 30GB です。

keepalive_timeout 120;

秒単位の長い接続タイムアウト。このパラメータは非常に重要であり、ブラウザの種類、バックエンド サーバーのタイムアウト設定、およびオペレーティング システムの設定に関係します。長時間の接続で多数の小さなファイルが要求される場合、接続を再確立するコストを削減できます。ただし、大きなファイルをアップロードする場合は、65 秒以内にアップロードが完了しないと失敗します。セットアップ時間が長すぎてユーザー数が多い場合、長時間接続を維持すると多くのリソースが占有されます。

send_timeout 120;

は、クライアントに応答するためのタイムアウト期間を指定するために使用されます。このタイムアウトは、2 つの接続アクティビティの間の時間に制限されます。クライアント上で何もアクティビティがないままこの時間を超えると、Nginx は接続を閉じます。

tcp_nolay on;

は、データをキャッシュせずに少しずつ送信するように nginx に指示します。データを時間内に送信する必要がある場合、戻り値をすぐに取得できないように、この属性をアプリケーションに設定する必要があります。小さなデータ情報を送信するとき。

client_body_buffer_size 512k;

これを 256k などの比較的大きな値に設定した場合、Firefox または IE ブラウザを使用して 256k より小さい画像を送信するのは通常のことです。このディレクティブをコメント アウトし、オペレーティング システムのページ サイズの 2 倍 (8k または 16k) であるデフォルトの client_body_buffer_size 設定を使用すると、問題が発生します。

firefox4.0でもIE8.0でも、約200kの比較的大きな画像を送信すると500 Internal Server Errorが返されます

proxy_intercept_errors on;

は、HTTP応答コード400以上でnginxブロック応答を行うことを意味します。

アップストリーム ベイクエンド {

サーバー 127.0.0.1:8027;

サーバー 127.0.0.1:8029;

ハッシュ $request_uri;

}

これ負荷分散の問題を考慮して設計されている念頭に置いて。

nginx のアップストリームは現在、次の割り当て方法をサポートしています

1. ポーリング (デフォルト)

各リクエストは、時系列に 1 つずつ異なるバックエンド サーバーに割り当てられます。バックエンド サーバーがダウンした場合は、自動的に割り当てられます。排除された。

2. Weight

は、ポーリング確率を指定します。重みは、アクセス率に比例し、バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。

例:

upstream bakend {

server 192.168.0.14weight=10;

server 192.168.0.15weight=10;

}

3, ip_hash

各リクエストはハッシュ結果に従って割り当てられますのアクセス IP。このようにして、各訪問者はバックエンド サーバーに固定アクセスできるようになり、セッションの問題を解決できます。

例:

アップストリーム ベイクエンド {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

4. フェア (サードパーティ)

バックエンドサーバーリクエストを押す応答時間に応じて割り当てられ、応答時間の短いものが最初に割り当てられます。

アップストリームバックエンド{

serverserver1;

serverserver2;

fair;

}

5, url_hash (サードパーティ)

アクセスされたURLのハッシュ結果に従ってリクエストを分散し、各URLが同じバックエンド サーバーに送信されます。バックエンド サーバーがキャッシュである場合に、より効果的です。

例: 上流にハッシュ ステートメントを追加します。重みなどの他のパラメーターはサーバー ステートメントに記述できません。

hash $request_uri;

hash_method crc32;

}

#負荷分散デバイスの IP とデバイスのステータスを定義します

アップストリーム bakend{

ip_hash;

server 127.0.0.1:9090 down;

server 127.0 .0.1: 8080 Weight=2;

server 127.0.0.1:6060;

server 127.0.0.1:7070 Backup;

}

負荷分散を使用する必要があるサーバーに、

proxy_pass http:// bakend/;

各デバイスのステータスは次のように設定されます:

1.down は、前のサーバーが一時的に負荷に参加していないことを意味します

2.weight が大きいほど、負荷の重みが大きくなります。

3.max_fails: 許可されるリクエスト失敗の数のデフォルトは 1 です。最大数を超えると、proxy_next_upstream モジュールによって定義されたエラーが返されます。

4.fail_timeout: max_fails 失敗後の一時停止時間。

5.backup: 他のすべての非バックアップ マシンがダウンしているかビジー状態の場合、バックアップ マシンを要求します。したがって、このマシンの圧力は最も少なくなります。

nginx は、未使用のサーバーで使用するために、同時に複数の負荷分散グループを設定することをサポートしています。

client_body_in_file_only は、デバッグ用にクライアントの投稿からファイルに記録できます。

記録されたファイルのディレクトリを設定します。

location は URL と一致します。プロキシ負荷分散

##仮想マシンを構成する

server

{

listen 80;

listen ポートを構成する

server_name image.***.com;

Configureアクセスドメイン名

場所 ~* .( mp3|exe)$ {

「mp3 または exe」で終わるアドレスを負荷分散するための正規表現

proxy_pass http://img_relay$request_uri;

のポートまたはソケットを設定しますプロキシ サーバーと URL

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

上記3行の目的は、プロキシサーバーが受け取ったユーザー情報を実サーバーに転送することです


}


location /face {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

#これには、スペースが限られているため、Nginx の Rewrite ルールの問題が含まれます。次のセクション

proxy_pass http ://img_relay$request_uri;

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header

}

}


}

それもできます上記のことから、nginx.conf ファイルの主な形式は次のとおりであることがわかります。

…


サーバー


}

...

}

Nginx の構成は主要な機能です。これは、CSS ファイルのスタイル定義と比較できます。子要素は親要素のスタイル定義を継承し、同様の継承関係が nginx 設定にも存在します。

nginx 設定の継承モデルを理解するには、nginx 設定には複数のブロックがあることを知っておく必要があります。たとえば、サーバー コンテキストで定義された命令は、server{} ブロックに保存されます。 http コンテキスト内 定義された命令は http{} ブロックに保存されます。

nginx には 6 つの可能なコンテキストがあり、高位から低位の順序は次のとおりです:

グローバル

Http

サーバー

If

Location

ネストされた場所

位置内の場合

limit_excel

デフォルトの継承モデルの方向は、水平方向または逆方向ではなく、下位層が上位層を継承することです。一般的なシナリオでは、書き換え要求がある場所から別の場所にジャンプすると、最初の場所ブロックで定義された命令は無視され、2 番目の場所ブロックで定義された命令のみが場所コンテキスト内に有効になります。ここで簡単に言及しただけです。

実際、Nginx の設定はこれらだけではなく、他にもあります。結局のところ、Nginx には多くのモジュールがあり、各モジュールにはいくつかの特別な設定コマンドがある場合があります。ここでは、いくつかの基本的な設定情報についてのみ説明します。より深く、そして段階的に追加してください。間違いがあれば批判して修正してください。

声明：
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
前の記事：コンパクトなクラス ソリューション次の記事：コンパクトなクラス ソリューション

関連記事

続きを見る