tcコマンドでNetworkの帯域と遅延を制御してみてみた - Qiita
■ 目的 tcコマンド(Traffic Control)は、Networkの遅延(Latency)と帯域(Throughput)を制御することができます。 コンピューターの距離により遅延、帯域が変わり、データ転送などの時間がかわることがあります。コンピューターを遠隔に離した場合、既存の処理に影響が出るかtcコマンドを使用して事前に検証することができます。 ということで、tcコマンドで、遅延、帯域が制御できるか確認してみてみます。 ■ 構成 Oracle Cloud上にComputeインスタンスを２台設置して、その間のNetworkパフォーマンスをTCコマンドで制御してみてみます ■ 現環境確認 Client --> Server へのレイテンシ、スループット、TPSを確認 ● 遅延(RTT)確認 pingを実行してRTT確認 今回は、平均0.166msであることを確認 [opc@clien
perfを用いたシステムのボトルネック解析方法
背景システムの処理速度を改善するために、ボトルネック解析を行う必要があった。 ボトルネック解析の方法と、プロファイリングに使用したperfの使用方法に関して調査を行った。 記事の目的perfを使用し、ボトルネック解析を行う ここでは、perfの導入方法及び使用方法について記載する。 perfとはperf(Performance analysis tools for Linux)とはLinuxカーネル2.6.31以降で使用可能なLinuxの性能解析ツールである。 実行されているプロセス毎のCPU使用率やプロセス内で呼ばれている関数の割合などを調査できる。 利点gprofのように、プログラム作成時に専用のライブラリを入れたり、コンパイル時にオプションをつける必要がない フレームグラフにして、ビジュアライズできる 導入方法(Ubuntu編)Ubuntu16.04へperfを導入する手順について記
Java Mixed-Mode Flame Graphs で Java の CPU ネックをフルスタックで分析する - ablog
Brendan Gregg (NETFLIX の Senior Performance Architect) 作の Java Mixed-Mode Flame Graphs を使うと Java のプロセスが CPU ネックのケースで、Java アプリケーションコード、JVM(HotSpot VM)、Linux Kernel のどのレイヤーのどの関数がボトルネックになっているかを簡単に特定することができます。 以下は GitHub - martint/jittest: Demonstrate JIT compiler issue in java 7 のワークロードを実行して Flame Graphs で可視化したものです。 以下は Java One 2015 での Brendan Gregg のスライドです(YouTube もあります)。 JavaOne 2015 Java Mixed-Mo
perf, ftraceのしくみ - 睡分不足
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
perf使ってみた - Qiita
man perf-サブコマンドでmanが見れる コマンド使ってみる perf top 関数単位でcpu使用率を閲覧 共有ライブラリのシンボルは16進数で読めない。kernel-debuginfoなどインストールしていないがカーネルシンボルが読める。共有ライブラリもシンボルが見れるものがある、なぜでしょうか＞＜？？？？？ Samples: 72K of event 'cpu-clock', Event count (approx.): 2471353254 Overhead Shared Object Symbol 3.76% [kernel] [k] find_vma 3.56% [kernel] [k] __d_lookup 2.44% [kernel] [k] avc_has_perm_noaudit 2.42% [kernel] [k] __link_path_walk 2.39%
CPU使用率は間違っている | Yakst
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
