How TCP backlog works in Linux
When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections. Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept s
SoftBank携帯とnet.ipv4.tcp_tw_recycle=1の相性が悪い本当の理由 - Y-Ken Studio
photo by saschaaa LinuxにおいてTIME_WAITなコネクションを減らす手法としてnet.ipv4.tcp_tw_recycle=1にするテクニックは有名です。 しかし環境によってはSoftBankに限らず問題が起きるため、利用には注意が必要です。 一体どのような問題が起きるのか、詳細に解説されたブログを見つけたので紹介します。 検証記事 記事1 kernel: TCP: time wait bucket table overflow の解消とTIME_WAITを減らすチューニングという記事では次の言及がされています。（抜粋） サーバ側で net.ipv4.tcp_tw_recycle が有効で、クライアント側でTCPのタイムスタンプオプションが有効（Linuxの場合net.ipv4.tcp_timestamps = 1）だと、NAT/LBを超えたときにSYNを落とし
Linux Network Tuning for 2013
Linux distributions still ship with the assumption that they will be multi-user systems, meaning resource limits are set for a normal human doing day-to-day desktop work. For a high-performance system trying to serve thousands of concurrent network clients, these limits are far too low. If you have an online game or web app that’s pushing the envelope, these settings can help increase awesomeness.
somaxconnの上限値は65535
Linuxのネットワークパラメータの一つに、net.core.somaxconnというのがあります。これはlisten(2)の第二引数backlogの上限値となっています。このsomaxconnは一見intに見えますが、実はunsigned shortの範囲の数値しか受け付けません。それを超える数値を入れると黙って切り捨てられます。つまり -1→65535 0→0 65535→65535 65536→0 65537→1 と同じような動作を内部的にします。なので、この値は絶対に0～65535の範囲を超えてはいけません。以下、詳しい説明です。 おことわり: この仕様はLinux 3.11以降変更されており、範囲外の数値を設定できないようになっています。ここに書いてある内容が再現するのは、Linux 3.10以前の古いカーネルのみです。 まずsysctlの定義ですが net/core/sysct
socat を使うと各種ソケットの操作が捗りまくる件
socat っていうツールを使ってみたところソケット関連のちょっとした操作をこなすのにすこぶる使い勝手が良かった。 インストール Mac OS X なら Homebrew でインストールできる。 $ brew install socat $ which socat /usr/local/bin/socat Echo サーバを立てる socat コマンドにはソケットの入力と出力を指定する。 以下のようにすると TCP 8080 ポートで接続を待ち受けて出力は入力をそのまま cat することで TCP の Echo サーバになる。 v オプションで通信内容を表示する。 $ socat -v tcp-listen:8080 system:cat 別のターミナルから telnet コマンドで接続してみる。 $ telnet localhost 8080 Trying ::1... telnet:
Linux：OSのtcpタイムアウトのデフォルト値について - HiiHahWIKI - making some notes for... -
Linux：OSのtcpタイムアウトのデフォルト値について † 例えば、curlを使用して、タイムアウト値を300秒に指定し、タイムアウトさせるよう無いことをしても、実際180秒を超えたくらいでタイムアウトする事象が発生していました。 これが、curlだけじゃなくて、例えばapacheのmod_proxy_balancerのバックエンドサーバへのタイムアウトについても、タイムアウト値を300秒とかでせっていしても、実際は180秒ちょいでタイムアウトしてしまっていました。 これについて、ちょっと調べたところどうもLinuxのOSとして持っているTCPのタイムアウト値が効いているようだ、ということがわかりました。 ここを見ると分かります。 #cat /proc/sys/net/ipv4/tcp_syn_retries 5 これはtcpのsynを送信するリトライ回数みたいで、以下のロジックでリト
RST Packetが発生する理由 - LEVEL 05 BLOG
を探すことがたまにあるので、今まで遭遇した・調べて見つけたケースを書いておく [1]ListenしていないポートにSYNパケットが送信された場合、RSTパケットがSYNパケットの送信元に返される。 [2] Accept済みのソケットに対して、データを全て読み取っていない(EOFに達していない状態）でcloseを発行した場合にコネクションの相手側にRSTパケットが送られる。 [3] Linux限定だが、tcp_abort_on_overflowがonになっている状態で設定したバックログ以上の未Acceptのコネクションが張られた場合(http://linux.die.net/man/7/tcp) [4] tcp_max_orphans以上のorhanコネクションが張られた場合、orhanなコネクションに対してRSTパケットが送られる。 ＊orpahなコネクションってソケットがクローズされてる
MultiPath TCPのLinuxカーネル実装
MultiPath TCP - Linux Kernel implementation : Main - Home Page browse 複数のIPアドレス、インターフェースをまとめてひとつにして扱えるTCP、MultiPath TCPのLinuxカーネルによる実装だそうだ。これにより、完全に別系統のネットワークをまとめて使うことができ、スループットと冗長性の向上が図れる。 デモでは、イーサネットとWifiと3GをひとまとめにしたMPTCP上にsshセッションでXを通している。冗長性があるので、複数のインターフェースの一部が切断されても、Xは問題なく使える。 FreeBSDでMultiPath TCPを実装するパッチもあるそうだ。 mptcp このWebサイトは、Hacker Newsからリンクされたことにより、一時期閲覧者の増加により閲覧困難な状況に陥ったそうだ。「このサイトにもMul
Queueing in the Linux Network Stack
[A slightly shorter and edited version of this article appeared in the July 2013 issue of Linux Journal. Thanks to Linux Journal’s great copyright policy I’m still allowed to post this on my site. Go here to subscribe to Linux Journal.] Packet queues are a core component of any network stack or device. They allow for asynchronous modules to communicate, increase performance and have the side affec
kernelチューニング
linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作：pidの最大数 設定値：131072 理由：pidを枯渇させない vm.max_map_count 動作：mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値：300000 理由：マッピングできなくなる事態を防ぐ net.core.somaxconn 動作：接続(ソケット)キューの
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だったおかげ
GitHub - google/packetdrill: The official Google release of packetdrill
This is the official Google release of packetdrill. The packetdrill scripting tool enables quick, precise tests for entire TCP/UDP/IPv4/IPv6 network stacks, from the system call layer down to the NIC hardware. packetdrill currently works on Linux, FreeBSD, OpenBSD, and NetBSD. It can test network stack behavior over physical NICs on a LAN, or on a single machine using a tun virtual network device.
Riak 05 システムプランニング | Ore no homepage
ハードウェア層 OS層 クラスタの留意点 負荷分散 ベンチマーク BitcaskとLevelDB コンフィグファイル スケールアウトとスケールアップの手順 運用上の注意点 64ビットCPUアーキテクチャ 最低4GBのメモリ。メモリは最も重要。局所性を活かせるのであれば多くメモリを必要としない。 RAID0、SSDを考慮すると良い。IOバウンドになりがちなので。 ミラーリング(RAID1)は考えなくて良い。 RAID(RAID1？)はやめちゃいな(クラスタ組んでるしいいんじゃない？的な？)。 ディスクサイズ重要。 ギガビットイーサも考慮にいれて。ネットワークも使うよ。 仮想マシンを使う場合は一番良いインスタンスを使う。同じデータセンタ/リージョンに配置するようにする。 クラスタ全体で必要なディスクサイズは次のように計算できる。 オブジェクト数 * 平均オブジェクトサイズ * n_val 50
TCPカーネルパラメータによる障害復旧時間の短縮 - GeekFactory
クラスタ構成のサーバでは、障害発生後にクライアントがすぐに復旧しない場合があります。サーバ側がフェイルオーバした後にクライアント側が再接続するまでの時間を短くする方法を紹介します。 クライアントからサーバに接続するとソケットはESTABLISHEDになります。もしESTABLISHEDになったソケットで正しくパケットが送信されなかった場合、OSは再送を試みます。再送に失敗してソケットをクローズするまでの時間はOSの設定によります。 OSがTCP接続の異常を検知してからクローズするまでの時間を短くするには3つの方法があります。 パケットの再送回数を少なくする。 TCPレイヤでKeep Aliveパケットを送信する。この方法はTCP Keep Aliveに対応しているアプリのみ可能。 アプリケーションレイヤでKeep Aliveパケットを送信する。この方法はNullパケットを投げる等に対応して
mixiのサーバOS移行のお話 - ビルド&Kernel編 - mixi engineer blog
こんにちは。年末と年度末になるとブログを書きたくなる運用部アプリ運用グループの清水です。 気づけば前回の記事から3ヶ月が経過してしまいました… 今回は、ビルド&Kernel編と題して、Fedora 17向けにおこなったパッケージのビルドや、KernelのConfig、TCP周りの変更点について紹介したいと思います。 パッケージのビルド OSが大幅にバージョンアップすると、依存しているライブラリに大きな変更が入ったり、RPMの仕様変更もあるため、Fedora 8時代のパッケージのリビルドなど、多くのRPMパッケージを作りなおさなければなりません。 mixiでは、Fedora標準パッケージとは別に150個以上のパッケージを、 configureなどビルドオプションを変える Fedoraで提供されないパッケージを作る ディストリビューションに依存しない構成のパッケージを作る(あとで紹介するPer
Using netstat and dropwatch to observe packet loss on Linux servers -- Prefetch Technologies
Using netstat and dropwatch to observe packet loss on Linux servers Anyone that is running a modern Operating System is most likely utilizing TCP/IP to send and receive data. Modern TCP/IP stacks are somewhat complex and have a slew of tunables to control their behavior. The choice of when and when not to tune is not always super clear cut, since documentation and the advice of various network “ex
Infrastructure/Fedorahosted-retirement - Fedora Project Wiki
This page was last edited on 24 February 2021, at 21:09. fedorahosted.org retirement Summary fedorahosted.org was retired on March 1st, 2017. If you are viewing this page, odds are it's after that date and you have been redirected here by attempting to go to some project on fedorahosted.org. If you are a user of a project formerly hosted at fedorahosted.org, please search for the new home the proj
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scaling Userspace @ Facebook
Velocity 2013 TCP Tuning for the Web
http://japan.internet.com/webtech/20130703/2.html