カテゴリー: Linux

Nginxでのリクエストとレスポンスのバッファサイズのチューニング

Nginxで運用しているWEBサーバーに画像ファイルをアップロード（フォームからのPOSTを）した際、「413 Request Entity Too Large」と表示されてアップロードができませんでした。

これはどうやらnginxがデフォルトで受信できるリクエストサイズが小さいためにエラーとなっているようです（デフォルトでは1メガバイトのようです）。この画面が表示されたときのnginxのerror.logには「client intended to send too large body」と出力されていました。受信できるリクエストサイズを拡張するにはclient_max_body_sizeディレクティブに適切な値を設定する必要があるとのこと。画像ファイルのアップロードにはPHPを使用しており、php.iniの中のupload_max_filesizeで最大2メガバイトと指定しているので、client_max_body_sizeには2メガバイト以上を指定することにしました。

この設定で画像のアップロードはできるようになったものの、error.logには「a client request body is buffered to a temporary file」のワーニングが表示されていました。気持ちが悪いので、このワーニングも対処することにします。調べてみるとclient_body_buffer_sizeディレクティブに適切な値を設定することで解消するらしい。client_body_buffer_sizeのデフォルト値は64ビットOSの場合は16キロバイトが一般的でリクエストサイズがこれを超えた場合にワーニングを出力するとのことです。このサイズを超えたリクエストはバッファに収まらないので一時ファイルに出力したことをワーニングとして示しているようです。デフォルト値ではあまりにも小さいので思い切ってアップロード可能な画像サイズまで引き上げました。一時ファイルを出力することはディスクI/Oが発生して処理時間が長くなってしまいますので。

なお、この一時ファイルはディスク上のファイルではなくメモリ上のファイル(tmpfsという)も指定可能なようです。tmpfsを使用すればディスクI/Oは発生しないので良いように思えるのですが、リクエストサイズがtmpfsの容量を溢れてしまうとスワップ領域に一時ファイルが書き出されてしまうということでtmpfsの使用はやめました。ちなみに一時ファイルの出力先の指定はclient_body_temp_pathディレクティブで指定できるとのことです。tmpfsはディスク容量を確認する際に使用するdfコマンドで確認できます。

ちなみに先ほど書いた「a client request body is buffered to a temporary file」のワーニングですが、初期設定のnginxでWordPressを運用していると必ず出てしまうようですね。。

これで画像ファイルのアップロード時のエラーおよびワーニングは出なくなりました。なので、いったんこれで様子見をしようと思います。

まとめ。リクエストのバッファリングに関する設定は以下をチューニングする。

client_max_body_size
受信できる最大リクエストサイズ。デフォルトでは 1M 。

client_body_buffer_size
メモリ上のバッファに読み込む最大リクエストサイズ。デフォルトでは 8k or 16k（使用するOSにより変わる）。このサイズを超えるリクエストだった場合はclient_body_temp_pathに指定された一時ファイルにリクエストを書き出す（ディスクI/Oが発生する）。

client_body_temp_path
バッファの代わりとして使用する一時ファイルの出力先。

[広告]

ここからはリクエスト時のバッファサイズについて調べているうちにわかったことを覚え書きとして残しておきます。nginxではリクエストだけではなくレスポンスのバッファについても設定ができるようになっています。レスポンス時のバッファって何のこと？と最初は思ったのですが、PHPやCGIを処理するFastCGIサーバーからのレスポンスのバッファリングのことだと理解しました。

nginxではPHPやCGIを処理する際、fastcgi_passディレクティブでFastCGIサーバーのIPアドレスとポートを指定します。

FastCGIを使っている場合のレスポンスのバッファリングに関する設定は以下のようなものがあります。

fastcgi_buffering
バッファリングを有効にするかどうかの設定。デフォルトでは有効となっている。

fastcgi_buffer_size
一番最初のレスポンスをバッファリングする際のサイズを指定する。デフォルトでは 4k or 8k（使用するOSにより変わる）。

fastcgi_buffers
fastcgi_buffer_sizeにレスポンスが収まりきらなかった場合、fastcgi_buffersを使用する。デフォルトでは 8　4k or 8k。4キロバイトもしくは8キロバイト（使用するOSにより変わる）の領域を最大8個使用するという意味。

