LinuxでTCP/UDPコネクション状態にプロセス情報を紐付ける方法 - ゆううきメモ
Linuxでは、/proc/net/*やNetlinkソケットを通じて、TCP/UDPのコネクション情報を取得できる。 しかし、ここで取得したコネクション情報は、コネクションを保有するプロセスに関する情報(pidなど)を含んでいない。 ssコマンドの--extendedオプションは、inode番号を表示することから、inode番号からプロセス情報を辿ることを考える。 当該プロセスのpidがわかっていれば、/proc/<pid>/fd以下から、次のようにsocket inode番号を知ることができる。 ubuntu@yuukidev01:~$ sudo readlink /proc/21326/fd/6 socket:[16801] しかし、inode番号からそのinodeを保持しているpidを直接知ることはおそらくできない。 そこで、次のようなTCP/UDPのコネクションリストとプロセスリ
TCP接続を集約表示するlstfでNetlinkにより実行速度が1.6倍になった - ゆううきメモ
Linuxサーバ上でホスト間コネクションを集約表示するツール lstf をつくった - ゆううきメモ にて紹介したlstfのホスト上のTCPコネクション情報の取得処理において、/proc/net/tcpを読みだす代わりに、Netlinkソケットを利用することで、実行速度が1.6倍になった。lstfのバージョン0.4.0で使えるようになる。 実験 約40,000接続あるWebサーバ上にて、lstfコマンドの実行時間を名前解決時間を含まずに比較する。 実験環境はEC2のc4.2xlarge、Debian 8.10、Linuxカーネル3.16であり、リバースプロキシとしてnginxが動作している。 接続数は次のコマンドよりだいたい40,000接続であることを確認する。 [y_uuki@hoge ~]$ ss -tan | wc -l 39264 /proc/net/tcpを読む実装では、次のよう
GoバイナリのGitHubリリース: gobump + ghch + goxz + ghr - ゆううきメモ
最近は、GoバイナリのGitHubリリースにgobump、ghch、goxz、ghrを利用している。これらのツールを組み合わせることで、repairableな形でリリース作業を自動化できる。 GoバイナリのGitHubリリースに一般的に必要な一連のプロセスを分解すると、下記のようになる。 バージョニング CHANGELOGの生成 クロスコンパイル: Linux、OSX、Windows用バイナリの作成など パッケージング: tar.gzの作成など GitHub Releaseへのアーカイブアップロード 各ステップを担当するミニマムなツールを組み合わせ、一連のプロセスを実行できる。*1 gobump: https://github.com/motemen/gobump バージョニング ghch: https://github.com/Songmu/ghch CHANGELOGの生成 goxz:
Linuxサーバ上でホスト間コネクションを集約表示するツール lstf をつくった - ゆううきメモ
概要 netstatやssコマンドにより、あるホストと他のホストとのコネクションを一覧表示できる。しかし、Webシステムの場合、クライアントが並行接続するため、 同一ホストから複数のポートを介してコネクションを確立しているケースが多い。コネクション数が大きい場合は、1万以上のコネクションが表示され、ホスト間のコネクション状況を人間の目で概観することが難しかった。 そこで、同一ホストとのコネクションを集約表示し、コネクション状況を概観する 「lstf」 (「えるえすてぃーえふ」)コマンドをつくった。 github.com lstfの特徴は以下の通り。 コマンド実行ホストを起点に、active openコネクションかpassive openコネクションを判定する。つまり、接続をする側かされる側かを判定する。 各ホストフローごとにコネクション数を表示する Goで実装されているポータビリティ。i3
リトルの法則とキャパシティプランニング - ゆううきメモ
(引用: Systems Performance figure 2.18 Queueing Model) リトルの法則とは、安定した系において、平均待ち行列数は、平均到着率と平均待ち時間の積に等しい、という法則である。 (Systems Performanceの原文ではaverage service timeになっていたが、正確にはaverage wait time) 例えば、平均到着率はスループット、平均待ち時間はレイテンシ、平均待ち行列数は、同時処理リクエスト数と捉えることができる。 計算機システムの場合、安定してサービスするためには、同時処理リクエスト数がシステムの上限を超えないことが重要。 同時処理リクエスト数の限界は、例えば単一のprefork型ウェブサーバだと、計算機資源が十分あると仮定すると、ワーカープロセス数で決まることが多い。 しかし、マルチスレッド型やイベント駆動型の場
Go言語をほぼ毎日書いている話 (序) - ゆううきメモ
はてなの京都オフィスで開催された そうだ Go、京都。 - connpass にて、「Go言語をほぼ毎日書いている話(序)」というふわっとした話をしました。いわゆる Write Code Every Dayという活動ですね。 タイトルに(序)と付けているのは、書き始めてまだ5ヶ月程度だからです。 ちなみにこのGWでは、Rustを毎日書いていて、すでにタイトル詐欺感がありますね。 スライド スライドを以下に貼っておきます。 speakerdeck.com 同僚の id:niwatako さんの超速記により、ツイートはるだけで内容紹介できて贅沢。 去年からめっちゃGithubに草を生やしている話 #golangkyoto pic.twitter.com/xInr7G9BHT— にわタコ (@niwatako) 2017年4月29日 オペレーションよりソフトウェアや文章を書く方が実は好き ソフト
mkr + peco + tmux + ssh - ゆううきメモ
Mackerel Meetup #10 Tokyo のLT枠で「mkr + peco + tmux + ssh」というタイトルで話をしました。当日の発表スライドを以下に貼っておきます。 speakerdeck.com 話の内容は、tmux + ssh + Mackerel API を組み合わせたとにかくモダンなサーバオペレーション - ゆううきブログ の続きになります。このエントリにあるように普段から $ tssh $(roles bookmark proxy) # サービス名: bookmark, ロール名: proxy のようなコマンドを叩いて、指定したロール配下のホストに、tmuxのpaneを使って同時にsshログインしています。 しかし、ロールの数が増えてくると、そもそもロールの名前を正確に覚えていないということがしょっちゅう起きます。 そこで、peco*1 を挟んでやることで、ロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
