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
370
人体モニタリングによる運動療法継続
qryuu
0
150
監視とは何か ~監視エンジニアのスキルと成長~
qryuu
8
8.5k
監視論 ~SREと次世代MSP~
qryuu
10
4.9k
Other Decks in Science
See All in Science
地表面抽出の方法であるSMRFについて紹介
kentaitakura
1
340
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
130
生成AI による論文執筆サポートの手引き(ワークショップ) / A guide to supporting dissertation writing with generative AI (workshop)
ks91
PRO
0
400
20分で分かる Human-in-the-Loop 機械学習におけるアノテーションとヒューマンコンピューターインタラクションの真髄
hurutoriya
5
2.8k
MoveItを使った産業用ロボット向け動作作成方法の紹介 / Introduction to creating motion for industrial robots using MoveIt
ry0_ka
0
310
観察研究における因果推論
nearme_tech
PRO
1
160
論文紹介: PEFA: Parameter-Free Adapters for Large-scale Embedding-based Retrieval Models (WSDM 2024)
ynakano
0
220
事業会社における 機械学習・推薦システム技術の活用事例と必要な能力 / ml-recsys-in-layerx-wantedly-2024
yuya4
4
300
統計学入門講座 第1回スライド
techmathproject
0
230
小杉考司(専修大学)
kosugitti
2
620
ベイズ最適化をゼロから
brainpadpr
2
1.1k
FOGBoston2024
lcolladotor
0
150
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Bootstrapping a Software Product
garrettdimon
PRO
306
110k
Side Projects
sachag
452
42k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
The World Runs on Bad Software
bkeepers
PRO
67
11k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
Faster Mobile Websites
deanohume
306
31k
GitHub's CSS Performance
jonrohan
1030
460k
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