fastcgi_busy_buffers_size
FastCGIサーバーからのレスポンスを受信しているときの最大バッファサイズ。デフォルトでは 8k or 16k（使用するOSにより変わる）。fastcgi_buffersと同じにするか、2倍程度にするのが一般的らしい。

fastcgi_max_temp_file_size
FastCGIサーバーからのレスポンスがバッファから溢れたときに書き出される一時ファイルの最大サイズ。

デフォルトだとfastcgi_buffer_size、fastcgi_buffersがかなり小さくメモリ上のバッファが足りなくなった場合は一時ファイルに書き出すとのこと。その際、「an upstream response is buffered to a temporary file」のメッセージがerror.logに出力されるらしい。ところがFastCGIサーバーからのレスポンスがどう考えてもfastcgi_buffer_size、fastcgi_buffersのバッファサイズを超えていると思われるのだけれど、このメッセージがerror.logに出力されていない。画像ファイルをレスポンスにしているからかなりのサイズだと思うのだけれど。これについて思い当たるのは以下の2点ということに考えが至りました。

  • 上の絵ではnginxとFastCGIサーバーは別々のサーバーとしていますが、実際の僕の環境はnginxとFastCGIサーバーはUnixソケットを通じて同一のサーバーでデータ連携をしている。これがバッファリング時のエラーを回避させているのか？
  • 上の絵ではnginxはWEBサーバーであってリバースプロキシの役割は持たせていない。nginxをリバースプロキシとして運用する場合はproxy_passディレクティブを設定してプロキシ先を指定するが、そのような構成ではない。レスポンス時のバッファリングのエラーはプロキシとして運用したときの場合のものか？

ちなみに2点目にあるリバースプロキシとしてnginxを運用する場合は以下のディレクティブでバッファリングに関する設定を行います。FastCGIのときの意味合いとほぼ同じだと思っているのですが。。

proxy_buffering
proxy_buffer_size
proxy_buffers
proxy_busy_buffers_size
proxy_max_temp_file_size

「an upstream response is buffered to a temporary file」が発生しない理由はよくわからないのですが、とりあえず上手くいっているようなのでFastCGIのレスポンスのバッファリングの設定はデフォルトのままとしています。

最後にFastCGI系とプロキシ系のレスポンス時のバッファリングに関するディレクティブの説明（nginxの公式サイト）を載せておきます。

・FastCGI系
・プロキシ系

スポンサーリンク

ubuntuにインストールしたnginxでCGIを動かしてみた。

ubuntuにインストールしたnginxでCGIを動かしてみました。もともとApacheで動いていたCGIスクリプトをnginxで動くようにしています。環境は以下です。作業はrootユーザーで行いました。

【環境】
ubuntu 18.04 LTS
nginx 1.16.1

まず、nginxでCGIを動かすためにはfcgiwrapが必要なのでインストールします。

fcgiwrapのインストール
# apt install fcgiwrap

パッケージのインストールができたらfcgiwrapを確認してみます。

インストールされたパッケージの確認
# dpkg -l | grep cgi

僕の環境では赤枠で囲ったパッケージがインストールされたようです。

[広告]

fcgiwrapの設定を確認します。fcgiwrapでは設定ファイルのようなものはないらしく、/etc/init.d配下にある起動スクリプトを確認します。

fcgiwrapの起動スクリプトの場所
/etc/init.d/fcgiwrap

この起動スクリプトに記載されている設定の中で確認する項目の抜粋（以下はデフォルト値）です。


　：
NAME="fcgiwrap"
　：
# FCGI_APP Variables
FCGI_CHILDREN="1"
FCGI_SOCKET="/var/run/$NAME.socket"
FCGI_USER="www-data"
FCGI_GROUP="www-data"

# Socket owner/group (will default to FCGI_USER/FCGI_GROUP if not defined)
FCGI_SOCKET_OWNER="www-data"
FCGI_SOCKET_GROUP="www-data"
　：

最初に、

NAME=”fcgiwrap”
FCGI_SOCKET=”/var/run/$NAME.socket”

