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を読む実装では、次のよう
読書メモ: 「Designing Data-Intensive Applications」Chapter 1. Reliable, Scalable, and Maintainable Applications - ゆううきメモ
感想 Chapter1は、本書のサブタイトルにもなっている、データシステム全体の非機能要件に関する用語(Reliability, Scalability, Maintainability)の定義をしている。 もうわかってるよととばしたくなるけれど、人に説明するときのリファレンス元として重宝する。 Figure 1-1の図のようなことをインフラと呼ぶこともあったけど、インフラが指す範囲が広すぎることとなんでもインフラがやることになってしまい、この層のシステムを指す用語として、データシステム、もしくはData-Intensive Applicationsと名をつけていることがよい。 Scalabilityに関するTwitterのタイムラインアーキテクチャの例が簡潔に紹介されていておもしろかった。 書籍「Designing Data-Intensive Applications」下読み - ゆう
tcpdumpでMySQLサーバに流れてくるクエリをみる - ゆううきメモ
社内のMySQLマスターのtcpdumpの様子。マスタ切り替えした後に切り替え先でクエリが流れているかをみる。単に3306ポートのパケットを流すだけでもよいが、接続確立に失敗しているがパケットは流れてくるという状況もあるので、SQL文が流れているかまでみるのがよい。 tcpdump -tttt -l -i eth0 -A -n -s 0 dst port 3306 | grep -iE "select|update|delete|insert" -tttt は人間に読みやすい形式のタイムスタンプを付与する -l は line buffered。パケット数の大きい環境で負荷を軽くする -A はアスキー表示 -n はIPアドレスの逆引きをしない。DNSリゾルバに負荷をかけないため -s 0 は出力をtruncateせずに全部だす -iはネットワークインタフェースを指定。複数のインタフェースがつ
LinuxサーバでネットワークI/Oで刺さっている接続先を発見する - ゆううきメモ
Linuxサーバの障害対応で社内で伝統的に使われているテクニック。I/Oで完全にブロックしているポイントを特定するノウハウ。 問題対応のため、怪しいプロセスをstraceしてみる read(2)やwrite(2)でブロックしていることを発見する read(2)やwrite(2)、connect(2)の引数にはファイルディスクリプタ番号がみえる プロセスIDとファイルディスクリプタ番号を使って、/proc//fd/ の中身をみると、ソケットI/Oで刺さっている場合はソケット番号を発見できる netstat からソケット番号でgrepして接続先を発見する [y_uuki@hogehoge ~]$ sudo strace -p 10471 Process 10471 attached - interrupt to quit read(58, <unfinished ...> Process 10
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型ウェブサーバだと、計算機資源が十分あると仮定すると、ワーカープロセス数で決まることが多い。 しかし、マルチスレッド型やイベント駆動型の場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
