Introduction Perf is a profiler tool for Linux 2.6+ based systems that abstracts away CPU hardware differences in Linux performance measurements and presents a simple commandline interface. Perf is based on the perf_events interface exported by recent versions of the Linux kernel. This article demonstrates the perf tool through example runs. Output was obtained on a Ubuntu 11.04 system with kernel
Linuxのトレーサーであるperfやftraceのツールの使い方に関する情報は結構ありますが,構造に関してはあまり見つけられなかったため,ここに簡単に調べたことをまとめようかと思います.(ツールの使い方の説明はあんまりしないです.) この文章はLinux 4.15のソースに基づいています. 全体像 ftrace function trace tracepoint (static event) kprobe (dynamic event) その他のtracer trace-cmd perf PERF_TYPE_HARDWARE, HW_CACHE, RAW PERF_TYPE_SOFTWARE PERF_TYPE_TRACEPOINT PERF_TYPE_BREAKPOINT USDT (SDT Event) perf-tools perf ftrace straceとの比較 その他 pe
みなさんこんにちは.突然ですがbpftraceってご存知でしょうか? 名前から明らかなようにbpfを利用したトレーシングツールです.bpftraceの設計は以前から存在するDTraceやSystemTapに影響を受けています.それらのツールに馴染みのある人にとってはむしろ,bpftraceはDTraceやSystemTapのBPF版と言った方が(非常に雑ですが)分かりやすいかもしれません. 一般にBPFを利用してトレーシンングを実施する場合は,1) BPFプログラム本体 と 2) トレーシング結果を表示するためのユーザランドのプログラム を書く必要がありますが,bpftraceでは独自のスクリプト言語により,それらを特に意識せずにトレーシング処理が記述できます.例えば,プロセス別にシステムコール発行数を集計したい場合は以下のようにしてできます.便利ですね. % bpftrace -e 't
Back in 2016, when Microsoft announced that SQL Server would soon run on Linux, the news came as a major surprise to users and pundits alike. Over the course of the last year, Microsoft’s support for Linux (and open source in general), has come into clearer focus and the company’s mission now seems to be all about bringing its tools to wherever its users are. The company today launched the first r
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
この記事は Ruby の Advent Calendar に参加しようとして用意しましたが、間に合わなかったものです。 Ruby 2.0でdtrace対応が入りました。この機能はLinuxのsystemtapからもアクセス出来ます。でも、どこにもドキュメントがないのでいっちょ使い方を解説しようという、そういう趣旨の記事です。 まず、基本の使い方ですが、以下の様に process(プロセス名).provider("ruby").mark(Rubyで定義されてるprobe名) で引っ掛けるイベント名を 記述して、tapscriptを記述します ruby.stp probe process("./ruby").provider("ruby").mark("find__require__entry") { printf("%s %s %d\n", user_string($arg1), user_
LXCとlibvirt LXC(英語: Linux Containers)は、1つのLinuxカーネルを実行しているコントロールホスト上で、複数の隔離されたLinuxシステム(コンテナ)を走らせる、OSレベル仮想化のソフトウェアである。 Linuxカーネルが提供するcgroupsという機能を利用することで、リソース(CPU、メモリ、ブロックI/O、ネットワークなど)の制限と優先順位付けが可能になっており、そのために仮想マシンを使用する必要がない。また、名前空間の隔離(英語版)機能を利用すれば、アプリケーションから見たオペレーティング・システムの環境を完全に隔離することができるため、プロセスツリー、ネットワーク、ユーザー識別子、マウント(英語版)されたファイルシステムを仮想化することができる[1]。 LXCはカーネルのcgroupsと隔離された名前空間のサポートを組み合わせることで、アプリケ
Linux には複数のファイルシステムがあります.これらには,仕様としての機能差の他に,品質・安定度に関して大きな差があると考えられています. 今回は,そのあたりを定量的に分析した論文をご紹介. A Study of Linux File System Evolution [キャッシュ] https://www.usenix.org/conference/fast13/study-linux-file-system-evolution 調査の対象は,XFS/Ext4/Btrfs/Ext3/Reiser/JFS の 6 つのファイルシステム.これらについて,Linux 2.6.0 (Dec ’03) から 2.6.39 (May ’11) の間に取り込まれた 5,079 個のパッチを分析しています. パッチの種類 まず,パッチを次の 5 種類に分類しています. Bug バグの修正. Reli
Tizen OS採用のスマートウォッチ Tizen(タイゼン)は、LiMo Foundation、Linux Foundation、Samsungが主導するTizenプロジェクトによる、スマートフォン、タブレット、ノートパソコン、スマートテレビ、IVI用オペレーティングシステム (OS)。異なるデバイス上で共通のユーザー体験を提供することを目標としたオープンソースのシステムである。 2015年〜2017年にSamsungの一部スマートフォンに採用されたがAndroidやiOSに対してシェアが振るわず、この分野からは事実上撤退、Samsungのスマートウォッチ・スマートテレビ分野でのみ利用されてきたが、2021年5月18日、Google I/Oにて、スマートウォッチ分野におけるWear OS(Google)との統合が発表された[6][7]。スマートテレビ分野ではSamsung主導で利用が継続
日経BPのサイトに、誰も読まないOSのソース・コードという記事がアップされている。 わりと衝撃的な見出しから始まるのでさくっと引用 まず,結論から言おう。 「エンジニアがOSのソース・コードを読めるようになると,活躍の場が一気に広がる」。そして,「コツさえ分かれば,OSのソース・コードはびっくりするほど簡単に読める」。 赤松氏が「ソースを読んでいる人がほとんどいない」と感じる理由はもう1つある。それは,誰もがよく使うソフトでさえバグが大量にある,ということだ。少しでもソースをのぞけば,誰にでもすぐに見つけられるほど簡単なバグなのに,ネットにも情報が上がらず放置されているという。例えば,赤松氏が見つけたバグの具体例を一つだけお見せしよう。 まあ、寝言は寝てから言ってくれといった感じだが、カーネル読めるぐらいで生活は楽にならんっちゅーの。 だいたい、アンタprocfsとネットワークしか読んでな
更新履歴 2012-08-28: URL 公開 2012-08-29: futex、hrtimer、MySQL の発生条件、NTP SLEW モードに関する @odhrfm さんからの情報、キーワード更新、その他いろいろ細かい修正 2012-08-30: 参考リンク追加 2012-09-01: LKML まとめシートの thread#50 を追加 2012-09-03: SLES カーネルの更新情報、per-cpu についての記述、blockdiag によるブロック図を追加 2012-09-11: LKML まとめシートの thread#52, #53 を追加 2012-09-12: LKML まとめシートの thread#54 〜 #58 を追加 はじめに 日本時間 2012 年 7 月 1 日 9:00 にうるう秒が挿入されましたが、その際 Linux カーネルに起因する不具合により、
さて、Ubuntuの基本的な使い方に慣れたので、さっそく環境の構築に入る。まず、GNU/Linuxに移行した最初の目的である、clangを使うことにする。Ubuntuのレポジトリにはclangはあるが、残念ながら古すぎる。面白いことをするには、SVNから最新版を引っ張ってこなければならない。 clangをコンパイルするのは非常に簡単だ。とくに珍しいツールも必要ない。比較的新しいgccとGNU makeがあればいい。テストするには、もうすこしツールが必要だ。基本的にはClang - Getting Startedに従えばよい。ただし、SVNから取得すると、デフォルトのビルドがとんでもないことになるので、このままでは使いづらい。もちろん、普通に使うことは想定してないのだから、当然といえば当然だが、clangをハックするのでもなければ、やはり使いづらい。 まず、デフォルトでは、すべてのアーキテク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く