はじめに Railsアプリケーションの開発において、Nginxを前段に置くべきかどうか疑問に思っていました。 私が調べた限りでは、Nginxがなぜ必要なのか？といった必要である理由を書いている情報は見つかるのですが、無くても良い場合という情報があまり見つかりませんでした。 確かに2020年くらいまでは本番運用する際には、Nginxを前段に置いた構成が一般的だったと思います。 この記事では、Railsの生みの親であるDHHのコメント等を紹介しつつ、RailsアプリケーションにおいてNginxが本当に必要かどうかについて考察してみたいと思います。 Railsの設定はどうなっているのか Railsには以下のように、環境変数によってpublic/assetsなどの静的ファイルをRailsが配信するか設定できる機能がありました。 config.public_file_server.enabled =
F5、NGINXの開発チームをロシア国外へ移転させたことを報告。開発を立て直しリリースサイクルも元通りに NGINX（エンジンエックス）はオープンソースで開発されているWebサーバとしてもっとも人気のあるソフトウェアの1つです。その開発者であるIgor Sysoev（イーゴリ・シソエフ）氏がロシアの首都モスクワに住んでいたことなどにより、NGINXの開発はロシアの首都モスクワを中心に行われていました。 そのロシアは現在、ウクライナへの武力侵攻に反対する西側諸国による厳しい経済制裁下にあり、多くのIT企業もロシアにおける活動を停止しています。 2019年にNGINX社を買収し現在NGINXの開発元となっているF5も、ロシアにおける営業活動とNGINXオープンソースプロジェクトへの貢献を停止したことを、3月15日付けのブログ「Standing Firm in Support of the Pe
nginxはworkerプロセスの数をCPUコア（スレッド）数で決定するworker_processes autoという便利設定があります。 これが多用されているのは、nginxがノンブロッキングでリクエスト処理を行うため、コンテキストスイッチなどを考慮した場合に、コア数で立ち上げておけば効率よくCPUを使い切れるという前提があるからです。 一方で、例えば僕の用途では、現在画像の処理だったりとか、ngx_mrubyのようにリクエストの過程で一部ブロッキングされるような処理も増えてきているため、コア数以上の値に設定しておいた方が性能を発揮できるような状況も増えてきています。 そうなると、現状、非常に便利な設定であるauto設定を使えずに静的に数字を設定する必要があり、例えばサーバリプレース時には古いコア数を考慮した値になっていたりして、リプレース後にCPUのコア設定がそのままで性能が出せてい
Puma worker数 workerはCPUのコア数に依存する物理スレッドを示しています。ここで大事なのは、worker数を サーバーのCPUコア数より大きくはしないことです 。 Pumaのworker数は、次のthread数に関係してくるので次で述べます。 thread数 threadは1worker内での論理スレッド数を示しています。 1worker/16threadの場合、計16thread 2worker/16threadの場合、計32thread 1worker内の最大thread数は、ここにも書いてあるように 16 より大きくしないほうが良さそうです。 ※workerとthreadの関係はこちらに記載 実際に設定ファイルに書くときは、2worker/16threadの計32threadの場合は以下の通りに書いてください。 実験を行った結果、もちろんサーバーのリソース(今回はC
nginxのせいでDisk Fullになってアクセス不能になった件
正直恥ずかしい話ですし、Disk監視ちゃんと入れておけば防げる話です。 AWSのEC2でnginx動かしていたら、Disk使用率が100%になってレスポンスが返せなくなりました。 原因はnginxが巨大なログファイルを出力していたためなのですが、 dfだとdiskが喰われているのに、/に移動してdu -sh *でディレクトリごとの使用量を見てみても、 どこがdiskを喰っているのかわかりませんでした。 そこで何かのプロセスがファイルをつかんでいるだろうと調べたところ、nginxが巨大なログファイルをつかんでいました。 なぜそれがduでわからなかったかというと、実際のファイルは存在していなかったからです。 nginxの起動ユーザーはec2-userになっていたのですが、nginxはyumでインストールしたものなので、 log出力先のディレクトリのオーナーがnginxユーザーになっており、 ロ
Nginxのアーキテクチャについて調べてたことをまとめた。 用語のおさらい プロセス（Process） プログラムの実行単位であり、CPU時間単位で割り振られる。 状態(ステート)があり、現在処理中であるRunning状態だったり、実行可能状態であるReady等が存在する。 CPUがプロセスを実行する場合、そのプロセスが持つメモリデータに対して演算を行う。 プロセスはテキストセグメントとデータセグメントからなる構造データをメモリ上に持っている。 テキストセグメント プログラムの命令列 データセグメント PDA (Processor Data Area)と呼ばれる、プロセッサの情報やプロセス管理用のデータ領域 データ領域と呼ばれる、定数等が置かれる静的領域と、通常の変数等が置かれるヒープ領域からなる領域 スタック領域と呼ばれる、一時的なデータ保管領域 実行中のプロセスを確認 スレッド（Thr
Knowledge というオープンソースのソフトウェアを使用しているのですが、その中でファイルをアップロードしたところ「アップロードに失敗しました」とメッセージが表示されアップロードできませんでした。 原因を調べたところ nginx のデフォルトが 1M までということが分かり、 client_max_body_size を適切に設定することで対応することができました。 Knowledge は次の環境で運用しています。 nginx tomcat サーバで取り扱うサイズの変更 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size によると、 nginx ではデフォルトで1MBまでのデータしか受け付けない設定になっています。 nginx が1MBより大きなデータを扱えるようにするには、 conf
はじめに 本日の08：00～09：30頃まで当サイトが404エラーでページが表示されなくなっていました。 nginxの再起動をしたところ、この状態になってしまいました。 エラーログを確認 エラーログを確認したところ下記のようなエラーが発生していました。 [crit] open() "/hogehoge_html/DocumentRoot/index.php" failed (13: Permission denied), client: xxx.xx.x.xx, server: www.kabanoki.net, request: "GET / HTTP/1.1", host: "www.kabanoki.net" ファイルのパーミッションを変更 エラーのログに(13: Permission denied)とあるので、権限に問題があるのかな？と試しにindex.phpのパーミッションを77
![[nginx]open() failed (13: Permission denied)で泣きそうになった | カバの樹](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e27be41d0c9678f2420aa2e9064c73b01c4a396/height=288;version=1;width=512/https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fwww.kabanoki.net%2Fwp-content%2Fuploads%2F2019%2F05%2F0d40a5e4a645fc6b96e767d64ac0878e-1.png)
アクセス権限は、 ・ディレクトリには実行権限 ・ファイルには読取り権限 を付与すれば大丈夫なはずですが、このようなエラーが出てしまいました。 [error] 4418#0: *9 open() "/home/ec2-user/www/index.html" failed (13: Permission denied)ディレクトリ・ファイルの所有者やグループをrootに変更してもダメです。 とりあえずの解決案 基本的に、ルートディレクトリの場所がユーザーのホームディレクトリに設定されているとエラーになります。 （というのはちょっと語弊があります。エラーになる理由はこちら） ✖ダメな例 location / { root /home/[ユーザー名]/www; index index.html; }※デフォルトだと「/home/[ユーザー名]/」のパーミッションが700なので、701に変更すれば
概要 nginxを初めて使ってみましたが、 色々ハマりどころがあったため、メモを兼ねて投稿します。 Owner問題 これはnginxに限った問題ではないかもしれませんが、 使用するフォルダがnginxの実行ユーザになっている必要があります。 例えば、centosの場合だと /var/lib/nginx などですね。 ここがうまくいっていないと ダウンロードの処理などを入れた時に failed (13: Permission denied) while reading upstream というエラーがnginxから吐き出されます。 解決手法 sudo chown -R [nginxの実行ユーザ名] /var/lib/nginx ここはもしかしたらOwnerを変えすぎなのかもしれませんが、 そこまで検証をしていません。 もしそういう指摘などありましたら、コメントください。 Permission
Centos7 + Nnginx 1.10.3 でerror.logを見てみると 2017/02/17 10:51:27 [crit] 17910#17910: *1 stat() "/home/user/sample/html/" failed (13: Permission denied), client: xxx.xxx.xxx.xxx, server: sample.com, request: "GET / HTTP/1.1", host: "sample.com", referrer: "https://sample.com" といったエラーがたくさん.. ディレクトリのパーミッションを見てみても $ ls -al /home/user/sample/html/ drwxrwxr-x 7 user nginx 4096 2月 16 12:10 . な感じで問題なさそう いろいろ調
defaultは60秒 sudo vi /etc/nginx/nginx.conf httpブロックのタイムアウト時間を変更する（秒） http{ ... proxy_read_timeout 300; proxy_connect_timeout 300; proxy_send_timeout 300; ... } 特定のサーバだけ、時間変えたい時 server{ ... proxy_read_timeout 300; proxy_connect_timeout 300; proxy_send_timeout 300; ... } 再起動 sudo systemctl restart nginx 確認 systemctl status nginx
Enables or disables the use of asynchronous file I/O (AIO) on FreeBSD and Linux: location /video/ { aio on; output_buffers 1 64k; } On FreeBSD, AIO can be used starting from FreeBSD 4.3. Prior to FreeBSD 11.0, AIO can either be linked statically into a kernel: options VFS_AIO or loaded dynamically as a kernel loadable module: kldload aio On Linux, AIO can be used starting from kernel version 2.6.2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
