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を落とし
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 Webをより速くしようと、HTTPよりも優れたプロトコルとして提案されたSPDY（スピーディ）。しかしそのSPDYによって、下位レイヤであるTCPの制限が顕著に見えるようになってしまい、そのことでTCP以外のプロトコルとしてQUICをGoogleが提案しています。 Webの進化は、インターネットのプロトコルにまで影響を与えようとしている、という非常に興味深い話が、HTML5のコミュニティ「html5j」主催のイベント「HTML Conference 2013」で行われた小松健作氏のセッション「最新Webプロトコル、傾向と対策」で行われました。 その内容をダイジェストで紹介しましょう。 最新Webプロトコル、傾向と対策 小松です。所属はNTTコミュニケーションズでHTML5の研究
Working With TCP Sockets - A short, concise guide that teaches Rubyists the basics of socket programming, and then some!
You Don't Have to be a C Programmer to Understand Socket Programming A short, concise guide that teaches Rubyists the basics of socket programming, and then some! Do you know how your web server opens a socket, binds to an address, and accepts a connection? I did a lot of web programming before I had enough knowledge to dig in and figure this stuff out. I knew that other developers had a better gr
ネットワ−クの速度を調べる方法
"速さ" の意味は？ 遅延時間を測る データ帯域を測る 試験用のファイルを作る 例: wget で速度を測定 速度低下や変動の原因 回線を高速化すべきか？どこまで？ "速さ" の意味は？ TCP/IP に使っている回線のスピードと云っても大まかには "バンド幅" と "レイテンシー" の2つがある. データ帯域: 一定時間あたりに通信できるデータ量. 個人の利用ではこれが実際の使用感と係わっていると思う. 以下のバンド幅, レイテンシーの他に パケットサイズ, 受信窓サイズ,エラーに依る再転送などの様々な要因に影響される. バンド幅(band width): 一定時間に通過できるデータ量. データ経路の太さと考えると良い. 究極的には流せる信号の周波数(帯域幅)による. 経路が複数の要素からなるとき, 最小のバンド幅の要素が制限の要因となる. 例： ほぼ, 10BASE, 100BASE
高速ネットワークでのサーバー負荷を大きく軽減する p2
TCPでは，送信すべきユーザー・データが大きすぎて1つのパケットで伝送できない場合，そのデータを分割して複数のTCPパケットにする。これがTCPセグメント化である。TCPユーザー・データの分割単位は，最大セグメント長（MSS）と呼ばれ，データ・リンクによって異なる。理由は，MSSの大きさがデータ・リンクごとの最大転送単位（MTU）に依存しているからである（図7）。 TCPセグメント化の例として，イーサネット上で送信すべきTCPユーザー・データが3000バイトの場合を示す（図8）。分割後のパケットのユーザー・データはMSSの値以下でなければならない。 イーサネットのMTUは1500バイトなので，IPヘッダーとTCPヘッダーの分を除くと，TCPユーザー・データが格納できるのは1パケット当たり最大1460バイトとなる。TCPセグメント化では，TCPユーザー・データの分割と併せて，IPヘッダー，T
Maximum Transmission Unit - Wikipedia
Maximum Transmission Unit (MTU：最大送信単位)は、ネットワークにおいて1回の転送（1フレーム）で送信できるデータの最大値を示す伝送単位のこと。 MTUの値は利用される通信メディアやカプセル化の有無などによって変わる。たとえばイーサネットでは最大1,500バイト（オクテット）がIP通信に利用できる。PPPoEを使うとカプセル化のために8バイトを使うため、1,492バイトとなる。WANではさらに別の制約が入る場合もあり、たとえばNTT東日本およびNTT西日本が提供するフレッツシリーズのIP網は1,454バイトとなっている[1]。 MTUを超えた場合、断片化（フラグメンテーション）して通信を行う。 MTUと通信パフォーマンス[編集] パケット通信を用いて一定サイズのデータを送受信する場合、パケット長の決定が通信パフォーマンスに影響する。 通信中にデータが破損した場合
エンド・ツー・エンドのMTUサイズに注意，フラグメント処理は性能劣化を招く
WANをまたいで拠点間を接続している場合，パケットのフラグメンテーションが原因でトラブルに陥ることがある。通信経路上でMTU（maximum transmission unit）サイズが小さい部分があるケースだ。具体的には，広域イーサネット・サービスを利用している場合や，暗号化技術を使ってVPN（仮想的な専用線）接続している場合である。 MTUサイズはデータ・パケットを送信する際に許容される最大パケット長で，イーサネットでは1518バイトというように物理媒体によってそれぞれ値が決まっている。問題はWANにデータを送出する際にカプセル化などによってパケット長がMTUサイズを超えてしまうケースがあることだ。パケット長がMTUサイズを超えている場合，ルーターなどが自動的にパケットを細分化（フラグメント）して送信することがある。この場合，フラグメント処理，受信側での再組み立て処理が発生し，パフォー
SEIL/SMF コミュニティサイト リニューアル
SEIL/SMF コミュニティサイトはリニューアルしました。 SEIL/SMF コミュニティサイトで提供されていた、サポートフォーラム、SEIL/x86 Fujiダウンロードページ、ブログは、以下のリンク先をご利用ください。
[B! linux][sysctl] kamipoのブックマーク
13.2. あまり知られていない設定はい、変更できるパラメータはとてもたくさんあります。 ここではそれらすべてをリストしたいと考えています。 一部は Documentation/ip-sysctl.txt でも説明されています。 カーネルのコンパイル時に 'Configure as router and not host' に 'Yes' と答えていると、これらの設定のデフォルトが、 ここに示すものとは異なっているかもしれません。 Oskar Andreasson も、これらのフラグに関するページを公開しています。 ここのものより良いように思えますので、 彼のページ もチェックしてみてください。 訳注: この部分の訳出にあたっては、 2.2 カーネル付属文書 proc.txt の翻訳 を参考にさせていただきました。 13.2.1. ipv4 全体一般的な注意ですが、ほとんどの速度制限機能は
高負荷マシンのネットワークチューニング — ありえるえりあ
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 「プ
kernelをチューニングしてTIME_WAIT値を変更する - メモとかそんな感じなやつ
kernelのチューニングについて まぁ個人的な所感なんですけど。。 10年前ぐらい前、とあるシステムで原因のリンクダウンが頻発するトラブルがあり、まったく原因がわからなかったのですが、当時の先輩がkernelのソースコードをいじくって直したことがありました(なんかパッチ送ってました)。 私はその頃ペーペーだったのですが、なにこの変態と思いつつも、その技術力にとても感動しました。 10年たった今はだいぶ安定しておりkernelレベルのチューニングはあまり必要性を感じていませんが、どうしてもって時はこうやるよって感じのメモです。 まぁTIME_WAIT値を変えるぐらいなら大したことないんですけどね。あのリンクダウンってどうやって解決したのかな。10年たった今でもさっぱりわからん。変態め 環境等 OS: CentOS 5.8 (64bit) kernel: kernel-2.6.18-308
Man page of TCP
Section: Linux Programmer's Manual (7) Updated: 2020-12-21 Index JM Home Page roff page 名前 tcp - TCP プロトコル 書式 #include <sys/socket.h> #include <netinet/in.h> #include <netinet/tcp.h> tcp_socket = socket(AF_INET, SOCK_STREAM, 0); 説明 これは RFC 793, RFC 1122, RFC 2001 で定義されている TCP プロトコルを NewReno 拡張と SACK 拡張を含めて実装したものである。 TCP は、 ip(7) 上の二つのソケット間に、信頼性の高い、ストリーム指向の全二重 (full-duplex) 通信を提供する。 v4 と v6 の両方のバージ
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 ソケットの最大
TIME_WAITのチューニングとkernelリビルド for CentOS 6.0 - 逆襲のWebエンジニア
久しぶりにSRPMからkernelリビルドしてみたので、 過去を振り返りつつ手順をメモ。 ソーシャルゲームや外部のAPIを使用するサービスなどにありがちなんですが、 Webサーバは、受けるHTTPリクエストが多くなると、 外部のWebサーバにHTTPリクエストを送る処理も多くなったりします。 その場合に問題となるのが、tcpのコネクションです。 TIME_WAIT状態のコネクションが多くなると、 接続できる数は上限があるので、接続できたりできなかったり不安定な状態になります。 そうなると、まあ担当者はかなりテンパってますね。 でも負荷的にはサーバはテンパってなかったりします。 TIME_WAIT多発対策はざっくり サーバ増強 緊急対応ということで、あくまで一時的な対応。富豪ならこれでよし。 使用できるTCPポート番号を増やした 増加量が上回る場合は、焼け石に水。 tcp_tw_recycl
Linux SYNパケット取りこぼし - LowPriority
Linuxで負荷も問題になるほど高くなくlisten及びsynのbacklogも溢れてないのに 特定のホストからのみSYNを吸い込んでSYN-ACKを返さない事がある場合があった。 必ず吸い込むというわけではなく、一発で通る場合と数回再送受けてから処理するのも あったりして謎な感じ。tcpdumpで見てもパケット単位の不整合は特に見あたらない。 受け付けている環境で変更されていたTCPパラメータは以下で、syncookies以外は IN/OUTどの部分の処理に関わるのかDocument読んでも良く解らないので、それぞれに ついて参照箇所を調べてみた。(PATHはKERNELのnet/以下) net.ipv4.tcp_tw_reuse (sysctl_tcp_tw_reuse) Outbound Connectionだけ影響 ipv4/tcp_ipv4.c:tcp_v4_connect ip
[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority
前回の続き。 パケット自体を零さずに処理に入った後にSYNを落とすのは以下3パターン。 syncookie無効時にsynのbacklog(tcp_max_syn_backlog)が溢れている listenのbacklogが溢れている(3way-handshake完了後のaccept待ち接続) net.ipv4.tcp_tw_recycleの制限に抵触 で、今回問題になっていたのは最後のtcp_tw_recycleへの抵触だった。 現象として発生しうるのは、以下の条件をすべて満たす場合 サーバ側でnet.ipv4.tcp_tw_recycleが有効 TCPタイムスタンプオプションを使用 同一IPからの接続でセッションを跨ぐとセットされるTCPタイムスタンプの値が戻る場合がある 最後の条件が微妙だが、TCPタイムスタンプの値としてセットされる値は起動時を 起算時にしていたりと実装によって初期値
![[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority](https://cdn-ak-scissors.b.st-hatena.com/image/square/264702d4cb37ced3c2fd5dda6a1368c235356862/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127119925553%2F17680117127119930188%2F1557218483)
どさにっき
2008年4月21日(月) ■ 無題 _ 今朝の電車でおっさんが読んでたスポーツ新聞からちょっと見えてた見出し。頭のおかしい人が新幹線で全裸になってタイーホ。春だなぁ。 _ 出社してからニュースサイトを巡回して、それが ファーストサーバの社長だったと知る。あぁ。 _ ち、ちがうよっ、春だから頭のおかしい人が湧いてきたんじゃないよっ。だってレンタルサーバ会社の社長だよ？ 頭がおかしいなんてことはないよ。最近のデータセンターは電力問題とか熱問題とかいろいろ大変だからね、きっと陽気がよくなってあったかくなったから熱暴走を起こして、その冷却のために大事なところを放熱してただけなんだよっ。 _ てか、ファーストサーバっていつのまにか yahoo の系列になってたのか。昔はクボタ(もちろん農業機械のクボタのことだ)の子会社だったよね、たしか。 2008年4月28日(月) ■ 無題 _ メール屋を廃業し
FLINTERS Engineer's Blog
2023-04-06 DigdagからBigQueryを動かす - ChatGPTを使用してエラーを解決した話 AI BigQuery Digdag こんにちは、植村です。今回は弊チームで使用しているワークフローエンジンのdigdag(AWS, EC2)からGCPへアクセスしてBigQueryを動かした時のお話を書きます。やりたいこと：DigdagからBigQueryのExport機能を使用してGCSにデータを格納するGCPの環境は既にで… digdag BigQuery Chat GPT 2023-04-01 週休7日に興味あり？新しいBingが弊社の魅力をご紹介します！ AI こんにちは、菅野です。 もう一年の4分の1が終わりましたね。 新生活の季節となった4月1日なので(?)唐突に弊社を紹介する記事を書きました！ と言っても、私が紹介するのでは面白くないので「新しいBing」に会社の
OSS Message Pedia -mid:30094-
TCP: Treason uncloaked! Peer dst_ip_address:dst_port/src_port shrinks window this_seq_pos:next_seq_pos. Repaired. dst_ip_address TCPパケット再送先のIPアドレス dst_port TCPパケット再送先のポート番号 src_port 再送の際に使用する、自ホストのポート番号 this_seq_pos 送信済みであるが、相手ホストからack(確認応答)が未だ帰ってきていないパケットの先頭位置 next_seq_pos 送信済みであるが、相手ホストからackが未だ帰ってきていないパケットの最後尾の位置 TCPの通信処理を行っているときに以下の全ての条件を満たした場合に本メッセージは出力される。 再送信したパケットに対してのackが無い TCP windowサイズが0
Linuxサーバ上のHTTPプロキシサーバでシステム負荷が高くないにもかかわらず処理が遅い場合：TechLabo：So-netブログ
仕事で、Linuxサーバ上でHTTPプロキシサーバとして動作するとあるURLフィルタリングソフトを使っているユーザから、「お昼頃からプロキシサーバ経由でのアクセスが非常に遅い、ちなみにCPU使用率とメモリ使用率、ディスクI/Oは正常時と変わりないのになぜ？」という問い合わせがあり対処したときのメモ。 システムリソースの負荷が高くなく、処理遅延が発生している場合の疑う点としては、 ファイルディスクリプタが不足している アプリケーション（プロキシサーバ）の最大同時接続数以上のアクセスを受け付けている カーネルチューニング不足 の3つが考えられる。 1．のファイルディスクリプタ不足はプロキシサーバアプリケーションが1セッション1スレッドで動作するようなもの（メジャーなものではsquidなど）が発生しやすい。 ログファイルに”too many open files”というメッセージが記録されるので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
