Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オブザーバビリティで理解するコンピュータサイエンス
Search
Qryuu
July 18, 2021
Science
1
1.5k
オブザーバビリティで理解するコンピュータサイエンス
JTF2021 D2 登壇資料
- CPU使用率の読み方 コアごと使用率の意味と計算機概論
- N+1問題 見つけ方とその発生原因
Qryuu
July 18, 2021
Tweet
Share
More Decks by Qryuu
See All by Qryuu
監視論Ⅳ ~監視からオブザーバビリティーへの招待~
qryuu
0
410
人体モニタリングによる運動療法継続
qryuu
0
160
監視とは何か ~監視エンジニアのスキルと成長~
qryuu
8
8.6k
監視論 ~SREと次世代MSP~
qryuu
10
5k
Other Decks in Science
See All in Science
ガウス過程回帰とベイズ最適化
nearme_tech
PRO
1
430
03_草原和博_広島大学大学院人間社会科学研究科教授_デジタル_シティズンシップシティで_新たな_学び__をつくる.pdf
sip3ristex
0
470
baseballrによるMLBデータの抽出と階層ベイズモデルによる打率の推定 / TokyoR118
dropout009
1
430
[第62回 CV勉強会@関東] Long-CLIP: Unlocking the Long-Text Capability of CLIP / kantoCV 62th ECCV 2024
lychee1223
1
940
Cross-Media Information Spaces and Architectures (CISA)
signer
PRO
3
31k
MCMCのR-hatは分散分析である
moricup
0
350
Explanatory material
yuki1986
0
310
Transport information Geometry: Current and Future II
lwc2017
0
150
機械学習 - 授業概要
trycycle
PRO
0
190
機械学習 - K近傍法 & 機械学習のお作法
trycycle
PRO
0
1.1k
統計学入門講座 第4回スライド
techmathproject
0
140
3次元点群を利用した植物の葉の自動セグメンテーションについて
kentaitakura
2
1.2k
Featured
See All Featured
The Language of Interfaces
destraynor
158
25k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Become a Pro
speakerdeck
PRO
28
5.4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
For a Future-Friendly Web
brad_frost
179
9.8k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Rails Girls Zürich Keynote
gr2m
94
14k
Site-Speed That Sticks
csswizardry
10
660
How GitHub (no longer) Works
holman
314
140k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Transcript
オブザーバビリティから理解する コンピュータサイエンス ~コンピュータサイエンスが職務境界の問題を見つける~ JTF2021
自己紹介 ▪ PN:九龍真乙 ▪ Twitter: @qryuu ▪ SlideShre: https://www.slideshare.net/qryuu ▪
GitHub: https://github.com/qryuu ▪ クックパッド: https://cookpad.com/kitchen/4142562 ▪ Youtube: https://www.youtube.com/channel/UCcPidyLCfGp49pmF4Zb761Q ▪ 専門:Zabbix, New Relic,テクニカルサポート, テクニカルトレーナー 2
セッションの目的 ▪ パフォーマンスDataをどのように読み解くのか ▪ その問題は何故発生するのか ▪ 問題は職務境界に存在する事が多いです、その問題を運用の視 点で見つけて見ましょう 3
セッションの目的 ▪ オブザーバビリティプラットフォームや監視ツールを使ってい ても、実際にその意味を読み解くにはコンピュータサイエンス の理解が必要です。 ▪ モニタリングツールで何を見てそれをどのように解釈するのか、 なぜそのようなことが起こるのか ▪ 実際の問題を2つ取り上げて解説します。
4
今日の課題 ▪ CPU使用率の読み方 – コア毎使用率の意味と計算機概論 ▪ N+1(または1+N)問題 – 見つけ方とその発生原因 5
CPU使用率 コア偏り問題は何故発生するのか 6
コア毎のCPU使用率 ▪ Zabbixでは ▪ system.cpu.util[0,idle, avg1] ▪ system.cpu.util[1,idle, avg1] ▪
CPUコア毎の使用率を取得 できます。 7
コア毎のCPU使用率 ▪ New Relicでは ProcessSampleでコア毎の CPU使用率を取得していま す。 8
CPUとは何か ▪ CPUとは、キャッシュから レジスタに値を読み込む ▪ レジスタ同士で演算を行う ▪ キャッシュに必要な情報は メモリや外部記憶装置、外 部入出力装置からやってく
る 9 レ ジ ス タ レ ジ ス タ レ ジ ス タ レ ジ ス タ キャッシュ キャッシュ キャッシュ キャッシュ フラグ フラグ
CPUと割り込み処理 ▪ 外部記憶装置の入出力は CPUに比べて遅い ▪ 遅いので待っている時間は Iowaitとなる。 ▪ 通信装置の入力は順番通り とは限らない
– 順番整理をCPUが行う ▪ パケットが届くとCPUに割 り込み命令が入る 10 CPU メモリ 外部 装置 割り込み
通信負荷とコア専有 ▪ 受信パケットは順番通り届かない – 経路毎に先着後着があるので、並べ替えないとデータにならない – 割り込み処理は通常特定のコアに偏る – 現代の処理は通信処理が大きい –
パケット処理に1コアが専有され、他のコアは処理したくても処理する データが無い ▪ CPUではなくてNICに処理させるのがハードウェアオフロード 11
解決策 ▪ DPDK(Data Plane Development Kit) – CPUを通信専用にして全コアで処理する(ソフトウェアルータ向け) ▪ https://ascii.jp/elem/000/001/691/1691592/
▪ RSS(Receive-Side Scaling) – NICからの割り込みを複数コアに分散させる ▪ https://qiita.com/nyamage/items/04f348a868475cef 0c77 ▪ https://speakerdeck.com/yuukit/linux-network- performance-improvement-at-hatena 12
解決策 ▪ シングルスレッド性能を上げる ▪ 小数コアマルチサーバー構成への変更 13
監視運用の視点から ▪ 高トラフィック環境では、データ処理では無くパケット処理の ためにCPUの1コアが専有される – 割り込み処理の特性 – 処理するデータが無いので他のコアは暇 ▪ 問題解決には対応したNICやOSカーネルのチューニングが必要
– バニラな環境だと発生しやすい ▪ ただのCPU使用率だと見落とす(コア毎の値が必要) – 1コアのみ専有は総CPU使用率としては低く出る – シングルコア限界を見つける必要がある 14
N+1問題 発生原因と気付きづらさ 15
N+1問題 ▪ フレームワークがSQLを組み立ててくれる(プログラマがSQL を意識しない)言語で発生しやすい ▪ 同じSQL問合せを処理をデータ件数分実行してしまう。 ▪ アプリケーションパフォーマンス劣化のよくある原因 ▪ https://qiita.com/massaaaaan/items/4eb770f20e636f
7a1361 16
N+1問題 ▪ インフラエンジニアやDBAは気付きにくい – SQLを意識して書く、自分でJOINする ▪ プログラマも気付きにくい – コードにエラーも無く、処理結果も合っている –
フレームワークの出力するSQLが非効率 – DB応答が遅いのでインフラ(DB)の問題だと思い込む 17
N+1問題の発見 APM(アプリケーションパ フォーマンスモニタリン グ) 1つの処理の中で同じSQL を何回発行したのかを可視 化 18
解決策 ▪ APMによってN+1問題が発生していることを確認 ▪ preload やeager_loadなどSQLの結果をキャッシュしておく フレームワーク処理を利用する。 19
監視運用の視点から ▪ 原因はアプリケーションコード ▪ 事象としてはDBが遅いのでインフラ起因のように見える ▪ インフラ監視だけだと気づけない ▪ APMで実際の処理を可視化して原因コードを特定 ▪
アプリケーションに改善を依頼 20
コンピュータサイエンス ▪ ほとんどの事象には原因がある。 – おまじない、オカルトではない ▪ レジスタ、キャッシュ、割り込み処理 ▪ 計算量概念、計算コスト概念(DeleteとDrop) ▪
コンピュータサイエンスを理解する事で監視ツールの値が読め るようになる ▪ 監視ツールの値を読むことで概念ではなくコンピュータサイエ ンスの実験として実際に観測できる 21
参考文献 ▪ 入門 計算機概論 – https://www.amazon.co.jp/dp/427412956X ▪ https://ascii.jp/elem/000/001/691/1691592/ ▪ https://qiita.com/nyamage/items/04f348a868475cef
0c77 ▪ https://speakerdeck.com/yuukit/linux-network- performance-improvement-at-hatena ▪ https://qiita.com/massaaaaan/items/4eb770f20e636f 7a1361 22