Linuxパフォーマンス

 (brendangregg.com)
3 ポイント 投稿者 GN⁺ 2023-10-15 | 1件のコメント | WhatsAppで共有
  • Brendan Greggの Linux Performance ページは、Linux の性能調査を始める際に必要な可観測性・分析・ベンチマーク・チューニング資料をひとまとめにしたリンクハブである
  • 中核となるツールの流れは perf, eBPF, bcc, bpftrace, Flame Graphs へと続いており、コマンド例からトレースツール、可視化まで直接たどれる
  • 文書資料は Netflix の 2015 年の性能分析記事、EC2 チューニング、Linux load averages、frame pointers、gdb の例、そして 2 冊の性能本まで広がっている
  • 講演一覧は 40 分概要、90 分ツールチュートリアル、コンテナ性能分析、SRE チェックリストのように、状況別の学習ルートを提供する
  • 各ツールマップは画像右下の年で新しさを確認する必要があり、統合ダイアグラムは他の個別ダイアグラムほど完全ではない

性能資料ハブとツールマップ

  • このページは Brendan Gregg が作成した Linux performance 資料を集めたリンクハブである
  • 右側のツールマップ画像はスライドデッキに合わせて大きなフォントで作られており、印刷してオフィスの壁に貼ってもよい形式である
  • ツールマップは Linux の性能作業を次の領域に分けて示している
  • 各画像がどの程度新しいかは、右下の年を確認する必要がある
  • 可観測性、静的性能チューニング、perf-tools/bcc をまとめた高解像度ダイアグラムも別途提供されている
    • png
    • svg
    • この統合ダイアグラムは、他の個別ダイアグラムほど完全ではない

すぐにたどれる主要ツール

  • perf: perf one-liners、例、可視化資料
  • eBPF tools: BPF/bcc トレースツールと例
  • perf-tools: Ftrace ベースの perf ツール集
  • bcc: BPF/bcc 性能ツール集
  • bpftrace: BPF/bpftrace 性能ツール集
  • Flame Graphs: perf や他のプロファイラを使った Flame Graph の使い方

文書と学習資料

eBPF、ftrace、perf の発展的な記事

状況別おすすめ講演

  • Linux Systems Performance, USENIX LISA 2019

    • 40分でLinuxシステム性能を、オブザーバビリティ、方法論、ベンチマーク、プロファイリング、トレーシング、チューニングの6つの側面から要約
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • 2018年時点のLinux performanceの最近の変化と機能を、20分のキーノートで要約
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • 90分のチュートリアルで、性能オブザーバビリティ、ベンチマーク、チューニング、静的性能チューニング、トレースツールと方法論、ライブデモを扱う
    • youtube playlist, slideshare, PDF

  • How Netflix Tunes EC2 Instances for Performance, AWS re:Invent 2017

    • 性能オブザーバビリティよりも チューニング に焦点を当て、Netflixの背景、AWS EC2インスタンスタイプと機能、Linux kernel tunables、オブザーバビリティを扱う
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • ボトルネックがホストとコンテナのどこにあるのかを見つけ、コンテナアプリをプロファイリングし、さらにカーネルの深部まで入っていく方法を扱う
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Linuxシステムツール、指標、統計、可視化、測定オーバーヘッド、ベンチマークでよく起きる問題と、「What You Can Do」という助言をあわせて扱う
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • CPUプロファイリングとFlame Graphsの動作に焦点を当て、perf_eventsの特性と、Java、Node.js、VM、コンテナのプロファイリング時におけるstack tracesとsymbolsの問題を含む
    • youtube, slideshare

  • Give me 15 minutes and I'll change your view of Linux tracing, LISA 2016

  • Performance analysis superpowers with Linux eBPF, O’Reilly Velocity 2017

    • Linux 4.xシリーズに追加されたenhanced BPF、つまりeBPFを、性能分析、オブザーバビリティ、デバッグに活用する内容を扱う
    • フロントエンドは、BPFインターフェースとツール群を提供するオープンソースプロジェクト bcc
    • youtube, slideshare, PDF

  • Linux Performance Analysis: New Tools and Old Secrets, LISA 2014

    • ftraceとperf_eventsツール、そして主にftraceを使う perf-tools を扱う
    • ftraceはLinuxカーネルに何年も前から組み込まれていたが、ほとんど知られていなかったトレーサーとして紹介される
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • 後半でLinux incident performance response向けのチェックリストを含み、緊急のLinux性能分析にも役立つ可能性がある
    • youtube, usenix, slideshare, PDF

