本部長や副本部長もプログラミングを（たまに）することで有名なサイボウズの運用本部長、山本泰宇です。 有名じゃないかもしれませんが、ブログに書いたので有名になるということでご了承ください。 今回は、先日発生した yrmcds に起因する障害の原因と対策を解説します。 yrmcds というのは、サイボウズが開発している memcached 互換のキーバリューストレージです。 問題の理解のため、まず TCP 通信で、通信先の相手の障害にどう対応するか解説します。 データの送信中に相手が落ちるケース このケースはさらに二つに分かれます。 相手の OS は生きているが、通信しているプログラムが落ちるケース 相手の OS ごと（あるいはネットワークごと）落ちるケース 1 と 2 の違いは、前者の場合 RST パケットが返ってくるのに対して、後者ではなにも返ってこない点です。後者の場合、ack されない
November 21, 2015 This isn’t about understanding everything about TCP or reading through TCP/IP Illustrated. It’s about how a little bit of TCP knowledge is essential. Here’s why. When I was at the Recurse Center, I wrote a TCP stack in Python (and wrote about what happens if you write a TCP stack in Python). This was a fun learning experience, and I thought that was all. A year later, at work, so
こんにちわ。せじまです。今年に入ってからアクティビティトラッカーを二回壊しまして、新しい分野の製品って設計いろいろ難しいんだなと、しみじみ思う今日このごろです。 先日、社内勉強会で Ethernet や CPU などの話をしました。前回のCPUに関する話に続き、今回のスライドも幅広い方に読んでいただけそうな内容かと思いましたので、公開させていただくことにしました。前回のスライドを読んでない方は、できればそちらを読んでいただいてからの方が、より理解が深まるのではないかと思います。 忙しい人のために三行でまとめると 2020年代には、サーバのネットワークインターフェースが 40Gbps 超えてそうな予感 もし Ethernet でそれだけ大量のパケットをさばくなら、（標準化されてないけれど） Jumbo Frame 使わないと厳しいかも 2020年代には、NICやブロックデバイス等、CPUを取
スプラトゥーンのナワバリバトルの通信をパケットキャプチャによって解析してみた
■なにをしたの スプラトゥーンのナワバリバトル中にどのような通信が行われているのか確認しました。ARPスプーフィングによって、Wii Uから自宅ゲートウェイへ送られるパケットを覗いてみました。使用したツールは下記の2つです。 nighthawk: ARPスプーフィングします Wireshark: パケットキャプチャします ■通信内容 ソフト起動後に、Amazon Web ServicesとSSLで通信していました。Miiverseと、ランク・ウデマエなどの戦績を、AWSとWii U本体間で同期していると思います。AWS導入事例で書かれているところの、「DataStore機能」と「Miiverse」ですかね。 ロビーに入ると、シリコンスタジオ株式会社のサーバーとUDPで定期的に通信していました。フレンドのオンライン状況を定期的にとりにいっているようです。マッチングについては、シリコンスタジオ
なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。 きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？: http://togetter.com/li/871768 以下のように、スラドに転載されてしまったわけだ。 スラド： Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？： http://linux.srad.jp/story/15/09/09/0648258/ いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。 tcp_tw_inter
ストーリー by hylom 2015年09月09日 16時55分 副作用無く効果があるならそれがデフォルト値になっているのでは 部門より Linuxカーネル界隈では有名ながちゃぴん先生こと@kosaki55tea氏が、LinuxカーネルのTCP_TIMEWAIT_LENを変更することについてその効果に疑問を呈している。 TCP_TIMEWAIT_LENはTCPコネクションのステータスがTIME_WAITになった後、コネクションをCLOSEするまでの待ち時間を設定するパラメータで、多くの場合デフォルトでは60秒に設定されているようだ。Googleなどで「TCP_TIMEWAIT_LEN」を検索すると、大量のトラフィックを捌くサーバーではこの値を変更してカーネルをリコンパイルすることでパフォーマンスを改善できる、などという話が出てくるのだが、これについて@kosaki55tea氏は次のように
9. $ ping -c 3 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=4.306 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.542 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.475 ms --- 192.168.1.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.475/2.441/4.306/1.31
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
ある日､OSX Yosemite で apache bench でベンチマークを使っていると､なぜか stuck して困っていた｡ ab -c 10 -n 16500 http://127.0.0.1:5000/ どうも､対向サーバーを jetty にしても plack にしてもダメなので､なんなのかな~と｡｡ ab そのものを疑ってみる いろいろ調べてみると､対向サーバーを変えても同じような感じで刺さるのでどうやら ab の側に問題があるのかな､と思って調べてみたところ､OSX Lion の時代にそのような問題が話題になっていたようだ｡ 最新版の ab は以下のようにして入れることができる｡ wget http://ftp.tsukuba.wide.ad.jp/software/apache//httpd/httpd-2.4.12.tar.bz2 tar xzvf httpd-2.4.1
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
要旨 昨年に続き、CONBU(COnference Network BUilder) は YAPC::Asia の会場ネットワークを提供しています。1 [※１] 今年の目標として「安定したネットワークを、いかに早く、そして面白く提供できるか？」を掲げており、これを達成するための取り組みについて紹介いたします。 発表内容 本トークでは、イベントやカンファレンスでのネットワーク提供に関するノウハウの紹介をします。 また、会場ネットワークの通信流量やWiFi接続数を取得できる独自APIに関する取り組み、及び活用例を紹介します。 CONBUのネットワーク提供方法 -いかにネットワークを早く上手くつくるか -CONBU Cloud（コンクラ）に関する紹介 APIについて -CONBU API への取り組み -独自API を作成するモチベーション -CONBU API の仕様 -CONBU API の
Seastar OS開発 カーネル開発 LinuxとかでC言語やってるけどC++やらされることになった。 半数の開発者はリモート開発で参加 IaaS環境に特化したOS OSvを開発 カーネルなのにboostが使える KVM開発者とか有名ドコロが多い SeaStarとは www.seastar-project.org 高スループットなサーバアプリケーションの為の新しいフレームワーク 非同期 Apacheライセンス DB 分散ファイルシステムなどに使える 問題点 CPUのクロック数があまり向上しない コア数は増えるけどソフトウェアが性能を出し切るのは難しい ロックの仕様はたとえ競合がなくてもコストが大きい あるコアでアロケートされたデータは別のコアで使用されたりコピーされたりする ので、ソフトウェアの性能を出し切れていない シェアードナッシングにしよう リニアにスケールするSeaStarフレー
5. SeaStarとは • http://www.seastar-project.org/ • 高スループットなサーバアプリケーションを記述するための新しいフレームワーク • 物理マシン／VM上で動作、Linux／OSvに対応 • シェアードナッシング、完全非同期モデル • オープンソース（Apache License） • 適用範囲の例：データベース、分散ファイルシステム、キャッシュ、プロクシなど 6. 今日のプログラミングモデルの問題点 • CPUのクロック数はあまり向上しない • コア数は増えていくがソフトウェアで性能を出し切る事は難しい • アプリがスケールしない • ロックの使用は例え競合がなくてもコストが大きい • あるコアでアロケートされたデータは別のコアで使用されたりコピーされたりする • ソフトウェアが最近のハードウェアに最適化しきれていない • SSD, >10GbE
東京ビッグサイトで17日、18日に開催された「ジャンボびっくり見本市」にて、DXアンテナは既設のテレビ同軸ケーブルを利用してIPネットワークを構築することができる高速同軸モデムEOC10シリーズ(「EOC10C01」「EOC11C01」）の展示を行った。「EOC10C01」は機器設定が自動登録仕様で、「EOC11C01」が手動登録仕様となる。 本機は、LAN端子とTV出力端子(同軸端子)、ライン入力端子(同軸端子)を備えており、電源はAC100V。ルーターやモデムにLANケーブルで接続し、既存の同軸ケーブルにつなげて親機として使う場合と、ネットワーク機器とLANケーブルでつなぎ、同軸ケーブルで親機に接続する子機として使う場合を想定している。 セキュリティシーンにおけるシステムの構成例としては、子機として使う本機Aにネットワークカメラ(IPカメラ)をつなぎ、同軸ケーブルで親機として使う本機B
500マイル以上離れた場所にメールが送れないのだが
http://web.mit.edu/jemorris/humor/500-miles From: Trey Harris <trey@sage.org> 今から私が書く話は、起こりようのない問題についてだ。この話を広く一般に公開してしまうのは惜しい。というのも、いい酒の話のネタになるからだ。この物語は、退屈な詳細や問題を隠すために、多少事実を変えていて、物語を面白く脚色している。 数年前、私はキャンパスのメールシステムを保守する仕事をしていて、統計学部の学部長から電話を受けた。 「大学の外にメールを送るのに不具合が発生しているのだが」 「どんな問題でしょう？」と私はたずねた。 「500マイル以上メールを送れないのだよ」と学部長は説明した。 私はラテを吹き出した。「何だって？」 「ここから500マイル以上離れた場所にメールを送信できないのだよ」と学部長は繰り返した。「実際は、もう少しあるの
ネットワークと私 ネットワークアプリケーションの建築を考えた時、全ての開発者がぶつかる問題があります それは、ネットワーク上にはどのようなコンピュータが存在するかわからないということです しかし、サーバーは相手が誰であれ正しい結果を出さなければなりません 人種差別が悪であるように、機種差別もネットワークの世界では悪なのです そこで、最初に問題となったのがネットワークバイトオーダーです ワード単位の情報をビッグエンディアンとするかリトルエンディアンとするか ネットワーク上の標準はどちらであるかという問題です 現代、多くのパーソナルコンピュータ市場は Intel とその互換プロセッサに支配され その性質は、下位バイトから順にメモリに配置するリトルエンディアン形式です アセンブリ経験者は理解していると思いますが、Intel の x86 プロセッサは 0xABCD というワード長のデータを 0xC
こっちの記事だとただ札束風呂入って綱引きして遊んできただけじゃねーか､なので本業タスク?について｡ CROSS2015 の会場ネットワークをCONBUチームがサポートしました｡ディープに技術的な内容は別途書くと思いますので､ここでは経緯とか準備について書きます｡ ===宣伝=== 技評さんのSoftware Design誌の3月号(2月18日発売)にCONBUメンバが執筆したカンファレンスNWについての特集記事が載ります｡みんな読んでね! 経緯 実は前回のCROSS2014 でもご相談を頂いていました｡昨年は実行委員さんチームでつくられたそうで､準備段階での技術的なご相談にのっただけでした｡ 今回CROSS2015については去年の夏頃に実行委員長である山口さんから手伝ってもらえないかとご相談いただきました｡CONBUチームはエンジニアコミュニティ間の交流をゴール(の一つ)にしていますので､
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
