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.6k
オブザーバビリティで理解するコンピュータサイエンス
JTF2021 D2 登壇資料
- CPU使用率の読み方 コアごと使用率の意味と計算機概論
- N+1問題 見つけ方とその発生原因
Qryuu
July 18, 2021
Tweet
Share
More Decks by Qryuu
See All by Qryuu
監視論Ⅳ ~監視からオブザーバビリティーへの招待~
qryuu
0
450
人体モニタリングによる運動療法継続
qryuu
0
180
監視とは何か ~監視エンジニアのスキルと成長~
qryuu
8
8.7k
監視論 ~SREと次世代MSP~
qryuu
10
5k
Other Decks in Science
See All in Science
データから見る勝敗の法則 / The principle of victory discovered by science (open lecture in NSSU)
konakalab
1
180
データマイニング - ノードの中心性
trycycle
PRO
0
280
知能とはなにかーヒトとAIのあいだー
tagtag
0
100
高校生就活へのDA導入の提案
shunyanoda
0
6k
06_浅井雄一郎_株式会社浅井農園代表取締役社長_紹介資料.pdf
sip3ristex
0
660
04_石井クンツ昌子_お茶の水女子大学理事_副学長_D_I社会実現へ向けて.pdf
sip3ristex
0
660
凸最適化からDC最適化まで
santana_hammer
1
310
論文紹介 音源分離:SCNET SPARSE COMPRESSION NETWORK FOR MUSIC SOURCE SEPARATION
kenmatsu4
0
340
NASの容量不足のお悩み解決!災害対策も兼ねた「Wasabi Cloud NAS」はここがスゴイ
climbteam
1
160
CV_3_Keypoints
hachama
0
210
Transport information Geometry: Current and Future II
lwc2017
0
210
動的トリートメント・レジームを推定するDynTxRegimeパッケージ
saltcooky12
0
200
Featured
See All Featured
The Invisible Side of Design
smashingmag
302
51k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Building Applications with DynamoDB
mza
96
6.7k
Code Review Best Practice
trishagee
72
19k
Rails Girls Zürich Keynote
gr2m
95
14k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.2k
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