一から学べる Google Cloud Networking リファレンス ガイドGoogle Cloud Platform (Google App Engine, Compute Engine, BigQuery や Container Engine など）の情報の日本公式ブログ
tc コマンドでネットワーク遅延やパケットロスを疑似的に発生させるメモ - ようへいの日々精進XP
ども、初老丸です。 tl;dr Linux において tc コマンド（Traffic Control）使ってネットワーク遅延やパケットロスを疑似的に発生させることが出来るとのこと。今まで tc コマンドの存在すら知らなかったペーペーで恐縮だが、参考サイトをまねて遅延やパケットロスを発生させてみたい。 メモ 参考 http://linux-biyori.sakura.ne.jp/setting/st_netem.php http://labs.gree.jp/blog/2014/10/11266/ man tc 以下の環境で試す。 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS" ひとまず
utrace - locate IP addresses and domainnames
The IP address "133.242.243.6" is located in the following region:
これが本当のインターネット、世界中に張り巡らされた海底ケーブルを地図上に表すとこうなる
インターネットは世界中に張り巡らされた海底ケーブルに支えられているのですが、その海底ケーブルがいったいどのような分布になっているかが一目でわかるようになっている図が「Mapping the internet」です。 Mapping the internet | nicolasrapp.com http://nicolasrapp.com/?p=1180 もはや生活と切っても切れない関係にあるインターネットを可能にしているのは、世界中の海底に張り巡らされた光ファイバーのケーブルで、長距離の海底ケーブルシステムでは最大給電電圧が1万5000V程度まで必要となっており、Wikipediaによると「伝送のために中継器と呼ばれる信号の増幅装置を設置する必要がある」「光ファイバーケーブルの中継器は、初期のころはケーブルからの光信号を電気信号に変えてから増幅させ、再び光信号を電気信号に戻して出力するとい
[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日(月) ■ 無題 _ メール屋を廃業し
あなたの大量配信サーバip_conntrack 溢れていませんか？ | ブログ | 株式会社イー・エージェンシー
ip_conntrackを設定する理由 パケットフィルタリングツールであるiptablesは、パケットを解析するときにip_conntrackというファイルにトラッキング情報を記録します。 ip_conntrackには、最大トラッキング数があり、それをオーバーすると新規セッションを弾いてしまって、ネットワークパフォーマンスの劣化を招きます。 /var/log/messageにこのようなメッセージが出ていたら、ip_conntrackが溢れている状態です。 大量のトラフィックを捌くロードバランサーやキャッシュなどの目的を持ったLinuxマシンで、iptablesを使っているときには、ip_conntrackの最大トラッキング数を忘れずに設定しておきましょう。 ここでは、手元のマシンCentOS 5と6で設定をしていきます。 検証環境 CentOS 6.3(64bit) CentOS 5.8(
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 ソケットの最大
CLOSE_WAITのセッションを早く消す方法 - つれづれなる・・・
原因はおそらくwebサーバ〜DBサーバ間のセッションがネットワーク的に不安定だったからだと思うけど、DBサーバで netstat -an すると 大量の CLOSE_WAIT のセッションが残ってしまって、MySQL の最大コネクション数にまで達してしまってwebの表示が出来なかった。CLOSE_WAIT をいきなり消すことは出来ないので、早めに消えるようにしたいときは tcp_keepalive_time TCPセッションが確立されて検査が実施されるまでの時間 時間になると tcp_keepalive_intvl と tcp_keepalive_probes の値にしたがって検査を実施する tcp_keepalive_intvl 次の検査を実行するときの待ち時間 tcp_keepalive_probes 検査の回数のそれぞれの値を小さくしてあげればよい。変更方法は vi で :wq する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
