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.4k
オブザーバビリティで理解するコンピュータサイエンス
JTF2021 D2 登壇資料
- CPU使用率の読み方 コアごと使用率の意味と計算機概論
- N+1問題 見つけ方とその発生原因
Qryuu
July 18, 2021
Tweet
Share
More Decks by Qryuu
See All by Qryuu
監視論Ⅳ ~監視からオブザーバビリティーへの招待~
qryuu
0
310
人体モニタリングによる運動療法継続
qryuu
0
130
監視とは何か ~監視エンジニアのスキルと成長~
qryuu
8
8.4k
監視論 ~SREと次世代MSP~
qryuu
10
4.8k
Other Decks in Science
See All in Science
作業領域内の障害物を回避可能なバイナリマニピュレータの設計 / Design of binary manipulator avoiding obstacles in workspace
konakalab
0
140
Cross-Media Information Spaces and Architectures (CISA)
signer
PRO
3
28k
構造設計のための3D生成AI-最新の取り組みと今後の展開-
kojinishiguchi
0
420
qeMLパッケージの紹介
bob3bob3
0
1.5k
Machine Learning for Materials (Lecture 9)
aronwalsh
0
190
2024-06-16-pydata_london
sofievl
0
460
Machine Learning for Materials (Lecture 2)
aronwalsh
0
690
All-in-One Bioinformatics Platform Realized with Snowflake ~ From In Silico Drug Discovery, Disease Variant Analysis, to Single-Cell RNA-seq
ktatsuya
0
190
Machine Learning for Materials (Lecture 1)
aronwalsh
1
1.9k
Reaping the Benefits of Ritual and Routine
arthurdoler
PRO
0
160
最新のAI技術を使った材料シミュレーションで材料研究現場に変革を
matlantis
0
720
ウェーブレットおきもち講座
aikiriao
1
770
Featured
See All Featured
From Idea to $5000 a Month in 5 Months
shpigford
379
46k
4 Signs Your Business is Dying
shpigford
179
21k
Happy Clients
brianwarren
96
6.6k
Raft: Consensus for Rubyists
vanstee
136
6.5k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Docker and Python
trallard
39
3k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Fantastic passwords and where to find them - at NoRuKo
philnash
48
2.8k
Ruby is Unlike a Banana
tanoku
96
11k
A Philosophy of Restraint
colly
202
16k
Statistics for Hackers
jakevdp
794
220k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
43
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