SYNを受け取っているのにSYN-ACKを返さない件 - FLINTERS Engineer's Blog
こんにちは！@kakeyangです！ 久しぶりの投稿です。 なぜなら、、、沖縄の八重山諸島に旅行に行ってましたのです！ 楽しかったなぁ（遠い目） 今回は、開発で経験した通信障害の原因とその対策を公開します。 原因がLinuxカーネルの設定だったので、結構苦労しました。。。 障害概要 異なるネットワーク内（片方は弊社ネットワーク）の物理サーバ間（弊社が受信側）でインターネット越しにソケット通信を行う。 毎回ではないが1割程度の割合で、送信側でconnection timeoutを観測。 受信側にはapacheのログが残っていなかったので、webサーバには届いていない。 送信側でtracerouteすると、確かに弊社ネットワーク内には入っている。 弊社ネットワーク内のF/Wから物理サーバの間のどこかで通信が途絶えているっぽい！ というところまではすぐに判明しました。 調査内容 データセンターと
Part1 アプリケーションに欠かせぬ通信のプラットフォーム
ネットワークはLANやIPだけじゃない。相手との通信を成り立たせるには，TCPやUDPが不可欠だ。むしろ，Webブラウザや電子メール・ソフトなどのネットワーク・アプリケーションにとって，TCPとUDPはなくてはならない基盤的な存在である。Part1では，TCPとUDPの概要を示す。 インターネットなどTCP/IPを使ったネットワークでは，データをIPパケットという単位でやりとりする。このIPパケットには，通信相手の住所を表すIPアドレスが書かれており，ルーターがこのIPアドレスを見て転送する。ここまでは，知っている人が多いだろう。 しかし，これだけでは通信は成り立たない。Webアクセスやメールの送受信など，ほどんどのインターネット・アプリケーションが動かないのだ。 その理由の一つは，IPアドレスは単に相手のコンピュータを特定するだけだからだ。パケットを受信してもコンピュータはそのデータをど
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のせいだ！ - Qiita
課題 突然キャンペーンとかの高トラフィックが来る！とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない！！とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 とりあえず何とかしたい TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.39
TCPのTIME_WAITを無くす！ | 田舎に住みたいエンジニアの日記
サーバをnetstat -anで様子をみると、TIME_WAITが大部分を占めていた。 これってこのままでいいのか？ と思い、TIME_WAITについて調べてみました。 TIME_WAITをなんとかしたい場合は、以下の方法が考えられます。 1, サーバ増強 分散させたり、性能を上げます。あくまで一時的な対応になります。 2, 利用可能なTCPポート番号のチューニング 増加量が上回る場合は、焼け石に水です。 3, tcp_tw_recycleを有効 + tcp_fin_timeout値を短くする。 パケットのタイムスタンプの影響で通信に問題が出てきます。webサーバなどでは新たな障害にも。 4, TIME_WAITの値を60秒→15秒に変更（参考リンク引用） TIME_WAITが減り安定動作するそうです。 以上の４点を順番に見て行きましょう。 注意としてはどれもカーネルパラメータのチューニン
見落としがちなLinuxのWEBチューニング | Act as Professional
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない) というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連 iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_max ip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて
HAProxyのパフォーマンスチューニングをやったメモ(CPS編) - 元RX-7乗りの適当な日々
HAProxyを使う上で、どうやったらパフォーマンスが上がるのかを模索するメモ。 基本的に、万能なパフォーマンスチューニングはないので、今回はCPS(Connections per Second)のパフォーマンスを上げることに焦点を絞ります。CPS(Connections per Second)は、ロードバランサの性能指標の1つとなっている数値です。 あくまで軽くやってみた過程のメモ書きみたいなものなので、まとまりもなく、まだまだ改善の余地があるとは思いますが、何かの参考にしてください。 前提 HAProxyを動かすのに使用した環境は以下の通り。 Server: DELL PowerEdge R420 CPU: Intel Xeon E5-2430L @ 2.00GHz * 2 Memory: 96GB Ethernet controller: Intel Corporation Ethe
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
