高速にリモートホストのポートがListenしているかを調べる - 人間とウェブの未来
hb.matsumoto-r.jp 以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。 とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。 そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい） そこで一旦、最低限socket()システムコールとconnect()システムコールで接続する時のパケットをtcpdumpで眺
100万ppsを受信するプログラムを書くのはどのくらい難しいのか？【翻訳】CloudFlare ブログ | FAworksブログ
100万ppsを受信するプログラムを書くのはどのくらい難しいのか？【翻訳】CloudFlare ブログ 無料枠が充実していることでも人気なコンテンツデリバリネットワーク (CDN) を提供するCloudFlareは、最近1億1000万ドルの資金調達が発表され、ますます注目を集めている。そんなCloudFlareのブログから、ネットワークチューニングの知見を紹介したい。 原文：https://blog.cloudflare.com/how-to-receive-a-million-packets/ (2015-11-20) ※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。 CC BY-SA 2.0 image by Bob McCaffrey 先週、何気ない会話の中で同僚がこう話すのをふと耳にした。「Linuxのネットワーク・スタックが遅いんだよ！1コアあたり5万pps以上
LinuxのARPとL2スイッチのお話 - masayoshiの日記
この記事は、はてなエンジニアアドベントカレンダー2016の12月19日の記事です。 developer.hatenastaff.com 昨日はid:taketo957くんの 10ms以下のレスポンスタイムを支える継続的負荷テスト - taketo957の日記 でした！ Webオペレーションエンジニアのid:masayoshiです。 2016年に入社後、基盤チームとして仮想化、ネットワーク周りを中心に見ています。 さて、この記事ではLinuxのARPの挙動とその挙動から起こった問題を紹介しようと思います。 長々と記事を読みたくない人向けに結論をまとめるとLinuxのARPはTCP通信で使われ続ける限りキャッシュが飛ばないという挙動になるので、複数のL2スイッチにまたがったセグメントや非対称ルーティングをしている場合は気をつけましょうという話が書かれています。 今回紹介する事例自体は別に新規性
LinuxのBPF : (1) パケットフィルタ - 睡分不足
はじめに BPFの基礎 BPFの構造 BPFでのフィルタリング レジスタマシン LinuxでのBPF BPFを利用したパケットフィルタリング libpcapとBPF ここまでのまとめ 参考文献 その他参考URL はじめに BPFはBerkeley Packet Filterの略で，1993年に効率的なパケットフィルタリング手法として提案されました[1] *1． BPFの構成要素は大きく2つあって，一つがネットワークからパケットをキャプチャする部分，そしてもう一つがキャプチャした パケットをフィルタリングする部分です．BPFといった場合，後者のフィルタリング機構だけを指すことも多いです． FreeBSDなどのBSD系のOSでは/dev/bpf*という特別なデバイスがあって，このBPFを利用することができます．また， Linuxでもパケットフィルタリング（Linux Sokcet Filter
netfilterチューニング
gistfile1.txt �~� mU П��mU ip_conntrack: table full, dropping packet. この一行のログに悩まされた方は多いのではないでしょうか。 自分もその一人です。 多くのブログには echo '500000' > /proc/sys/net/ipv4/netfilter/ip_conntrack_max で解決。みたいなことが書いてあると思います。 では、この数字について根拠はなんでしょうか。そもそも何のためにconntrack tableというものがあるのか考えたことはありますか？ 闇雲に最大値をあげることにたいして抵抗がある方もいると思います。 このテキストは、転職後2日目にGWとして使っているLinux NAT BOXが爆発したことを起因とした、netfilterのチューニングについてまとめようと思います。 ある程度前提の知識が
コラム - クラウド時代のオープンソース実践活用 | 第53回 NFVとIntel DPDK（前編）｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第53回 NFVとIntel DPDK（前編） (中井悦司) 2014年10月 はじめに 先週、Red Hat Forum 2014/Tokyoで日本のオフィスに来ていたChris Wrightと会話をする機会があり、Intel DPDKについて、いろいろ教えてもらいました。Chrisは、以前は、Linuxカーネルや仮想化（Xen/KVM）の開発に深く関わっていましたが、現在は、「Technical Director of SDN at Red Hat」という肩書で、SDN関係の仕事をしています。OpenDaylightのボードメンバーやOpenStackのNFVサブチームにも参加しています。 Intel DPDKの話題になったのは、まさにこの
Kernel bypass
In two previous posts we've discussed how to receive 1M UDP packets per second and how to reduce the round trip time. We did the experiments on Linux and the performance was very good considering it's a general purpose operating system. Unfortunately the speed of vanilla Linux kernel networking is not sufficient for more specialized workloads. For example, here at CloudFlare, we are constantly dea
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
別のプロセスにファイルディスクリプタを転送する - Blog by Sadayuki Furuhashi
UNIXドメインソケット経由でファイルディスクリプタを別のプロセスに渡すことができるらしいと言うことで、試してみました。Manpage of UNIX Manpage of SEND 標準出力を別のプロセスに渡してみます。渡された側のプロセスは、自分の標準入力からの入力を、渡された標準出力に出力しています。 ライブラリ（fdtransport.h）： #ifndef FDTRANSPORT_H__ #define FDTRANSPORT_H__ #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/socket.h> #include <sys/un.h> #include <fcntl.h> #include <string.h> /* UNIXドメインソケットを待ち受ける */ /*
Queueing in the Linux Network Stack | Linux Journal
Packet queues are a core component of any network stack or device. They allow for asynchronous modules to communicate, increase performance and have the side effect of impacting latency. This article aims to explain where IP packets are queued on the transmit path of the Linux network stack, how interesting new latency-reducing features, such as BQL, operate and how to control buffering for reduce
Receive-Side Scalingについての調査メモ - syuu1228's blog
Kernel/VM Advent Calendar ４日目: Linuxのネットワークスタックのスケーラビリティについて - かーねる・う゛いえむにっきで書いたReceive-Side Scalingの記述が未だ理解が足りず不正確だと思ったので、調べ直してみてる所。 Multi-queueなNICってなに RPS提案のメールにこんな事が書いてある： This effectively emulates in software what a multi-queue NIC can provide, but is generic requiring no device support. 要約すると「multi-queue NICが提供している機能をソフトウェアエミュレートするのがRPS」 →じゃあmulti-queueなNICってどれで、どんな機能を提供してるんだろう？ それらしいNICを探して
The Performance Analysis of Linux Networking – Packet Receiving
Please select an authentication system to verify your identity. NOTICE TO USERS This is a Federal computer (and/or it is directly connected to a Fermilab local network system) that is the property of the United States Government. It is for authorized use only. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of this system and all files on thi
Library Operating System for Linux #netdev01
This document introduces a library operating system approach for using the Linux network stack in userspace. Some key points: - It describes building the Linux network stack (including components like ARP, TCP/IP, Qdisc, etc) as a library that can be loaded and used in userspace. - This allows flexible experimentation with and testing of new network stack ideas without modifying the kernel. Code c
第8章 ネットワーキング Red Hat Enterprise Linux 6 | Red Hat Customer Portal
パフォーマンスチューニングガイド 1. 概要 Expand section "1. 概要" Collapse section "1. 概要" 1.1. 本書を読むにあたって Expand section "1.1. 本書を読むにあたって" Collapse section "1.1. 本書を読むにあたって" 1.1.1. 対象読者 1.2. リリースの概要 Expand section "1.2. リリースの概要" Collapse section "1.2. リリースの概要" 1.2.1. Red Hat Enterprise Linux 6 における新機能 1.2.2. 水平方向のスケーラビリティ 1.2.3. 分散システム 2. Red Hat Enterprise Linux 6 のパフォーマンス機能 Expand section "2. Red Hat Enterprise Li
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Netdev | Netdev 2.2 - Session
Netdev | Netdev 2.1
Linux Networking
RHEL6のマルチキューで効率的なネットワークの付加分散
TCP Implementation in Linux: A Brief Tutorial
paper.dvi