bpftraceを使ってバイナリの謎の性能劣化を突き止めろ - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズ社内ではC++で開発している製品があります。 未知のバッファオーバーランなどの脆弱性への対策として、重要なコンポーネントについてはプロダクション環境で利用しているバイナリでも AddressSanitizer を有効にしてビルドしています。 その製品で利用しているコンパイラをgcc5.3.0からgcc7.5.0に更新したところ性能劣化が発生しました。 製品コードとは別の部分が原因のため、根本原因の追跡が難しそうです。perf,bpftraceを使って性能劣化を追いかけてみましょう。 本記事で利用しているAddressSanitizer, bpftrace, perfコマンドはネット上に良質な記事がありますので、使い方などの解説は今回は省略させていただきます。 gcc7.5.0において、性能劣化が発生する再現コードとして次のようなものを用意しました。 #include <strin
はじめにシステムの状態を的確に捉え、運用に必要なインサイトを継続的に得るための特性は「オブザーバビリティ」と呼ばれます。オブザーバビリティを実現することで、パフォーマンスのモニタリングやトラブルシューティングを効果的に行い、システムの信頼性を高めることができます。 この重要な特性を実現する上で、eBPFやbpftraceは強力なツールとなります。 本記事では、Goアプリケーションにおけるオブザーバビリティを実現するための一つの方法として、bpftraceを用いたトレースの手法を紹介します。 内容が多いため、目次を活用して段階的に読み進めることをお勧めします。 eBPFとbpftraceはじめに、eBPFとbpftraceについて簡単に説明します。 eBPFとはeBPF(Extended Berkeley Packet Filter)はLinuxカーネル内で動作する柔軟なプログラミングフレー
bpftrace 2020 - 睡分不足
(この記事はLinux Advent Calendar 2020 - Qiitaの2日目の記事です．前日はmasami256さんのTiny Core LinuxでLinuxのinitプロセスが実行されるあたりを調べるでした．) みなさんこんにちはこんばんは．bpftraceを使っていますか? (e)BPFといえば最近は専らCiliumなどネットワークが話題ですが，bpftraceはBPF*1を利用したトレーシングツールです．私は昨年からぼちぼち使い始めて，機能追加やバグ修正のパッチをいろいろと投げていた(130+)ら気づいたらコミッタになっていました．ということでbpftraceについては比較的よく知っていると思うので，今年にbpftraceに追加された主要な機能や変更点を紹介したいと思います． bpftrace知らないなぁという方はこちら(拙文です)を，bpftrace使ってないなぁとい
はじめに 去年のアドベントカレンダーでeBPFについていろいろ調べた． その時に，ネコの人に「SystemTapで昔ゲームを作ったことがあるから，BPFでも作れるはずだから作ってみたら」と． ちょうどLT会のネタに困っていたこともあり，作るかとなったので，bpftraceで動作する2048を作りました．(SystenTapで動作する2048もあります) 動作環境 bpftraceの環境構築は公式に書いてあるinstallの手順に従って導入してください． Linux5.3以上である事が必須となっています． Linux5.2以前では，命令数制限でverifierでカーネルにロードされずエラーとなってしまいます． また，プログラム内でwhileを使用しており，whileもLinux5.3以上でないとサポートされてないため(確かこのバージョンで入ったはず...)動作しません． このあたりの環境構築
bpftraceでテトリス - Qiita
みなさんこんにちは．突然ですがbpftraceってご存知でしょうか? 名前から明らかなようにbpfを利用したトレーシングツールです．bpftraceの設計は以前から存在するDTraceやSystemTapに影響を受けています．それらのツールに馴染みのある人にとってはむしろ，bpftraceはDTraceやSystemTapのBPF版と言った方が（非常に雑ですが）分かりやすいかもしれません． 一般にBPFを利用してトレーシンングを実施する場合は，1) BPFプログラム本体 と 2) トレーシング結果を表示するためのユーザランドのプログラム を書く必要がありますが，bpftraceでは独自のスクリプト言語により，それらを特に意識せずにトレーシング処理が記述できます．例えば，プロセス別にシステムコール発行数を集計したい場合は以下のようにしてできます．便利ですね． % bpftrace -e 't
インフラのいわほり（egmc）です。 eBPFを利用したプロダクトとしてはCiliumなどがcloud nativeな文脈として盛り上がっていますが、一方でBCC Toolsやbpftaceは、システム内部のかゆいところに手が届くソリューションとして身近な課題解決にカジュアルに役立つツールとして提供されています。 これらのツールは実際に便利ではあるものの現実世界での事例をそれほど見かけないというのもあり、「こんな感じで役に立った」という事例をカジュアルに紹介していくのもコミュニティにとって有用ではないか、ということで今回はOSのバージョンアップに関連して発生した問題の調査にbpftraceが役立ったというお話をご紹介したいと思います。 環境 Ubuntu 20.04.6 LTS bpftrace v0.9.4 発生した事象 GREEのクラウド環境で利用しているシステムのアラートの配送を行う
Accurate, low-overhead per process bandwidth monitoring on Linux in 40 lines of bpftrace
Existing tools to measure bandwidth usage on Linux Measuring bandwidth with bpftrace The full program Preamble Installing kprobes Measuring incoming data Measuring outgoing data Cleanup Adding live updates Future work Further reading Existing tools to measure bandwidth usage on Linux Searching for “per process network usage linux” is disappointing. Most of the recommended tools – like iftop, nload
Linuxにおける利用が急速に増えている「Berkeley Packet Filter（BPF）」について、基礎から応用まで幅広く紹介する連載「Berkeley Packet Filter（BPF）入門」。前回はBPFによるトレーシングについて、おおまかな仕組みや概要を説明しました。今回は、BPFによる代表的なトレーシングツール「bpftrace」について、具体的にどのようなことができるのかを紹介します。また、bpftraceの注意点や分かりにくい点についてもまとめます。 bpftraceとは bpftraceはBPFを利用したトレーシングツールの一つです。代表的なBPFのライブラリである「BCC（BPF Compiler Collection）」と同じく、現在は「iovisor」が管理しています。BCCと比較すると、bpftraceはトレース処理に特化し、より簡単に利用できるようになって
Benefits for LWN subscribersThe primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today! There are times when developers and system administrators need to diagnose problems in running code. The program to be examined can be a user-space proces
Let's build a simple system calls monitoring dashboard using bpftrace and streamlit
% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 49.67 0.000301 301 1 execve 14.69 0.000089 11 8 mmap 6.44 0.000039 13 3 openat 4.46 0.000027 9 3 mprotect 4.46 0.000027 6 4 newfstatat 3.47 0.000021 5 4 pread64 3.14 0.000019 19 1 munmap 2.81 0.000017 8 2 close 2.64 0.000016 5 3 brk 2.15 0.000013 6 2 read 2.15 0.000013 13 1 1 access 1
このブログは、昨日の分です。だめですかね... カーネルトレーシングシリーズです。今日は、Nginxを、追ってみます。 まず、 uprobe が見えるnginxバイナリを用意する 大抵の場合、パッケージのnginxバイナリはシンボルがstripされていて、uprobeが見えない。 nginx-build などで自分でビルドする。 github.com トレーシングの都合上、 --with-debug でビルドするといいらしい（ ngx_request_t * などがトレーサから見えるようになる）。 $ nginx-build -d src/nginx-build -v 1.15.12 \ --with-debug uprobeは以下の通り確認できる。 $ sudo bpftrace -l 'uprobe:/usr/local/nginx/sbin/nginx' | head uprobe:
概要 Dockerはよくdocker runとかdocker execのコマンドで Black Box みたいに使われて完結ですが、その中身をもっと詳しく調査してみたい。そのための有力ツールの一つはbpftraceです。 作業環境 Ubuntu 20.04 Dockerの構成 Dockerはおよそ以下のパーツに構成されている docker-cli：docker runとdocker execなどのコマンドを提供するDockerのクライアント側 dockcerd：Docker のサーバー側、Docker Engine のデーモンプロセス、docker-cliなどクライアントからのリクエストを処理する場所 containerd：Container Runtime の一つ、いろんな Container の管理を機能しているデーモンプログラム runc：いろんなOS機能を利用して、単独のConta
bpftrace Cheat Sheet
This page is a bpftrace cheat sheet that you can print out for reference, and is from the bpftrace programming section of my eBPF Tools page. There is another bpftrace cheat sheet as Appendix B in BPF Performance Tools: Linux System and Application Observability. Syntax probe[,probe,...] /filter/ { action } The probe specifies what events to instrument, the filter is optional and can filter down t
「カーネル謎機能を活用したパフォーマンスとの戦い」と題してPepabo Tech Fridayで発表していた。ペパボテックフライデーとは下記です。 tech.pepabo.com しかし、割と生々しい社内のプロジェクトの計測値を出しているので、資料は公開しません...（入社したらあるいは... ;) ） が、一般的な内容にしてどこかで話そうという気持ちはある（言ってしまった...）。 話した内容はわりと一般的ではあって、まずは *BSD/Solarisでの DTrace や perf と bpftrace を比較して、perfのようにさまざまなカーネルの情報を取れる上に、dtraceのようにカーネルランドで集計やフィルタリングが完結して低コストなbpftraceは便利と紹介した （※認識が違ったら突っ込んでください...）。 ちょうど詳解システムパフォーマンスを読んでいて、読んでいるととに
Tracing mysqlnd.so and mysqld (with perf and bpftrace) | GREE Engineering
こんにちわ。せじまです。 現代人はgdbよりbpftraceを好むという電波を受信したので、Debugging mysqlnd.so ～mysql_native_passwordが廃止される未来に備えて～のようなことをbpftraceなどで確認したいならどうしたら良いか、試してみます。 はじめに 身も蓋もないですが、こういった用途ではgdbの方が融通がきくと個人的には思いました。uprobeだと、ユーザ空間のローカル変数で、参照できるものとできないものがまちまちだったので、今回は「libcryptoの関数に渡してる引数を見ればいいだろう」という発想に至りました。そこまで至るのにも時間を要するので、こういう選択肢もあるという感覚で読んでいただければと思います。 でははじめます。 perf probe や bpftrace を試す環境など WSL2だと sudo ls /sys/kernel/
動機と概要 eBPFプログラムはLinuxカーネルのようなC言語で書かれた関数のトレースを得意としています。しかし、C++アプリケーション特有のトレース技法があまり公開されていないため、今回記事を書きました。以下ではeBPFを使ったトレーシングを提供するツールであるbpftraceを使います。 サーバーの移設を検討するためにはどのウェブサーバーからどの程度のアクセスがあるのか調べる必要があります。グリーではC++で書かれたflareというmemcached互換のサーバーが動いており、flareへのアクセス解析にbpftraceを利用しました。ウェブサーバーは一回の接続で何度もflareにリクエストを送るため、接続数ベースの計測では実際の利用頻度が分かりません。今回bpftraceを用いてどのサーバーからどんな種類のアクセスを何回リクエストしているか調査しました。 本記事ではトレースにおける
Linux Kernel: rtnl_mutex を長時間 ロックして刺さった状態を観察する (2) with bpftrace - hibomaの日記
前回の続き hiboma.hatenadiary.jp rtnl_mutex でロックを獲得してクリティカルセクションを実行中のタスクを何らかの方法でトレースしたり、時間を計測したいと思って、あれこれ調べたり、試行錯誤していた 最終的に bpftrace でがちゃがちゃと試すまでを記していく 案 A: CONFIG_LOCK_STAT Kernel の設定で CONFIG_LOCK_STAT を有効にしていると各種ロックの統計を取ることができるようです sites.google.com CONFIG_LOCK_STAT は CONFIG_DEBUG_KERNEL に依存した設定なので、production 環境なワークロード化で導入するのはなかなか難しそうかな? CONFIG_LOCK_STAT の設定を Ubuntu (Vagrant) で確認したけど有効でないな (Ubuntu はデバ
# シグナルの送信を検知する $ bpftrace -e 't:syscalls:sys_enter_kill {time("%H:%M:%s "); printf("%s (PID %d) send a SIG %d to `PID %d\n", comm, pid, args->sig, args->pid);}' # pid別にシステムコールの回数を調べる $ bpftrace -e 'tracepoint:raw_syscalls:sys_enter {@[pid, comm] = count();}' # プロセス別のページフォルトの回数を調べる $ bpftrace -e 'tracepoint:exceptions:page_fault_user {@[ustack, comm] = count();}' # 引数付きで新プロセスをトレースする $ bpftrace -e '
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bpftraceによるGoアプリケーションのトレース｜hayajo
bpftraceで2048作ってみた - バニキPの気ままに
bpftraceで深夜にプロセスをkillした犯人を特定する | GREE Engineering
BPFによるトレーシングが簡単にできる「bpftrace」の使い方
Comparing SystemTap and bpftrace [LWN.net]
Nginxをbpftraceで追いかける - ローファイ日記
bpftraceで Docker の仕組み調べてみる - Qiita
社内生活発表会でeBPF(bpftrace)の話をした - ローファイ日記
bpftraceでC++のアプリケーションをトレース | GREE Engineering
いつか使えそうなbpftrace1行プログラミング - 地方エンジニアの学習日記