NFSでI/Oシステムコール発行後に応答がない場合、プロセスを kill できるか - ablog
NFSのマウントオプションで soft と hard がある。プロセスがI/Oシステムコールを発行してユーザーモードからカーネルモードにコンテキストスイッチした後、応答がないと、soft の場合はリトライを繰返した後にI/Oエラーになるが、hard の場合は応答があるまで待ち続ける。 hard + intr: kill できる*1。おそらく TASK_INTERRUPTIBLE でスリープするため。 hard + nointr: kill できない。おそらく TASK_UNINTERRUPTIBLE でスリープするため。 Kernel 2.6.25 以降、TASK_KILLABLE が導入され、NFS Client のコードでI/Oシステムコール発行後、TASK_KILLABLE でスリープするよう変更が入り、マウントオプションに hard を指定しても kill できるようになっている。
"Reducing Memory Access Latency" が素晴らしすぎる - ablog
Reducing Memory Access Latency by Satoru Moriya (Hitachi LTC) が素晴らしすぎるのでメモ。 まとめ vm.swappiness = 0 により、解放可能なページキャッシュがあるうちはプロセスのメモリ(anon page)をスワップアウトしないようにできる*1。 swappines=0 にしても 解放可能なページキャッシュがあるのにプロセスのメモリがスワップアウトされる問題があったが、この資料を書いた守屋さんのパッチが Kernel 3.5 にマージされている → mm: avoid swapping out with swappiness==0 extra_free_kbytes で kswapd がページ回収を開始する閾値を上げ、direct reclaim が発生しにくくできる Kernel 3.2 以降、direct rec
プロセスのランキュー待ち時間とI/O待ち時間を調べる - ablog
cat file|awk では実行時間 < CPU時間となっていますが、cat が I/O wait していないとは限りません。実行時間は単純に終了時間 - 開始時間で算出しますが、CPU時間はプロセスのCPU時間を getrusage システムコールで取得します。catのプロセスと awk のプロセスが並列実行されている期間があるため、実行時間 < CPU時間となっています。例えば、CPUバウンドな2プロセスがほぼ完全に並列実行されると、実行時間 * 2 ≒ CPU時間 となったりします。 （中略） 大きなテキストファイルをawkで処理するときにcatで投げ込むと速い理由 - ablog と書きましたが、プロセスの ランキュー待ち時間は /proc//sched の2列目(sched_info.run_delay) I/O待ち時間は /proc//schedstat の se.stati
funcgraph で Linux カーネル内のボトルネックをミクロに追跡する - ablog
perf + Flame Graphs で Linux カーネル内のボトルネックを特定する - ablog で Linux カーネル内のボトルネックをマクロに分析する方法を紹介しましたが*1、 strace でI/Oシステムコールのレスポンスを調べると遅く*2、 iostat の await でカーネルのブロックレイヤーのI/Oレスポンスを調べると速い場合、 システムコールインターフェースとカーネルのブロックレイヤーの中間(ファイルシステムレイヤーなど)で詰まっていると考えられます*3。 このようなケースで、1回のシステムコール発行の所要時間の内訳*4をミクロに追跡するには Brendan Gregg の funcgraph が便利です*5。 実行結果 # ./funcgraph -Htp 4511 vfs_write Tracing "vfs_write" for PID 4511...
strace でシステムコールの所要時間を調べる - ablog
システムコールの所要時間は strace の -T オプションで調べることができる。 上はEXCELでピボットテーブルを使ってグラフ化したもの I/Oレスポンス（read システムコールの所要時間）は5〜15ミリ秒であることがわかる 例 strace でシステムコールのトレースを取得する $ strace -ttT -o strace-T_fs_`date +'%Y%m%d%H%M%S'`.log dd if=OVMRepo.vmdk of=/dev/null iflag=direct bs=1M count=1000 -T: システムコールの所要時間（秒.マイクロ秒）を出力 ※マイクロ秒=1/1,000,000秒 -tt: タイムスタンプをマイクロ秒で出力 -o: トレースを指定したファイルに出力 出力結果 $ less strace-T_fs_20150111143101.log [.
Javaのスレッドダンプの読み方 - ablog
あなたとスレッドダンプ - スレッドダンプ入門 - この国では犬が が非常にわかりやすく、自分でブログエントリを書く必要はないが、Oracle Database や Linux の性能分析に携わる者の観点から Java のスレッドダンプについて整理してみた。具体的なスレッドダンプの分析方法はサポートエンジニアが語るWebLogic Serverトラブルシュートのノウハウがとてもわかりやすい。 WebLogic のスレッドダンプの見方については id:yamadamn さんの スレッドダンプから見るWebLogic Serverの世界 #javaee - yamadamnのはてな日記 がわかりやすい。 スレッドダンプとは Javaのスレッドのスナップショット。 取得した瞬間のJava仮想マシン(JVM)内に存在するスレッド（ID、名前、状態、タイプなど）とコールスタックを見ることができる。
"Linuxのしくみを学ぶ - プロセス管理とスケジューリング"を読んだ - ablog
id:syuu1228 さんのLinuxのしくみを学ぶ - プロセス管理とスケジューリング がとてもわかりやすかった。ここまで分かりやすさと深さを両立した説明は初めて読んだ。プロセススケジューラの自分用の備忘録です。 タイマ割込みのタイミングでプロセスの切り替えが起こる Linux 2.4 のランキューは単純なリスト構造で線形探索になるので探索コストがO(n) O(1)スケジューラは優先度ごとのプロセスリストの配列になっているので計算量はO(1) CFSではプロセスが使用したCPU時間と優先度による重み付けをして昇順に並べて先頭のプロセスを実行する。赤黒木が効率が良いので使われている。 赤黒木はO(log n)だが、プロセス数が多くなるとO(1)との差がわずかになる スケジューラのアルゴリズム上ほとんど左端しか参照しないので、ノードのポインタをキャッシュすることでさらに高速化している Li
iostat はどのように %util を算出しているか(3) - ablog
iostat はどのように %util を算出しているか - ablog http://d.hatena.ne.jp/yohei-a/20130925/1380070554 と続いた iostat から Linux Kernel のブロックレイヤーへの旅は Etsukata blog: iostat -x の出力を Linux Kernel ソースコードから理解する のおかげでほぼ終わりを迎えました。 part_round_stats() では、その延長で、全てのリクエストがキューにいた時間の積算値を表すtime_in_queue と、デバイスがIOリクエストを発行していた時間を表す io_ticks を更新しています。io_ticksには前回のリクエスト完了から、今回のリクエスト完了までを加算し、time_in_queueにはそれに実行中のリクエスト数を掛けたものを加算しているのがわかり
gettimeofday(2) は VDSO によりユーザー空間で実行される - ablog
gettimeofday(2) はシステムコールなので、大量に発行すると%sysが上がると思っていたが、VDSOという仕組みでユーザー空間で実行されるので%userが上がるらしい。時刻取得みたいなちょっとした処理でシステムコールを発行してコンテキストスイッチするのって無駄が多いなって思ってたけど、そこはちゃんと考えられているんですね。 多くのアプリケーション負荷 (特にデータベースおよび財務サービスアプリケーション) は gettimeofday または類似の時間機能コールを非常に頻繁に実行します。 このコールの効率性を最適化すると、 大きな利点があります。 VDSO (Virtual Dynamic Shared Object) は、 ユーザースペースのアプリケーションがシステムコールよりも少ないオーバーヘッドで一部のカーネルアクションを実行できるようにする共有ライブラリです。 多くの場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RHEL6互換ディストリビューションでの不要サービス - ablog