外部のおすすめ資料

関連記事

1件のコメント

 
GN⁺ 2023-10-15
Hacker Newsの意見

  • リアルタイムアプリを動かしている Debian/Ubuntu VPS で tuned を使っているが、かなりうまく動いている
    カーネルパラメータ、つまり sysctl 設定やカーネルのチューナブルを直接変更するより簡単
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • SAPワークロードにも Tuned を使っていて、とても気に入っている

  • Brendan Gregg が今 Intel にいるとは知らなかった
    https://en.wikipedia.org/wiki/Brendan_Gregg
    バイラル動画 Shouting in the Data Center の主役でもある
    https://www.youtube.com/watch?v=tDacjrSCeq4
    本当に天才

  • 元記事で扱っているほぼすべての内容は、レイテンシではなく、ネットワーク、ディスク、その他I/O、CPUのスループット/帯域幅に関するものだという点は指摘しておく価値がある
    多くの人にとって性能とはスループットを意味するので理解はできる。ただし、スループットよりレイテンシの方がはるかに重要な場合もあり、Linuxでレイテンシをチューニングするには別のツール群が必要になる

    • かなり妥当な指摘だ。スループットを増やすよりレイテンシを下げる方がはるかに難しいこともあり[1]、レイテンシを気にすることが重要な場合は多い
      人々が最適化できるもう一つの軸はワット当たり性能だが、ここでは長くは触れない
      スループット最適化がそのままレイテンシ最適化になる場合もある。たとえば、より多くのプロセスを1台のマシンに載せられれば、プロセスと通信相手の平均距離が縮まり、平均レイテンシも下がる
      レイテンシを最適化する際に非常に当然のことは、スループットがボトルネックにならない程度まで十分に増やすことだ
      レイテンシを積極的に最適化するなら、Linuxチューニング自体は多くない印象がある。間違っているかもしれないが、おおむねコア固定、tickless 実行、ユーザー空間ネットワーキング、そしてページサイズ・SMT・省電力設定・ハードウェア選択といったハードウェア側の調整が中心のようだ
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • bandwidthよりは throughput と呼ぶ方が適切に見える。意味は似ているが、スループットとレイテンシの対比は昔から議論されてきた
      ときには両方を改善できるが、通常はトレードオフだ
    • レイテンシチューニングに関連しておすすめできるツールや資料が気になる
    • システムのリアルタイム性のためにレイテンシを下げることが目的なら、標準的なLinuxディストリビューションでいくらさまざまなノブをいじっても、満足できるシステムにはならない可能性が高い

  • 待つのも良い戦略だ
    Linux 6.5 から、スケジューラは1つのSMT「コア」が忙しいときに別の「コア」へ何かを配置するのが最善とは限らないことを理解する。実際にはコンテキストスイッチのコストが非常に低い単一コアに近いからだ
    これにより、非常に並列的な作業が体感できるほどきびきびするようになり、CPU使用率グラフにも表れる
    キャッシュコヒーレンシとNUMAの問題により、結果は異なる場合がある

    • 以前のカーネルでも SMT無効化 だけでよりきびきびした効果を得られ、一部のサイドチャネル攻撃も防げて、電力効率も上がる

  • 関連記事:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - 2017年1月、コメント64件
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - 2014年8月、コメント22件

  • あるチューナブルパラメータを変更したがりながら、その変更がなぜ望む効果を生むのか、そもそもなぜその値に設定されているのかを説明できないなら、本番環境では変更させない
    「チェスタトンのチューナブルパラメータ」と呼べそうだ

    • 仮説上の理由を説明できるとしても、どうせ本番環境の外でベンチマークすればよいのでは？

  • BrendanのeBPFでの仕事を考えると、この資料はさまざまな性能状況で、より簡単に監視し評価する方法として受け取れる
    調整やチューニングにはトレードオフがあり、たいてい一方を最適化するともう一方が犠牲になることが多い
    付け加えると、btop は glances の代替となるオールインワンのTUIシステム性能・負荷ビューアとして非常に便利だった。開発者たちがこれをどれほど活用しているのか、より良いTUI監視ツールを作る動機があるのかも気になる
    サーバーに入ったら、まず tmux を起動して、1つのウィンドウを btop に割り当てる

  • 私にとってLinux性能「チューニング」とは、Spectre/Meltdown緩和策の無効化と同じだ
    この場合、計算ノードはインターネットアクセスのないVPC内で動いているので、リスクはかなり低そうに見える

    • どのCPUを使うかによる。Zen 4 では緩和策の無効化はサポートされておらず、バグやクラッシュを引き起こした
      その特定のクラッシュは修正されたようだが、それでもおすすめしない。AMDとIntelの最新CPUは、少なくとも基本的な緩和策を有効にした状態で実行されるよう設計されている

  • ブックマークしておいた。近いうちに取り組んでいる作業で役に立ちそう
    まだスライドを全部読んだわけではないが、カーネルのビルドオプションで意味のある性能向上を見たことがあるのか気になる
    以前 Gentoo を使ってビルドフラグをいじっていた頃は、カーネルの Makefile を変更して -O3 を使い、-march=native のパッチを適用したりしていた。振り返ると、Phoronix のベンチマークでは複数のワークロードでむしろ有害に見えるのだが、逆の事例を見たことがあるのか気になる

  • 良いサイトだ。Linux の性能を、チューニングにせよモニタリングにせよ要約しようとする傾向があって、思わず深呼吸したくなる
    このテーマは深く、観測ツールの種類も非常に多い。少なくとも uptime、dmesg、iostat は深く理解しておくべきだ。これらのツールは負荷、メモリ、CPU などシステムのさまざまな側面をざっと確認し、状態診断の最初の手がかりを与えてくれる。私が「ちょっと見てみよう」チェックリストと呼んでいるものの100ページ中の1ページ目だ
    性能分析の方法論では、システムの挙動とワークロード特性を全体的に評価するために、慎重なベンチマークを推奨している。変更前後のシナリオを比較し、まず小さな変更を加えてから、利益があると判断されたものを段階的に組み合わせるべきだ。実験室と本番環境は決して同じようには動かない
    ここからが厄介になる。perf のようなツールによる CPU プロファイリング と flame graph のような可視化は、CPU 活動を狙い撃ちで分析できるようにし、ハードウェアイベント追跡まで加えれば計算効率を最適化できる。「アプリの問題です、開発チームの最新リリース前は問題ありませんでした」以上のことを知っておく必要がある
    管理者として開発者と話すときは、Linux では ftrace や BPF のようなツールが必要になる。カーネル関数の実行やシステムコールを詳細に追跡できるため、問題解決と性能最適化に重要だ。逆に開発者なら、管理者の勘を検証しなければならないこともある。言葉どおり、信頼しつつ検証せよ、だ
    自分のコードなら BPF を知っておくべきだ。BPF は効率的なカーネル内部トレーシングを可能にするだけでなく、bcc や bpftrace を通じた高度なカスタムプロファイリングツールの開発も後押しし、システム性能をより深く見られるようにしてくれる
    最後に、これは本当に難しい。チューニングとは、CPU とメモリからネットワーク設定まで、多数のシステム構成要素やカーネルパラメータを調整し、さまざまなワークロードで性能と信頼性を最適化する作業だ。あるいはネットワークのせいにすればいい
    実際には、変更管理に対する良い姿勢が必要だ。コードやカーネルパラメータを追いかける作業は誰にとっても手に余ることがあり、時間に追われている状況では、プレッシャーによって人的ミスの可能性がさらに高まる