マルチクラウド展開にまつわる既成概念を覆すより データ転送では、特に長距離の場合にレイテンシ（遅延）が問題になることがありますが、現在はすべてのクラウド・プロバイダーがそれぞれの物理インフラストラクチャを互いの近くに配置（専門用語では「コロケーション」）しているため、これはさほど問題となりません。この近接性（場合によっては同一コロケーション施設内の別の部屋）は、クラウド間のレイテンシがミリ秒単位であることを意味します。それに加え、クラウド・データセンター・リージョンは世界中で増加しており、クラウド・リージョン間の距離は縮まっています。 という事で、レイテンシ(遅延)について、まとめてみてみます。 ■ Agenda レイテンシ(遅延)とスループット(帯域幅) レイテンシと TCP の動作 帯域幅遅延積(Bandwidth-Delay Product) TCP Window Size の調整と
cgroups の net_cls と tc を使えばできる。 http://blog.livedoor.jp/aspplus/archives/51842032.html に書いてあるとおりで良いようだ。 ただし、このページにも書いてあるとおり、 tc filter の記述は謎がある。しかし、このとおりに書けば期待通りになる。 なお、 filter の最後の cgroup を別の文字列に置き換えると動かないため、意味のある文字列として扱われていることは https://www.kernel.org/doc/Documentation/cgroups/net_cls.txt を読むと iptables も必要そうに読めるが、実際には不要だった。 結果の測定は iperf を使えば良い。 コマンドの実例は以下のとおり tc qdisc del dev eth0 root tc qdisc a
O'Reilly Japan @oreilly_japan 5月16日発売の『ハイパフォーマンス ブラウザネットワーキング』の書籍ハッシュタグは #HPBNj です。情報共有にご活用ください！ 2014-05-12 14:02:23
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog インフラエンジニア見習いの森本です。これまで数年ほどサーバーサイドエンジニアとして開発ばかりをしてきた人が最近インフラエンジニアになりました。 3月末に開催された Go Conference 2017 Spring で開発チームの後藤から弊社で開発・運用している AWS S3 互換の分散オブジェクトストレージ Dragon についての発表がありました。 Goでヤフーの分散オブジェクトストレージを作った話 私は Dragon の運用を担うチームに所属しており、本稿ではその業務の中で発生したトラブルシューティングについて紹介したいと思います。 分散オブジェクトストレージ Dragon で発生していた課題 Dragon で gorout
ども、初老丸です。 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" ひとまず
ソフトウェア割り込みが偏る？ Linuxを利用していて、ネットワーク負荷が高いサーバを運用していると、特定のCPU負荷が高くなっている事があるのですが、そのようなケースを経験されたことはないでしょうか？ topでみると特定CPU(topを起動して1を押すとCPU単位で確認できる)の**%si(software interrupt)がやたら高くなっている場合、それはネットワークの負荷が原因かも知れません。(実際のtopを貼り付けたかったのですが、持ち合わせがなかった・・・。)何も設定していない場合はネットワークの割り込みは特定のCPUで行われるため、ネットワークの割り込みに関連づいたCPUの%siが高くなります。ソフトウェア割り込みを確認するには、/proc/interrupts**を確認しましょう。 # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0:
ちょっとした小ネタです。 ネットワーク環境調査に於いてネットワークの『回線速度を調べたい』という局面があるかと思いますが、Windows環境ではブラウザ経由で簡単に結果が得られる一方、Linux環境では『あれ、そもそも何が出来る／どうやれば出来るんだろう？』と少々思案してしまいました。情報を幾つか漁ってみたところ、Linux環境でも回線速度状況を把握する術が幾つかある事が分かりましたので備忘録的に整理しておこうと思います。 目次 環境準備 Speedtest-cli iperf dstat ping まとめ 環境準備 当エントリではAmazon Linux AMIを使った環境で回線速度を調べる環境が必要になった場合、という状況を想定してみたいと思います。直近最新のAmazon Linux AMIで環境を構築し、yumコマンドでパッケージ各種を最新の状態に整えておきます。 $ sudo yu
現実的な値と根拠など Slow Start などの例に良く出てくる数字の論拠と、個々の単位がどこで決まってくるかを主に取り扱う。というメモ。苦手科目だ。_:(´ཀ`」 ∠): Max Segment Size (MSS) の決定 この MSS がウインドウサイズ（一度に転送するデータサイズ）の単位として扱われる。（後述） TCP コネクションが 3-way handshake によって確立される際、ノード間で下記のような MSS に関するやり取りが発生する。 各ノードは Maximum Transmission Unit (MTU) から TCPヘッダ20バイト、IPヘッダ20バイトの計40バイトを引いた値を MSS として提示する 各ノードの希望 MSS のうち低い方を、そのコネクションにおける MSS とする たとえばイーサネットでは最大1,500バイト（オクテット）がIP通信に利用で
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
概要 ↓ memcachedのtcp_backlogのデフォルト値は1024で、stats settingsにも1024と表示されているのですが、 stats settings ... STAT tcp_backlog 1024 ... END↓ net.core.somaxconnがデフォルト値のままだと128に切り詰められてしまい、 # cat /proc/sys/net/core/somaxconn 128負荷が高いサーバーでは接続要求を取りこぼしてしまうことがあるそうです。 このnet.core.somaxconn、MemcacheやMySQLなど、高負荷時に多くの接続要求を受け付けるサーバーではチューニングが必要なカーネルパラメータのようです。いったいどういう値なのか、調べてみました。 net.core.somaxconnとは TCPソケットはlisten()関数の第二引数 ba
1. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. 今できる通信⾼高速化 にトライしたみた 東京Node学園 15時限⽬目 Feb 10, 2015 Yoshiki Shibukawa GDI DeNA Co., Ltd. 2. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. ⾃自⼰己紹介 ! 名前: ⁃ 渋川よしき (@shibu_̲jp) ! 所属 ⁃ DeNAの開発基盤部 ⁃ Sphinx-‐‑‒Users.jp, Python温泉 ! 好きな⾔言語 ⁃ C++, Go, 型のある某altJS ! 書いた本・翻訳した本 ⁃ つまみぐい勉強法、Mobageを⽀支える技術、 オブジェクト指向JavaScript、スクラム本、 ポモドーロテクニック⼊入⾨門、 エキスパート
mTCP enables high-performance userspace TCP/IP stacks by bypassing the kernel and reducing system call overhead. It was shown to achieve up to 25x higher throughput than Linux for short flows. The document discusses porting the iperf benchmark to use mTCP, which required only minor changes. Performance tests found that mTCP-ified iperf achieved similar throughput as Linux iperf for different packe
Does TCP not meet your required latency consistently? Is UDP not reliable enough? Do you need to multicast? What about flow control, congestion control, and a means to avoid head of line blocking that can be integrated with the application? Or perhaps you’re just fascinated by how to design for the cutting edge of performance? Maybe you have tried higher level messaging products and found they are
Greets! I'm delighted to be able to announce the release of Pflua, a high-performance packet filtering toolkit written in Lua. Pflua implements the well-known libpcap packet filtering language, which we call pflang for short. Unlike other packet filtering toolkits, which tend to use the libpcap library to compile pflang expressions bytecode to be run by the kernel, Pflua is a completely new implem
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
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
サーバNIC(Network Interface Card)の可用性向上や負荷分散にはNIC冗長化が有効です。NIC冗長化については拙著「インフラエンジニアの教科書」にも記しましたが、bonding、チーミング、リンクアグリゲーションなど様々な呼び名があります。今回はLinux上でのNIC冗長化の話しとなりますので、bondingについての話題となります。 【bondingとは】 bondingとは、複数のNICが搭載されているマシンのNICを束ねて1つの仮想的なNICとして扱うことのできる技術です。例えば1GbpsのNICポートが4つ搭載されているサーバとL2スイッチの間を4本のLANケーブルで接続してbonding設定を有効にさせると、冗長化が行われて最低1本が正常であれば1～3本に問題があっても通信が継続できたり、負荷分散が行われて通信帯域幅を4Gbpsに拡張されたりといった使い方が
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
