2017/06/16 10:29:55
shodai
IO waitと同じようにmemory waitが分かるようにしろってこと？
2017/06/16 10:33:55
atsuizo
メモリバウンドの場合、多重処理が近しいメモリ空間をアクセスしてセマフォ・ラッチ競合起こしてるだろうから、そこを分散しろって理解でOK？
2017/06/16 10:59:06
lesamoureuses
なるほどわからん
2017/06/16 11:00:45
NOV1975
この手の話だと昔AIXでメモリ使用率をファイルページが専有するからPIをみないと意味ないってのはあったな
2017/06/16 11:07:46
Ehren
“CPU Utilization is Wrong”
2017/06/16 11:17:45
tanakh
いや逆にストール率考慮せずにチューニングなんてしてる人おるん・・・？(´･_･`)
2017/06/16 11:31:17
yoku_0825
ほわー、面白い！
2017/06/16 11:37:33
the48
クロックも変動するしな
2017/06/16 11:39:08
SigmaG2
これは読んでおこう
2017/06/16 11:42:47
codehex
おお
2017/06/16 11:45:09
sonots
詳解システムパフォーマンスの著者の記事。CPUの章に載ってる内容。
2017/06/16 12:13:36
hobbling
仮想マシンチューニングのためにstall値に関しては調べまくったな。
2017/06/16 12:16:46
akiramaz
“あらゆるパフォーマンスツールは、%CPUと一緒にIPCを表示するべきです。あるいは%CPUを、命令の完了サイクルとストールのサイクル、例えば%INSと%STLの対比にブレークダウンするべきでしょう。”
2017/06/16 12:18:41
fire_0218
[] CPU使用率は間違っている | Yakst
2017/06/16 12:23:52
ryun_ryun
興味深い。
2017/06/16 12:53:14
ahomakotom
ストールしようがウェイトしようが、Softwareの品質評価の基準としてCPU使用率を用いるのは間違えじゃないでしょ。その時間が短縮可能であっても他のプロセスに譲らないことに変わりはないのだから。
2017/06/16 12:58:03
tmatsuu
おーあの記事の翻訳ありがとうございます。素晴らしい
2017/06/16 13:02:34
kenichiice
「Linux perfなどを使って読み出せるハードウェアカウンターであるPerformance Monitoring Counters (PMC)を使います」「top(1)に対しては、Linuxではtiptop(1)があり、プロセス毎のIPCを表示してくれます。」
2017/06/16 13:25:27
rindenlab
"サイクル毎の命令数(IPC)のような他の指標を使うことで、%CPUが実際何を意味しているかを知ることができます。IPCが1.0より小さければメモリーバウンド、IPCが1.0より大きければ命令バウンドである可能性が高い"
2017/06/16 13:40:17
masatomo-m
%CPUは処理のボトルネックがどこにありそうかを最初にざっくり区分けするときに見るものでしかないし、ボトルネック調査のアタリを付ける段階ではそれなりに有用かと思う
2017/06/16 13:48:24
iww
『しかし実はボトルネックはDRAMのバンクなのです。』
2017/06/16 13:53:19
shozzy
じっくり読み返そう
2017/06/16 13:53:21
tincast
だろうねー…　CPU使用率が高いのに涼しいままなパターンって、やっぱコレなんかしらね。また、メモリの応答が速ければハイパースレッディングの効率も上がったりするのかしら？
2017/06/16 13:53:49
junglejungle
ARMだとPMUEVENTで取れるんだが使い方がよくわからない
2017/06/16 13:54:49
dagama
普段topとか監視で見てるのはパフォーマンスじゃなくて異常が発生してないかだよね？チューニングの文脈でこんな荒い情報見ててもしょうがないし
2017/06/16 14:36:39
six13
むかしmpstatの読み方で大変シゴかれたので、この辺の認識は正しいことがわかって安心した。
2017/06/16 14:41:10
umisama
CPU使用率がパフォーマンス・チューニングのために必要なすべての要素を含んでいるわけではないのは理解できるけど、"間違っている"とは思わないかなあ。
2017/06/16 14:51:33
tmtms
勉強になる
2017/06/16 14:59:48
hyoshiok
360 低レベルのチューニングは測定してボトルネックを発見する。間違った道具を使うと間違う。
2017/06/16 15:02:16
ayakanishino8
なんとなくは知っている
2017/06/16 15:05:01
tsutsumi154
uptimeでたいてい見てるけど別にCPU負荷だなんて思ったこと無いし
2017/06/16 15:19:04
s-tomo
メモリ使用率の間違われっぷりと比べたらこれくらいどうということはないな。
2017/06/16 15:19:59
otihateten3510
あとで読む。Macの使用率はたまに400%とか出てウケる
2017/06/16 15:20:59
yorkfield
CPUを異常に食ってるプロセスをKillしたいとかの目的なら別に良いんじゃ無いかなあ。冒頭に書いて有るとおり、あくまでチューニングを想定してるんだろうけど。
2017/06/16 15:38:51
mehori
「CPUがアイドルでない時間」うんうんそれもまた（ry
2017/06/16 15:49:47
yamadar
"IPCが1.0より小さければメモリーバウンド、IPCが1.0より大きければ命令バウンドである可能性が高い"
2017/06/16 15:50:15
hiromo2
自分が正しいことを確認した。
2017/06/16 15:55:48
xact7
知ってた。
2017/06/16 16:02:46
kenzy_n
エンジン
2017/06/16 16:03:32
joker1007
勉強になる。
2017/06/16 16:05:06
masfj
そうですね。
2017/06/16 16:05:07
deep_one
まぁ待ち時間もユーザーにとっては使用率かな…でも別になってないと開発側はチューニングしづらい。
2017/06/16 16:05:15
Error401
コメ欄の、わかってた人の「俺そんなの知ってた」感がすごい
2017/06/16 16:11:29
mEGGrim
“Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘”
2017/06/16 16:20:23
takc923
頑張って英語で読んだ記事が翻訳されると損した気分になる
2017/06/16 16:24:47
xr0038
メモ的/『詳解 システム・パフォーマンス』 http://amzn.to/2swac9s に書かれているそうなのでチェックしておきたい
2017/06/16 16:26:03
reoring
なるほどー
2017/06/16 16:38:01
topiyama
せやな。これをもとにした消費電力計算もやめて欲しい
2017/06/16 16:49:01
yutam7
うーん
2017/06/16 17:01:45
zakusun
io待ちでは主にディスクしか気にしていなかったな。何らかの資源を確保できずに命令実行待ちで、実質的にcpuが空いているのに仕事が出来ていないことはロードアベレージで見ていた。古いな、考えが。
2017/06/16 17:04:58
xevra
別に間違ってないが、盲信して満足する事無いように内容をよく知っておけって話。社畜の言う「忙しい」も同様で中身を見たらどうでもいい事ばかりやっているからちゃんと中見ようよと言う話
2017/06/16 17:24:40
lyiase
ストール率(I/O待ち)、これ以外と厄介なんだよね…。現実、B/F比が高いマシンに変更可能ならいいんだけど、特に最近多いマルチコアやGPUではかなり小さいので計算量が小さくデータがでかい時は大変。
2017/06/16 17:29:27
Andrion
翻訳あざーっす！
2017/06/16 17:31:40
sorakazetan
専門用語ばかりでわからなかった(;^_^Aさすがに難しい
2017/06/16 17:38:20
s_shibano
CPUの話
2017/06/16 17:44:40
mukaken
“非常に誤解を招く指標になりつつあります。最近の負荷の多くを占める、メインメモリを待っているサイクルを含んだ値になっているため”
2017/06/16 17:45:43
Nilfs
日本語訳出てたのか、もっかい見直すかな
2017/06/16 17:52:21
nezuku
ある程度プロセッサアーキテクチャの理解が前提のエントリかもしれない。処理が終わるまでの時間と、CPUパイプラインがストールせずかつどれぐらい埋まっているか、の違いな感じかな
2017/06/16 18:12:15
t-murachi
humm...
2017/06/16 18:25:27
n314
プログラムでループしすぎて遅いとか変なSQLで遅いとか言ってるレベルでは関係ないよね…。
2017/06/16 18:30:55
gkom
社会
2017/06/16 18:31:22
kei_1010
CPUやメモリやストレージやネットワーク上をデータがどのぐらいの速度差で流れるのか可視化しつつ、プログラムやハードウェアの構成を見直してパフォーマンスチューニングするパズルゲーム、誰か作って。
2017/06/16 18:46:04
chinshufu
素人VPSユーザーには有り難い記事
2017/06/16 18:51:02
rAdio
CPU使用率は確かに「指標」というより「目安」って感じだし、よく理解もしてなかったので、「高負荷の時には上昇してることもある」という結果としての値としてしか活用できてない。
2017/06/16 18:52:21
ata00000
あるプロセスのボトルネックを調べるのにCPU使用率を使うのは不適切という話で、他の用途でまで否定されるものなのかなー。例えばサーバをスケールアウトするかの判断には使えそうだと思うけど…
2017/06/16 18:56:01
inumax21
(´・ω・｀)
2017/06/16 18:56:36
uzuki-first
知らなかった
2017/06/16 19:00:26
kitadon
頭の片隅においておく。
2017/06/16 19:02:38
enicalpha
ハードよりのことはホントいつになっても身につくことが難しいとおもう。
2017/06/16 19:05:55
kabacsharp
え？topって、I/O待ちを考慮してなかったの？
2017/06/16 19:10:18
alastor914
ﾌ-('.'o)-ﾝ
2017/06/16 19:31:26
tengo1985
原文でかなりブクマ付いてるけど、こっちにもこれだけ付くということは読んでなかった人がいっぱいなのだろう。この人のドキュメントはだいたい読んでおいたほうがいい。ツールの分類図が素敵。
2017/06/16 19:33:58
dirtjapan
まずはCPU使用率みながらチューニングして、その先はストールとかみながらチューニング、って基本どおりだな。
2017/06/16 19:38:28
tsz
メモリもIOなんだよね〜
2017/06/16 19:41:19
ewq
すごく分かりやすく書いてくれてるんだろうけど何言ってるか全然わからん。
2017/06/16 19:42:12
joyan0930
Brendan Greggの解説。インフラエンジニアなら、Linux Pefomance toolは壁紙にすべき。http://www.brendangregg.com/Perf/linux_perf_tools_full.png
2017/06/16 19:42:46
kitaj
なるほど
2017/06/16 19:48:38
IGA-OS
指標の一つだけど、チューニングには使いづらい指標なのか。
2017/06/16 20:16:25
junmk2
タスクマネージャーで見るとCPUにもメモリにも余裕があるのに、頻繁に固まるブラウザの解決策的な事が書いてあるかと思ったらよくわからなかった。
2017/06/16 20:22:16
chintaro3
最初 core-iが出てきた時に早く感じたのはこの辺のF/Wレベルでの改善が大きかったんだと思う。DDR4で良くなるかと思ったけど、まだそうでもないね。
2017/06/16 20:26:15
hogetahogeko
メモリを待つこともいまだに「CPU使用率」と呼ぶ
2017/06/16 20:40:42
kniphofia
cpuの使用率をもう少し細かく表示しましょうってだけなのにこのブコメ
2017/06/16 21:00:17
dekasasaki
あとでよまないとだめなきなする。
2017/06/16 21:15:21
macj_jp
ソフトウェアの品質判断にはそのまま使えるというブクマになるほどと思う一方、サーバーの増設判断にはこの記事通りにボトルネックを探した方がいいように思う。
2017/06/16 21:15:44
ya--mada
ワークロードはシステムごとに異なるから、、全体を見て、何を重視するかはじっくり見定めて監視設定してるねぇ。Voiceやってたときはcpu 使用率とコンテクストスイッチとNIC 割り込みを指標にリソース調整だった。
2017/06/16 21:24:29
a96neko
CPUですら仕事で手を抜いて適度に休憩してるのに、お前らときたら
2017/06/16 22:15:40
nisisinjuku
想定していない状況になってきたなら新しい指標を使うようにOSなのか評価する側が変わっていくといいよな。
2017/06/16 22:37:39
iR3
ふむふむ
2017/06/16 22:42:40
rryu
CPU使用率とロードアベレージはシステム全体の「暇じゃない度」だから、確かに個々のプログラムがCPUを使い切っているかを計るのには向いてはいない。
2017/06/16 22:53:28
dowhile
ほとんどの演算はメモリバウンドなんだよなあ
2017/06/16 23:21:12
denilava
この記事が１０００超えブクマってはてぶ民の偏りなのか高レベなのか。IPC＞1は、おおよそパイプラインの命令が維持されてる＝命令の最適化がいる。IPC<1は、パイプラインがストールしてる＝命令が実行されてないと。
2017/06/16 23:53:05
mamezou_plus2
CPUの発展にわくわくしてた人間なら解ってる話で、誰向けに書いたんだろう？
2017/06/17 00:04:08
takayaman
メモリのI/Oをまつストールも含んでいる。
2017/06/17 01:19:06
blueribbon
「サイクル毎の命令数(IPC)のような他の指標を使うことで、%CPUが実際何を意味しているかを知ることができます。IPCが1.0より小さければメモリーバウンド、IPCが1.0より大きければ命令バウンドである可能性が高い…」
2017/06/17 02:07:42
tettekete37564
まあ確かにCPU使用率ってなんだよと思っていたけど。CPUはレジスタに乗ってる値しか計算できないのでメモリからレジスタにコピーする命令がブロックしてても使用率は上がるって話。ですよねって感じではある
2017/06/17 02:28:45
shotakame
知らなかった
2017/06/17 02:39:39
tkmoteki
面白い。スピンロックなんて、何だか悲しいメモリロック久しぶりに聞いた。今はどんな事情なのか。 CPU使用率は間違っている - Yakst via @nuzzel
2017/06/17 06:00:36
kmrlkmrl123
http://www.the-ift.com/system/files/km-Live-NASCAR-Sprint-Cup-Qualifying-Live-Stream-Race-Watch-Online-Web-TV-Cast-2017.pdf
2017/06/17 07:15:12
ragey
mac だとどうなるのか？
2017/06/17 08:16:27
REV
内部には重要、外部からは「それもまた使用率」
2017/06/17 08:49:48
lenore
%cpuはstalledを含むのでipc など他の指標と共に計測する。"IPCが1.0より小さければメモリーバウンド、IPCが1.0より大きければ命令バウンドである可能性が高い"
2017/06/17 08:53:35
Iridium
え、でもメモリにアクセスしないコーティングって可能なの？どうやって？具体的に方法を知りたい
2017/06/17 09:45:31
zou3dazou
あとで
2017/06/17 12:21:31
mogmognya
CPU使用率はボトルネックがCPUではなくてメモリの場合が多いですよということだけ理解したが、あとは「よし！わからん！」って感じである。はてなは詳しい人が多いのだなあ。
2017/06/17 14:51:45
pmint
アプリレベルで考慮すると「オブジェクトを作るな、破棄もするな」となって今日の分かりやすいコーディングを根本から否定することになるのかな。
2017/06/18 14:03:41
taro-r
なるほど，勉強になった。
2017/06/18 19:03:55
kairusyu
ストールされてるときって演算発生しないからCPU温度上がらない、でいいの？（わかってない
2017/06/19 14:45:05
moccos_info
ソフトウェア自分で書くより使うだけ人の方が圧倒的に多いだろうから、どちらかというと正しい、でいいんじゃないかなあ