Linuxでネットワークの監視を行えるモニタリングコマンド20選 | 俺的備忘録 〜なんかいろいろ〜
今回は、Linux上でネットワークトラフィックの監視を行えるモニタリングコマンドについて、数あるコマンドから20個を紹介する。 1.iftop 以前にこちらでも書いているiftopは、個別のソケットで受信・送信パケットをひと目で見る事が出来るコマンド。 通信ごとに個別のプロセスを表示させることは出来ないが、どのホストとの接続がどの程度の帯域を使用しているのかはひと目で分かるだろう。 以下のコマンドでインストールが出来る。 sudo apt-get install iftop # Debian/Ubuntuの場合 sudo yum install iftop # RHEL系の場合 2.bmon 『bmon』は、グラフでトラフィックの負荷を表示してくれるモニタリングコマンドだ。 どのNICのトラフィックを表示させるかを上下キー、モニタリングを行うパケットの種類を左右キーで選択する。 このコマン
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
【linux】【bash】【network】サーバのトラフィックを監視するワンライナー - サイトウさんのサイト
サーバのトラフィックをリアルタイムで監視するワンライナーを書きました。 もしかしたら需要があるかもしれないと考え、晒させていただきます！ 経緯 別ネットワークに存在するサーバ間で、大量のデータを転送したい 回線圧迫を避けるためにrsyncで帯域制限をかけながら転送。でも本当に意図通りの制限がかかっているか不安。 CactiやMRTGではリアルタイム監視できないし… iftopとか入れて使うのもありだけれど、別サーバで需要がある度にインストールするのもな… と悩んで方法を色々探していたのですが、発見できませんでした。 そこで、ひとまず以下の形で落ち着きました。 方法 以下を実行していただければリアルタイムで確認できると思います。( 無理やりなワンライナーであることは気にしないでください。 ) tcコマンドを使って計算しています。 while : ; do _T1=$( /sbin/tc -s
LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。 結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、 TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jp
TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace
サーバのトラブルシューティングにsysdigが使えそう - $web->{note};
sysdig とは？ Sysdig is open source, system-level exploration: capture system state and activity from a running Linux instance, then save, filter and analyze. Think of it as strace + tcpdump + lsof + awesome sauce. With a little Lua cherry on top. http://www.sysdig.org/ 上に書いてある通り、一言で言うと strace + tcpdump + lsof + α。tcpdumpのように-wで書き出して-rで読み込めるのがありがたい。 高機能過ぎてまだ全然使いこなせてないけど、ぱっと触った感じ使えそうだなと思ったものを紹介。 1. プロ
Geekなぺーじ : 拙著「Linuxネットワークプログラミング」の紹介
拙著「Linuxネットワークプログラミング」に関する情報ページです。 サンプルプログラムダウンロード、はじめに/目次/Chapter 1～3までのサンプルPDF、書籍中の間違いに関する情報を扱っています。 参考：拙著に関して発売時に書いたブログ記事。拙著中のコラムを書く過程で書いたブログ記事「いいから殺せ。後はこっちでなんとかするから」。 サンプルプログラム (間違い箇所の修正対応済み) まとめてダウンロード(tar.gz) 2-2 IPv4＋TCPによるソケット実装例 2-4 ファイルディスクリプタが0となる場合 2-5 単純なTCPサーバの実装 2-6 単純なTCPクライアントの実装 2-9 socket()システムコールを失敗させる 2-10 注意すべきエラー処理 2-11 printfをperrorの前に実行したケース 2-12 bind()を行わない場合 2-19 単純な名前解決
拙著「Linuxネットワークプログラミング」:Geekなぺーじ
「Linuxネットワークプログラミング」という本を書きました。 LinuxでCを利用してネットワークプログラミングを行うための解説書で、私にとって初の書籍執筆です。 昨年２月にソフトバンククリエイティブさんから書籍執筆のオファーを頂き、開始から約一年後の発売となります。 今回、C言語によるLinuxのネットワークプログラミング解説書籍を執筆する機会を頂けたのですが、書籍の大きな方向性として以下の点が挙げられます。 可能な限り、ソースコード全文を掲載する。断片的なソースコードだと手元で即座に試しにくい メインはIPv4を意識しながら書く ただし、getaddrinfo()を前提とし、IPv6が存在することを前提に書く IPv6移行がメインの書籍ではない。インターネットの世界がIPv4/IPv6デュアルスタックで運用されることになるという前提でネットワークプログラミング解説書を書いているだけ
Linux / UNIX & ネットワーク 参考サイト
Linux / UNIX & ネットワーク 関連の参考サイトと書籍 最終更新 : 2006/3/18 Linux / UNIX & ネットワーク 関連で、 主にソフトウェア開発者向けの参考サイトや書籍等の紹介とリンクです。 0. 目次 書籍 プログラミング Linux 情報・解説 用語等の検索（日本語） 用語等の検索（英語） 用語集 RFC ネットワーク 情報・解説 GNU GPL などのオープンソース Apache などのWebサーバ関連 団体 1. 書籍 詳解 UNIXプログラミング ... 「Advanced Programming in the UNIX Environment(1st ed.)」 の邦訳。名著です。UNIX系のプログラミングをする際には必ず机の上に置いておきたい一冊。 UNIX ネットワークプログラミング 第２版 Vol.1
Linux の TCP/IP チューニング・パラメータ
TCP のチューニング・パラメータ 接続確立関係のチューニング・パラメータ TCP のチューニング・パラメータ TCP のチューニング・パラメータは、以下のコマンドで取得できます。 なお、以下は Linux のものです。 >cat /proc/sys/net/ipv4/tcp_retrans_collapse 1 >cat /proc/sys/net/ipv4/tcp_keepalive_probes 9 >cat /proc/sys/net/ipv4/tcp_keepalive_time 10800 >cat /proc/sys/net/ipv4/tcp_syn_retries 10 >cat /proc/sys/net/ipv4/tcp_sack 1 >cat /proc/sys/net/ipv4/tcp_timestamps 1 >cat /proc/sys/net/ipv4/tcp
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
Note - ソケットバッファのチューニング
Overview ADSLや光回線などの充実によって，ここ数年でネットワークの回線速度もかなり進歩してきました．ですが，Linuxの バージョンによっては，一昔のネットワーク速度を基準としてパラメータの設定を行っているためにネットワーク帯域を フル活用できていない場合もあります（特に，1Gbpsを超えるような場合はその可能性が高い）．そこで，今回はボトルネック の一つとなりやすいバッファサイズのチューニング方法について記述します． sysctl変数の設定 Linuxにおいてシステム全体のバッファサイズを変更する場合には，sysctlコマンドを使用します．設定する項目は， 下記の9種類です（ Manpage of TCP参照）． net.ipv4.tcp_window_scaling RFC 1323のTCPウィンドウスケーリングを有効にします．この機能を用いると，（接続先が対応していれば）
ミニマルなHTTPサーバ - かそくそうち
http://0xcc.net/blog/archives/000178.html このコードには長時間動作させる上で明らかにマズい点が二つあります。 (22:58追記: 問題のコードは既に修正されています。高林さん、すばやい対応ありがとうございます。) 「UNIXネットワークプログラミング」の別の節に解説はありますが、コードだけコピペした人が困らないよう指摘しておきます。 一つ目はSIGPIPEシグナルの発生に備えていない点です。 サーバーがレスポンスを返す前にクライアントがソケットを閉じてしまうと、write()がSIGPIPEシグナルを生成することがあります。 SIGPIPEの既定の動作はプロセスの終了なので、この状況が発生しただけでサーバーは勝手に(coreを残さず)終了してしまいます。 通常は次のような関数でSIGPIPEを無視します。 #include <cstring> #i
Perl でローカルのアドレスを取得する - naoyaのはてなダイアリー
ifconfigの出力をsedでパース — ありえるえりあ まだ Linux を触り始めて間もない頃に、サーバーを構築していてローカルの IP アドレスをシェルスクリプトから利用する必要があって、どうやって取得するべきだろうかと小一時間悩んだのですが結局分からず Perl の正規表現で ifconfig を parse したことがありました。ioctl() を使ってデバイスを操作する必要がある、ということを知ったのは数年後、割と最近のことです。なんということでしょう。 では、Perl で IP アドレスを取得する場合ですがモジュールを使ってよいのであれば IO::Interface がよいだろうと思っています。IO::Interface は Pure Perl ではありませんが、XS で ioctl() を呼び出しているので比較的高速且つ素直な実装だと思います。 #!/usr/local/
ithreads でスレッドプール - naoyaのはてなダイアリー
マルチスレッドなサーバー実装を色々模索していて、Perl の ithreads で遊ぶ。ithreads は Linux の pthread にリンクさせた perl なら一応 NPTL で動いてくれるので、pthread アプリケーションの設計を試すのにも良い。 試しににやってみたのは、たとえば mod_perl とかで重い SQL でブロックするのが嫌なときとかにそれを別プロセスに丸投げしてやる、その丸投げされる側のサーバー実装。(やりたいことだけに関して言うと、TheSchwartz に似てる) クライアントとサーバーの IPC は UNIX ドメインソケット メッセージングのプロトコルは JSON サーバーはクライアントからのリクエストをバッファリングしたら、SQL を実行する前にクライアントとの接続を切断 この時点でクライアントは制御が戻る サーバーは内部ではフロントエンド /
inetd の仕組みを見てみる - naoyaのはてなダイアリー
inetd や xinetd (以下 inetd) はインターネットサービスをデーモン化するのに共通している処理を担い、ほとんどの時間をアイドル状態で過ごすその手のサービスに必要なリソースを節約する役割を果たします。 inetd のひとつ面白いところは、inetd でサービス化したいプログラムの標準入力/標準出力がクライアントソケットの入出力に接続されるところです。例えば daytime 相当のサービスを自分で作ろうと思った場合 #!/usr/local/bin/perl # daytime.pl use strict; use warnings; use DateTime; use IO::Handle; STDOUT->autoflush(1); STDOUT->printf( "%s\n", DateTime->now(time_zone => 'Asia/Tokyo') ); と標
prefork サーバーと thundering herd 問題 - naoyaのはてなダイアリー
Catalyst を POE で動かす Engine の Catalyst::Engine::HTTP::POE という実装が CPAN にあります。"Single-threaded multi-tasking Catalyst engine " だそうです。"Single-threaded" と言いつつも実装を覗いてみると環境変数 CATALYST_POE_MAX_PROC を 1 よりも大きく設定することで prefork する実装になってます。POEシングルスレッドではアプリケーション内で発生するブロックを避けることが難しいのでそのための実装じゃないかなと思います。 ところでこの Catalyst POE エンジン、prefork の実装はどのように行っているかというと POE から prefork と名の付いたイベントが発生するとおもむろに子プロセスを生成する、というのもの。複数の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ncコマンド (netcat)
IBM Developer
「TCPの再送処理について」（1） Master of IP Network － ＠IT