インターネットサーバでのPthreadとepoll（1）
本連載ではシステムコールプログラミングの例も掲載していく予定ですが、本記事ではLinuxに追加されたepollを採りあげ、インターネットサーバでのPthread利用と比較してみます。 はじめに マルチスレッドプログラミングが普及し、POSIX threadも制定され、Pthreadの利用は目新しいものではなくなりましたが、スレッドにまつわる迷信や誤った認識を、だいぶ減ったとはいえ、今でもたびたび耳にします。例として、 スレッドはプロセスよりも軽いので、多数作成しても軽快に動作する スレッドはプログラミングを簡単にしてくれ、1つの処理だけに集中できる などがあります。しかし、これらは常に真であるとは限りません。本記事ではマルチスレッドの概念や入門を繰り返すのではなく、その利用方法をHTTPサーバのサンプル実装を基に考察します。更にLinuxに追加された独自機能のepollインタフェースを用い
listen backlog 【3.6】 - Linuxカーネルメモ
(*1) backlog(512)はtcp_max_syn_backlog(400)より大きいので、400を切り上げた512がsyn backlogのサイズになる。 syn backlogのサイズを大きくしようとするには、以下の点に注意する。 (a) net.ipv4.tcp_max_syn_backlogを大きくする (b) listen()で指定するbacklog値を大きくする(apacheならListenBackLogディレクティブで指定できる) (c) backlogの値自体はnet.core.somaxconnに切り詰められるため、net.core.somaxconnの方も大きくしておく。 syn backlogの最大サイズはbacklogサイズに基づいて決まるため、net.ipv4.tcp_max_syn_backlogを大きくするだけでなく、backlog自体が大きくなるよう
Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング
もう半年くらいフルDockerでmicroservicesなサービスを運用してるんですが、イマイチパフォーマンスを出し切れていないなという面がありまして、今回DockerホストのTCPカーネルパラメータを抜本的に見直しました。 そしたら劇的に症状が改善して、インスタンス数も削減できた上に安定してメシウマ状態になったので紹介します。実際効果があったのでチューニングポイントとしてはある程度正解であったと考えていますが、もちろん扱ってるアプリケーションの特性にもよるはずなので一つのケーススタディであることをご了承頂ければと。 前提 まずは今回のお話の前提を。こんな環境です。 EC2 c3.xlarge ホストはUbuntu（EC2 Optimized AMIは未使用） Docker 1.11.2 MySQL（HAProxy経由）やRedisへのデータストアの通信、各microservicesへの
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
tcp_tw_なんとかの違い - Qiita
自分用の覚書です。CentOS5とか6とかでの経験。 実際高負荷だとか負荷試験ツールで出ただとかのTIME_WAITを減らしたいというときに、 syctlで、tcp_なんとかを調整するというのは今ではよくあると思います。 （わたしはむかし運用していた某無料サイトで負荷に悩んだのが切欠で知りました。無料というだけで会員数激増的な風潮だったのと素行の悪い某国のクローラーとかrewriteのループとかの色々な芸の肥やし的な機会がというか夜中に起こされて眠りを妨げられたくなかったので色々調べたりしていました。） いっぱい接続したいの - (ひ)メモ Linux - ぜんぶTIME_WAITのせいだ！ - Qiita ・TCPの終了待ちタイムアウト秒数を設定（default60sec) net.ipv4.tcp_fin_timeout = 10 ソケットを強制的にクローズする前に、最後のFINパケッ
Introduction · Linux Inside
linux-insides A book-in-progress about the linux kernel and its insides. The goal is simple - to share my modest knowledge about the insides of the linux kernel and help people who are interested in linux kernel insides, and other low-level subject matter. Feel free to go through the book Start here Questions/Suggestions: Feel free about any questions or suggestions by pinging me at twitter @0xAX,
小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 | gihyo.jp
RubyKaigi 2015レポート 小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 12月11日～13日、ベルサール汐留にて「RubyKaigi 2015」が開催されました。今年も基調講演が毎日一つずつ行われました。その模様をレポートします。 RubyKaigi 2015 2日目の基調講演は、世界で唯一の、LinuxのコミッタでありRubyのコミッタでもある小崎資広さんです。今回、小崎さんは「Linux loves Ruby. Ruby Loves Linux - How to debug your linux box」と題して、発表しました。 Linux portメンテナのお仕事 小崎さんは、Ruby Core Teamでの自分の役割を「Linux Portメンテナ」と称し、これまでの仕事の内容を紹介しました。
kernelチューニング
linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作：pidの最大数 設定値：131072 理由：pidを枯渇させない vm.max_map_count 動作：mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値：300000 理由：マッピングできなくなる事態を防ぐ net.core.somaxconn 動作：接続(ソケット)キューの
SYN ACKが返ってこない太郎
すげ、こまったお。 LBの配下に、WEBサーバ(apache)を複数台置いて画像を配信してたら MAC(OS X10.8.6)、ubuntu(11.04)で画像が見れたり、見れなかったり。 状況kwsk ・LBの振分ルールはラウンドロビン。 ・LBからWEBサーバに対しては、SNATしてる。 ・WEBサーバは常時2000コネクションくらい張っているんだけど 接続がまったくない状態でも同じ現象が発生する。 ・逆にWEBサーバが1台やら2台だと再現しない。 ・上記端末から、画像取得ができない(WindowsXP、Vista、7)はさくさくいける。 ・ブラウザ依存じゃなかった(Firefox、Opera、Safari、Choromeでもだめ) ・IPV6はONでもOFFでもでる。 ・Wiresharkでキャプチャしたら、SYN+ACKが返ってこない・SYNのリトライたくさん。 原因は・・・ ・サ
システムコールについてどれくらいご存じですか？
システムコールについてどれくらいご存じですか？：知ってトクするシステムコール（1）（1/2 ページ） 「システムコール」と聞いて、どういう印象を受けますか？ 「難しくて、自分では手に負えない」とか「使う必要を感じない」という方は多いでしょう。しかし、コンピュータを使う人ならどんな人でも、システムコールについて知っておくといろいろトクをするんですよ。（編集部） システムコール？ 聞いたことはあるけど…… 企業情報システムや、Webアプリケーション、携帯機器向けアプリケーション、あるいはちょっとしたツールの作成など、なんらかの形でソフトウェア開発に携わったことのある方なら、一度は、「システムコール」という言葉を耳にしたことがあるはずだ。しかし、先に挙げたような分野のアプリケーション開発現場で、明示的にシステムコールを利用する開発者は多くない。 システムコールは、低レベルのプログラミングやカーネ
kernel: TCP: time wait bucket table overflow の解消とTIME_WAITを減らすチューニング - 気ままにインフラエンジニア
整理がてら。 httpdが動いているあるホスト上で、 /var/log/messages に以下のようなメッセージが出ていた。 kernel: TCP: time wait bucket table overflow kernel: printk: 50078 messages suppressed. "netstat -tna |grep TIME_WAIT"すると、10万以上の数でTIME_WAITが出ている。これを解消するまでの流れ。 そもそもこの値は、カーネルパラメータの net.ipv4.tcp_max_tw_buckets で設定されている。デフォルトは16384。 （↑の通り、エラーが出た環境では既にかなり大きな値が設定されていたのだが。） /proc/sys/net/ipv4/tcp_max_tw_buckets システムが同時に保持する time-wait ソケットの最大
DBサーバの場合のLinuxチューニング - shibainu55日記
今回はLinux上でPostgreSQLやMySQLなどのDBMSを使う場合のLinuxカーネルチューニングについて。共有メモリ(shmallやshmmax)については設計時にもれなく設定の確認などをしている場合がほとんどだと思うが、それ以外のTipsとして、今回はLinuxのメモリオーバーコミットに関する記事。DBMS向けと書いたが、Linux上で動作させるソフトウェアであればDBMS以外でも考慮に入れて設計すべきポイントである。 Linuxのメモリ管理 Linuxのメモリ管理サブシステムには「メモリオーバーコミット」と呼ばれる機構があり、マシンに物理的に搭載されているメモリ以上の領域を確保できてしまう。この動作については、メモリ確保の際(Cの場合)実際に使われるmallocを使ったサンプルアプリなどで実際に挙動を確認することができる。参考までに、あるサイトの方は以下のようなサンプル(a
どさにっき
2008年4月21日(月) ■ 無題 _ 今朝の電車でおっさんが読んでたスポーツ新聞からちょっと見えてた見出し。頭のおかしい人が新幹線で全裸になってタイーホ。春だなぁ。 _ 出社してからニュースサイトを巡回して、それが ファーストサーバの社長だったと知る。あぁ。 _ ち、ちがうよっ、春だから頭のおかしい人が湧いてきたんじゃないよっ。だってレンタルサーバ会社の社長だよ？ 頭がおかしいなんてことはないよ。最近のデータセンターは電力問題とか熱問題とかいろいろ大変だからね、きっと陽気がよくなってあったかくなったから熱暴走を起こして、その冷却のために大事なところを放熱してただけなんだよっ。 _ てか、ファーストサーバっていつのまにか yahoo の系列になってたのか。昔はクボタ(もちろん農業機械のクボタのことだ)の子会社だったよね、たしか。 2008年4月28日(月) ■ 無題 _ メール屋を廃業し
vm.overcommit_memory = 2 のときに、実際の上限と今現在の値はどこで確認できるか？ - （ひ）メモ
(vm.overcommit_memoryの説明はぐぐってください: google:vm.overcommit_memory) 例えば vm.overcommit_memory = 2 vm.overcommit_ratio = 90なときに、実際の上限と今現在の値はどこで確認できるか？ the total virtual address space on the system is limited to (SS + RAM*(r/100)), where SS is the size of the swap space, and RAM is the size of the physical memory, and r is the contents of the file /proc/sys/vm/overcommit_ratio. proc(5): process info pseu
高負荷マシンのネットワークチューニング — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
何か決めなきゃ駄目ですか。 Linuxのbacklogについて
少しだけ突っ込んだ話。 （曖昧さは人間の脳内補完に委ねるとして･･･。） LinuxにはTCPの3Wayハンドシェイク（即ち、SYN,SYN/SCK,ACK）状態保持に関連して、 次のようなパラメータを持っている。 net.ipv4.tcp_max_syn_backlog=1024 何それ？って人は # sysctl -a | grep tcp 等のコマンドで探します。 # sysctl -a | grep backlog？それじゃノイズが無さすぎて面白くｎ(ry これは、「LinuxがSYNを受信し、SYN/ACKで応答した状態をいくつ保持するか」というもの。 閾値を超えると、Linuxは新規に接続しようとするホストのリクエスト（SYN）を無視する。 最近のLinuxを、最近のハードウェアにとりあえずインストールすると、 初期値は上記のような1024とか言う数値になっていると思う。 利用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
10分で分かるLinuxブロックレイヤ
Inside Sqale's Backend at Sapporo Ruby Kaigi 2012
https://docs.google.com/viewer?a=v&q=cache:surUGbLq1DQJ:image.gihyo.co.jp/assets/files/event/2008/24svr/report/2-24svr-TechMTG-ito.pdf+&hl=en&pid=bl&srcid=ADGEESisdoEAt03OJEl2IUxkiZl6VJL8oZ0LGfovGDqGct4tIFqk7na2Iq3eQqAL8S74m6XVX_Hixg4A65Iu6bdJIRts7pjxOkPs
Opensource.com