prociostat.pl と visualize_prociostat.R で Linux のプロセスのボトルネックを分析する - ablog
今日もモツ鍋を堪能されていた模様の [twitter:@hasegaw] さんが Linux のプロセスのアクティビティを追跡してグラフ化するツールを Perl + R で作られたということで早速使ってみました。 プロセスがユーザーモードでCPUを使えているのか、I/O待ちになっているのかといった傾向を分析することができます。Oracle Database はCPUを使えているのか、どんな理由で待機している（CPUを使えていない）か見ることができるよう実装されていますが、そんなものはないプログラムでも /proc ファイルシステムを参照してプログラムの外側からボトルネック分析が可能になります。素晴らしい！ こんな感じのグラフができます。 ツール prociostat.pl プロセスのCPU使用率、I/Oバイト数、I/O待機時間*1を秒間隔でCSVに記録する Perl スクリプト*2 情報ソ
CFQ スケジューラのアルゴリズム概要 | 技術文書 | 技術情報 | VA Linux Systems Japan株式会社
cfqスケジューラ Linuxカーネルは、ブロックI/Oの処理効率を向上させるさせるための仕組みとして、I/Oスケジューラと呼ばれる機能を提供しています。I/OスケジューラはI/O要求の順序を入れ替えることにより、スループットを向上させたり、特定のI/O要求を優先して実行させたりします。実際のブロックデバイスのセクタに対するアクセス（つまり読み書き）を、要求された順序ではなく、I/Oを最も効率よく行うためにその順序を並び替えるというアイデアは、初期のUNIXの実装から採用されていました。それは、セクタ番号順序に並び替えてI/Oを実行するという単純なものです。ディスク面上を移動するヘッドの動きがエレベータに似ているため、このアルゴリズムはエレベータアルゴリズムなどと呼ばれていました。 現在のLinuxカーネルでは、そのころのアルゴリズムより洗練されたスケジューリング方式を採用しており、目的に
Linux Storage Stack Diagram - Thomas-Krenn-Wiki-en
The Linux Storage Stack Diagram shows the layout of the the Linux storage stack. Downloads Diagram for Linux Kernel 6.9 Linux Storage Stack Diagram v6.9): Linux I/O Stack Diagram v6.2 (20230309): ZIP (includes .drawio and .svg) PDF PNG Changelog: dm-vdo added (Kernel 6.9) ext2 removed (Kernel 6.9, ext2 wird nun so wie ext3 auch durch den ext4 Code unterstützt) bcachefs added (Kernel 6.7) EROFS add
Linux I/O scheduler queue size and MyISAM performance
At MySQL Conference and Expo 2009, I explained how Linux I/O scheduler queue size affects MyISAM insert performance. It is well known that Linux implemented four types of I/O schedulers (noop/deadline/anticipatory/cfq) in Linux kernel 2.6.10. The default is cfq in most distributions including RHEL, which is not so good then noop normally outperforms, but I'll talk this in other posts. Linux I/O sc
Etsukata blog: iostat -x の出力を Linux Kernel ソースコードから理解する
はじめに iostat は IO の出力速度や待ち時間の計測によく使われるコマンドです。"-x" オプションをつけると、平均待ち時間(await)やリクエストキュー長(avgqu-sz)、サービスタイム(svctm)などの詳細な情報を出力することができ、とても便利です。データベースをはじめとし、各種アプリケーションのパフォーマンスを計測するための重要な指標となります。 今回は、これらの出力結果について、より詳細かつ正確な意味を、Linux Kernelのソースコードを読んで理解しましょう。かなり長くなってしまったので、意味を把握したい方は下の方の "iostat -x 出力結果まとめ" をご覧ください。 iostatの挙動 まず、iostatの挙動を調べます。iostatは、read_sysfs_file_stat()で指定したインターバルごとに /proc/diskstats の情報を読
SSDにしたのでI/Oスケジューラを noop に変更してみた - ablog
PC の HDD を SSD に変更したので、I/Oスケジューラを noop に変更してみた。 SSD は HDD のようにシーク（目的のレコードが記憶されたシリンダにヘッドを移動）したり、サーチ（目的のセクタの先頭がヘッドの位置に来るのを待つ）したり、物理的な動きはない。なので、OSのI/OスケジューラでソートなんかせずにI/Oリクエストを渡してくれたほうが速いとという話だと思う。 簡単に noop が速いことを検証した上で、noop に変更した。 cfq I/Oスケジューラを cfq に設定する [root@yazekats-linux queue]# echo cfq > /sys/block/sda/queue/scheduler [root@yazekats-linux queue]# cat /sys/block/sda/queue/scheduler noop deadlin
Optimizing SSDs random IOPs
Optimizing SSD random IOPS The script Some time ago I was asked how to max out the random IO performance of an SSD RAID0 array. Here is what I came with after experimenting with fio and perf top. ls /sys/class/block/|while read device do # SSD random iops are better with no scheduler if [ -f /sys/class/block/$device/queue/scheduler ]; then echo noop> /sys/class/block/$device/queue/scheduler fi # I
Epoll - from the kernel side
The document discusses the basics of I/O and event-driven I/O models in Linux like blocking I/O, non-blocking I/O, I/O multiplexing using select/poll and their internals. It then introduces epoll as a more efficient alternative to select/poll and describes its user-space API, kernel structures and how it works by adding file descriptors to an epoll instance and waking up blocked processes on I/O e
iowait について - ablog
iowait の時間って、I/O要求を出しているプロセスは Disk Sleep しているという理解でいいんだろうか。 ちょっとわからなくなってきた。 linux-2.6/kernel/sched.c /* * Account for idle time. * @cputime: the cpu time spent in idle wait */ void account_idle_time(cputime_t cputime) { struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat; cputime64_t cputime64 = cputime_to_cputime64(cputime); struct rq *rq = this_rq(); if (atomic_read(&rq->nr_iowait) > 0) cpu
個人的epollめも - 愛と勇気と缶ビール
仕事柄、「ああいうデカいサイズのファイルアップロードとか、preforkでやるべきじゃないよね。イベントモデルじゃないと厳しい」とかそんな話をすることがあって、「確かにpreforkだとあの場合すぐプロセスが埋まっちゃいますよね」とか自分も分かったようなことを言うのだけども、裏側のことは特にはっきりと理解しているわけでなく、イベントモデルだと1プロセスで大丈夫だとか、下手にブロックしちゃうと死んじゃうとか、聞きかじっただけの知識でそういうことを何となく語ってしまう自分に不意に背筋がゾッとする、そのようなことも秋の夜長にはございます。 そのような良心の問題とは特に関係なく、ネットを漂流してほどよいサンプルを見つけたのでふんわりとした自分用のメモ。 http://www.oreilly.co.jp/community/blog/2010/03/pthread-epoll-inet-server
カーネル２．６の実力を探る NTTコムウェア株式会社 Linuxセンタ 佐々木博正
Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003
SSDをHDDのキャッシュにする「bcache」、Linuxカーネルに登場
次期Linuxカーネルバージョン3.10の目玉機能のひとつになるとみられる「bcache」がカーネルソースツリーにマージされた。bcacheはLinuxのカーネルレベルで動作するブロックレイヤキャッシュの実装系。特定のデバイスを他のデバイスのキャッシュとして利用できるという機能。ここでは主にHDDのキャッシュとしてSSDを活用するケースが想定されている。 bcacheが提供するキャッシュ機能はZFSのL2Arcの動作に似ているが、bcacheはライトバックに関してもキャッシュを実施するという違いがある。デフォルトの設定ではシーケンシャルアクセスに対してはキャッシュを提供せず、ランダムI/Oに対してキャッシュを提供する。SSDの特性を活かし、もっとも効果がでるケースでSSDを動作させる。実装はトランスパレントになっており、利用するにあたってアプリケーションやユーザ側に変更の必要はない。 bc
VFS and Block I/O
Copyright© 2002, VA Linux Systems Japan K.K. All right reserved. VFS and Block I/O VA Linux Systems Japan Hirotaka.Sasaki sasaki@valinux.co.jp Copyright (C) 2002, VA Linux Systems Japan K.K., All rights reserved. 目次 ● ファイルシステム概要 ● VFS（仮想ファイルシステム） ● ページキャッシュとバッファキャッシュ ● ブロックI/O共通レイヤ Copyright© 2002, VA Linux Systems Japan K.K. All right reserved. ファイルシステム概要 Copyright (C) 2002, VA Linux Systems Japa
Block I/O Layer Tracing using blktrace
blktrace is a really useful tool to see what I/O operations are going on inside the Linux block I/O layer. So what does blktrace provide: plenty of block layer information on I/O operations very low level (2%) overhead when tracing highly configurable - trace I/O on one or several devices, selectable filter events live and playback tracing There are many different types of events that can be captu
Linuxhack.jp » キャッシュバッファの制御
pdflushを制御してLinuxのキャッシュバッファのチューニングを考えてみたいと思います。 kernel2.6系から書き込みに関するキャッシュバッファ管理はpdflushによって実現されています。これはkernel2.4系の時代にはbdflush+kupdateの組み合わせで実現されていたものです。このpdflushを制御することにより、ディスクI/Oを向上させる可能性があります。 ※ 当然ですが、パフォーマンスが向上するか否かは環境によります。 ・Linuxの遅延書き込み機構（ざっくりと） 一応、前提となる遅延書き込みについて簡単に触れておくと、データの書き込みは1次記憶装置から2次記憶装置へ・・・みたいな感じで、徐々に記憶容量の多いほうに渡されていきます。一般的に記憶容量が多くなるに反比例して記憶装置へのアクセスは遅くなりますね。 要はメモリからHDDへのディスク媒体にデータが書
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
10分で分かるLinuxブロックレイヤ
Tracing a specific process with ftrace | eballetbo
tracing_onとtracing_enable (ftrace) - moriyasator.memo
20061021 2 6_io_sched
Linux Kernel Tuning for GlusterFS