Why does one NGINX worker take all the load?
Why does one NGINX worker take all the load?10/23/2017 Scaling up TCP servers is usually straightforward. Most deployments start by using a single process setup. When the need arises more worker processes are added. This is a scalability model for many applications, including HTTP servers like Apache, NGINX or Lighttpd. CC BY-SA 2.0 image by Paul Townsend Increasing the number of worker processes
徒然なるままに｜epollの使い方 ~I/O Multiplexing~
多重I/O(I/O Multiplexing)について勉強する機会があったのでメモ。 具体的な使用方法の前に多重I/Oについての前置き。 多重I/Oとは、複数のプロセスにread(recv)要求を行っている状況において 順番を気にせず、読み込みが完了したプロセスから順次読み込んだデータを使って処理する場合に使う。 いわゆるイベント駆動型動作であり、一つでも読み込みが完了していれば まだ読み込みが終了していないプロセスのread待ちによるブロックがない。 例えば１００プロセスとの通信で、ファイルディスクリプタを１００個所持している状況を考えよう。 １つのプロセスからの入力を待って、入力が来たら、次のプロセスからの入力を待って、・・・として 全てのプロセスからデータを読み込むのは非常に非効率である。 そこで１００個のファイルディスクリプタを監視して、 読み込みイベントがあったファイルディスクリ
【Nginx】ulimit設定変更（ worker_connections exceed open file resource limit:）エラー | インフラエンジニアの技術LOG
Nginxをインストール後、コンフィグファイルで最大コネクション数を設定（worker_connections）した後、サービスを再起動時にエラーが吐かれます。 # vim /etc/nginx/nginx.conf events { worker_connections 5000; Nginx再起動後に以下の用にエラーを吐く # service nginx restart nginx: [warn] 5000 worker_connections exceed open file resource limit: 1024 nginx を停止中: [ OK ] nginx を起動中: nginx: [warn] 5000 worker_connections exceed open file resource limit: 1024 [ OK ] そんなときの設定対処手順を紹介します。 u
第8章 ソケット
ソケット とは双方向のデータ転送メカニズムです。 2 つのプロセス間でのデータ転送に使用されます。 2 つのプロセスは Unix 領域またはループバックソケットとして同じシステムで実行していも、 ネットワークソケットとして別のシステムで実行していても構いません。
4.4. TCP_NODELAY と小さなバッファ書き込み
TCP (Transmission Control Protocol) で簡単に説明したように、デフォルトでは TCP は Nagle アルゴリズムを使用して小さな送信パケットを収集して一度にすべてのパケットを送信します。 これにより、 レイテンシに悪い影響が出ることがあります。
Tuning NGINX for Performance
NGINX is well known as a high‑performance load balancer, cache, and web server, powering over 40% of the busiest websites in the world. For most use cases, default NGINX and Linux settings work well, but achieving optimal performance sometimes requires a bit of tuning. This blog post discusses some of the NGINX and Linux settings to consider when tuning a system. You can tune almost any setting, b
Nginxのインストールと基本設定
処理能力の高さなどを理由に、近年、大規模サイトを中心に急速にシェアを拡大しているWebサーバー「Nginx」について紹介します。連載第2回では、インストール方法と基本的な設定内容を解説します。 連載目次 Nginxのインストール手段 Nginxをインストールする方法は主に2通りあります。ソースファイルをビルドする方法とバイナリパッケージを利用する方法です。 ソースファイルを使ってインストールすると、無駄なモジュールを省いてバイナリを最適化できたり、インストールパスや設定ファイルのパスをカスタマイズできたりしますが、開発環境を用意する必要があります。 バイナリパッケージを使えばインストールやアップデートが手軽に実行でき、ディストリビューションのパッケージツールで一元管理できますが、バイナリの最適化やインストールパスのカスタマイズはできません。 用途に応じた適切なインストール方法については表1
Nginxでyumリポジトリサーバーを作る時 - tsunokawaのはてなダイアリー
これまでこういったyumリポジトリミラーサーバーを作る場合にApacheを使って構築してきましたが、 Nginxで同じように設定する場合のメモです。 Nginxの設定 /etc/nginx/nginx.confにautoindex on;を追加します。 例 server { listen 80; server_name repo.example.com; location / { root /var/www/html/; autoindex on; autoindex_localtime on; } } 表示結果 このように表示されます。 Apacheの場合 ちなみにApacheの場合 <Directory "/var/www/html/"> Options Indexes FollowSymLinks </Directory> 参考 HttpAutoindexModule http://
Nginx導入時、サクッと対応しておくと良いかもしれない - Qiita
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要？ 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
[nginx]S3をバックエンドにngx_small_lightで画像を動的にリサイズ
S3 で公開しているバケットをバックエンドに nginx モジュール ngx_small_light を利用して画像をリサイズする方法をメモ http://d.hatena.ne.jp/akishin999/20130619/ にローカルの画像を対象にした画像変換手順が書かれているので、そこに S3 バックエンドを追記しただけとも言える。 ngx_small_light について github で公開 https://github.com/cubicdaiya/ngx_small_light pixiv の中の人が開発した nginx モジュール Apache 向け mod_small_light の nginx 移植 https://code.google.com/p/smalllight/ 画像変換エンジンは ImageMagick/Imlib2/GD から選択可能 構成 client
![[nginx]S3をバックエンドにngx_small_lightで画像を動的にリサイズ](https://cdn-ak-scissors.b.st-hatena.com/image/square/558d53bd8632c04537f9b0ff297877a64b26b110/height=288;version=1;width=512/https%3A%2F%2Fsiguniang.files.wordpress.com%2F2014%2F01%2Fbenchmark1.png)
TCP Fast Openを試してみる - milieuの日記
kernel3.8がリリースされてついにTCP Fast Openがクライアント、サーバサイド共に実装さた。カーネルのソースを見てみるとやはり結構な変更でpatchで2000行レベルらしく、これ仕事で実装したくないなーというかバグを出す自信があるというのが正直な感想だが、とりあえず動作概要ぐらいは知っておかないとまずいので遊んでみた。TCP Fast Openの認証？部分でAESを使うらしくSandy BridgeならAES-NIを使えばCPU負荷的に問題ないかとか調べたかったが、家で使用しているPCはCPUが残念ながらWestmereなのでそれは諦めた。動かすにあたりFedora18を用意しないと！と思いたちVM環境にインストール。そういえばFedora18がリリースされた当初はVMwareにインストールを試みたが失敗したという苦い記憶が蘇えったが、今回はVirtualboxだったおかげ
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
nginx で Too many open files エラーに対処する
nginx では1プロセスで多くのアクセスを捌くので、アクセス数が増えるとToo many open filesエラーが発生することがあります。 ここでは対処法と調べた内容を残しておきます。 1. fs.file-max の確認 まず fs.file-max の値を確認しておきます。fs.file-max は、システム全体でのファイルディスクリプタの上限数となっており、この値以上のファイルディスクリプタは確保することができません。 現在設定されている値は以下で確認できます。 $ cat /proc/sys/fs/file-max 167488 通常は上記の値で問題無いと思いますが、もしこの値が不足しているようなら設定値を更新します。 $ sudo -s # echo 320000 > /proc/sys/fs/file-max # cat /proc/sys/fs/file-max 320
Optimising NginX, Node.JS and networking for heavy workloads
9 Min Read Optimising NginX, Node.JS and networking for heavy workloads Used in conjunction, NginX and Node.JS are the perfect partnership for high-throughput web applications. They’re both built using event-driven design principles and are able to scale to levels far beyond the classic C10K limitations afflicting standard web servers such as Apache. Out-of-the-box configuration will get you prett
Isucon用Webサーバーrecaro : DSAS開発者の部屋
11/3に開催された #isucon2 に、隣の席の @pandax381 と一緒に、チーム双龍として参加してきました。 結果は惨敗だったのですが、そのレポートを書く前に、 #isucon2 で使う予定だった秘密兵器 recaro について紹介します。 recaro とは recaro はカーネル空間で動く httpd + memcached サーバーです。 httpd サーバーは @pandax381 が作成した tkhttpd で、 memcached は kmemcached というプロジェクトが 未完成のまま放置されていたのを見つけて、私がデバッグ＆高性能化したものです。 (KLab/kmemcached) 通常のnginx+memcachedだと ネットワーク <- TCP/IP ]-> nginx <-[ TCP/IP ]-> Memcached ([] はシステムコール) と
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
nginx連載3回目: nginxの設定、その1
ディレクティブはこのモジュールのカテゴリ毎に記述します。ただし、coreモジュールに関してはmainコンテキスト、すなわち、設定ファイル内の最上位の階層に記述します。設定ファイルの構成は次のようになります。 coreモジュールの設定 events { eventモジュールの設定 } http { httpモジュールの設定 } mail { mailモジュールの設定 } httpコンテキストはさらに、バーチャルサーバ（バーチャルドメイン）毎の設定を行うserverディレクティブ、さらにURI毎の設定を行うlocaltionディレクティブにより階層化されます。次のような構成になります。 http { httpモジュールの設定 server { サーバ毎の設定 location PATH { URI毎の設定 } location PATH { URI毎の設定 } ... } server { .
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
画像変換Night - 資料一覧 - connpass
Nginx バージョンアップ動向（2014/01〜2014/12）
nginx入門