ですが、これはnginxとfcgiwrapとのデータの受け渡しの方法です。nginxでは静的コンテンツしか処理できずCGIのような動的コンテンツはfcgiwrapが行うことになるのですが、CGIへのリクエストをnginxからfcgiwrapにどのような方法で受け渡すかを設定します。受け渡しの方法にはUnixソケットを使う方法とTCP/IPを使う方法があるのですが、デフォルトの設定ではUnixソケットを使う方法となっています。一般的にnginxとfcgiwrapを動かすサーバーが同一であればUnixソケットを使ったほうが効率がよいです。ですので、FCGI_SOCKETの設定はこのまま（デフォルトのまま）とします。

実際に、/var/run配下にfcgiwrap.socketがあるかどうか確認してみると以下のようにありました（緑線の部分、ピンク色線については後述）。

次に、

FCGI_CHILDREN=”1″

ですが、これはfcgiwrapがリクエストを待つ待機プロセスの数です。fcgiwrapはこの数分のプロセスを生成(C言語でいうfork)をしていて、リクエストが連続で来た際に待ちを作らずに並列に処理を裁ける数となります。本来はリクエスト数とサーバー性能を考慮してチューニングするべきですが、ここではいったんデフォルトのままとしておきます。

続いて、

FCGI_USER=”www-data”
FCGI_GROUP=”www-data”

ですが、これはfcgiwrapを実行するユーザー、および、グループを設定します。ここにはCGIスクリプトを実行できるユーザーを設定するのですが、ubuntuでApacheを動かす際は一般的にwww-dataを使用していて、今回はApacheで動かしていたCGIスクリプトをそのまま動かす想定なのでwww-dataのままとしておきます。

最後に、

FCGI_SOCKET_OWNER=”www-data”
FCGI_SOCKET_GROUP=”www-data”

ですが、これは先ほど記載したfcgiwrap.socketの所有者、および、グループの設定です。記載がなかった場合はFCGI_USER、FCGI_GROUPと同じになると起動スクリプトのコメントには記載されていました。こちらもデフォルトのwww-dataのままとしていたのですがfcgiwrap.socketの所有者、グループはrootになっていました（fcgiwrap.socketを確認した際のピンク色の線のところ）。ここのところの差異の理由は、ちょっとわかりませんでした。所有者はrootですが、www-dataでも読み書きできる権限となっているため問題ないのかもしれません。

fcgiwrapの設定の確認はここまでです。結果的にですが、fcgiwrapの設定は何も変えずにデフォルトのままで行きます。引き続き、nginxの設定に入ります。

[広告]

nginxの設定ファイルにCGIスクリプトへのリクエストがあった場合の動きを記載します。記載する設定ファイルはnginx.conf、もしくは、conf.d配下のconfファイルです。

nginxの設定ファイルの場所
/etc/nginx/nginx.conf
/etc/nginx/conf.d 配下のconfファイル

※nginx.confがconf.d配下のconfファイルを読み込んで（includeして）います。

記載する内容は以下です。serverディレクティブの中に記載してください。


location ~* \.cgi$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.cgi)(/.+)$;
    include fastcgi_params;
    fastcgi_index index.cgi;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_intercept_errors on;
    fastcgi_pass unix:/var/run/fcgiwrap.socket;
}

この中で一番最後にあるfastcgi_passの設定が、nginxからfcgiwrapにUnixソケットを使用してデータを引き渡す、という設定になります。他の設定はパラメータファイルのインクルードとか404エラーファイルの出力などですが、細かい説明は省略します（すみません）。そのまま貼り付けてもらえれば動くはずです。。

上記を反映した僕の場合のserverディレクティブを載せておきます。

nginx.confにnginxを動かすユーザーが記載されているのですが、そのユーザーをnginxからwww-dataに変更しておきます。nginx.confの「user」という項目です。

変更前
user nginx;
　↓
変更後
user www-data;

以上でnginxのconfファイルの修正は終了です。confファイルのテストを行います。

confファイルの確認
# nginx -t

「syntax is ok」および「test is successful」と表示されれば問題ありません。今回はfcgiwrapの設定は変えていないのでnginxの再起動のみ行います。

nginxの再起動
# systemctl restart nginx

nginxでCGIスクリプトにアクセスしてみてください。動くと思います。

スポンサーリンク