データサイエンティスト向け性能問題対応の基礎

データサイエンティストの皆さん、次のような性能問題にであったことないでしょうか。「データの加工処理が遅いからインスタンスタイプを上げたが速くならなかった」「機械学習の学習が遅いから、GPUを増やしたが、速くならなかった」こういったときにどうすればよいか説明します。

Transcript

1. Mobility Technologies Co., Ltd.
   データサイエンティスト向け
   性能問題対応の基礎
   2022/2/14
   渡部徹太郎
   

   View Slide

2. Mobility Technologies Co., Ltd.
   § 目的
   § 処理が遅いときにどういうふうに調査・対応すればよいのか、わかるよう
   になる
   § 例えば、以下のような場合に有効
   § データの加工処理が遅いからインスタンスタイプを上げたが速くならなか
   った
   § 機械学習の学習が遅いから、GPUを増やしたが、速くならなかった
   § 前提とする環境
   § AWS上のLinux OS もしくは LinuxベースのDockerコンテナ
   目的
   2
   

   View Slide

3. Mobility Technologies Co., Ltd.
   § 性能問題対応の手順
   § 1. 性能要求の確認
   § 2. 遅い箇所の特定
   § 3. なぜ遅いかの調べ方
   性能問題対応の手順
   3
   

   View Slide

4. Mobility Technologies Co., Ltd.
   § 遅いではなく、明確な数値目標との比較にする
   § ✕データ加工処理が遅い
   § ○データ加工が30秒で終わって欲しいのに、90秒かかる
   →性能要求を満たしている場合は、さっさと他の仕事に移る
   1. 性能要求の確認
   4
   

   View Slide

5. Mobility Technologies Co., Ltd.
   § プロセス(スレッド)を特定する
   § マルチプロセス/スレッドで動く場合は、どのプロセス/スレ
   ッドが遅いのか調べる
   § Dockerで実行する場合も同様。Dockerの子プロセスに見える
   ため。
   § プログラムのどの部分が遅いのか調べる
   § 例えば
   § プログラムのログからデータ加工90秒の内訳
   § DBからデータの取得は10秒 →目標値通り
   § データの加工は77秒 →目標より60秒遅い
   § データのS3への保存3秒 →目標値通り
   § 調べ方
   § プログラムのログを見る
   § タイマーを仕込む
   § プロファイラを使う
   § 例えばPyCharmのプロファイラを用いれば、各関
   数の呼び出し回数や時間がわかる（右図）
   2. 遅い箇所の特定
   5
   図：PyCharmのプロファイラ画面
   

   View Slide

6. Mobility Technologies Co., Ltd.
   § 基礎となる考え
   § 「もしもリソースに無限のスペックが有り、外部から待たされることがないなら、
   処理は一瞬で終わる。
   そうならないのは、リソースにボトルネックが有るか、外部から待たされているから」
   § リソースには「ハードウェアリソース」と「ソフトウェアリソース」が有る
   § どうアプローチするか？
   § →もっとも観測しやすいハードウェアリソースボトルネックから調査を始める
   3. なぜ遅いのかの調べ方
   6
   

   View Slide

7. Mobility Technologies Co., Ltd.
   ハードウェアボトルネック
   7
   コンピュータ
   プロセッサ
   ディスク
   入力 出力
   外部システム
   永続化
   DB API
   ネットワーク
   § ハードウェアボトルネックで疑うべきリソースは、プロセッサ、ネットワークディスクの３つ
   § 他にもストレージコントローラや、バスなどもあるが、問題になることはほぼない。
   § メモリについては最後に触れます
   ネットワーク ディスク
   プロセッサ
   ネットワーク ディスク
   プロセッサ
   ネットワーク ディスク
   プロセッサ
   ディスク
   ボトルネック
   プロセッサ
   ボトルネック
   ネットワーク
   ボトルネック
   図：ボトルネックのイメージ
   図：ボトルネックを疑うべき３つのリソース
   

   View Slide

8. Mobility Technologies Co., Ltd.
   § プロセッサとはCPUもしくはGPUのこと
   § プロセッサボトルネックとは
   § 一つのコアの使用率のusrとsysの合計が100%近くで
   推移する
   § ロードアベレージがコア数以上になること
   § 確認方法
   § CPU使用率はdstatコマンド
   § AWSのメトリックはOS全体なので参考程度
   § プロセスごとに見たければ、psコマンド or top
   コマンド
   § CPUロードアベレージはtopコマンド
   § GPU使用率は nvidia-smi コマンド or NvidiaのAPIを使
   用したツール
   § よくある落とし穴
   § ４コアのCPUがあり、OS全体のCPU使用率が25%であ
   っても、一つのコアが100%ならCPUボトルネック
   プロセッサボトルネック
   8
   図：dstatの結果. CPU0とCPU1のそれぞれのコアで使用率が出る
   図：全体のCPU使用率は25%だが、コア2は100%
   

   View Slide

9. Mobility Technologies Co., Ltd.
   § 単一プロセスの処理速度をあげる
   § CPUを動作クロック数の高いものに変える
   § →現代においてはクロック数は頭打ちなので、厳しい
   § 計算毎に得意なプロセッサに任せる。
   § 大量の行列計算はCPUよりGPUの方が得意等
   § →自作は不可能なので、対応するライブラリがないと厳しい。
   § マルチプロセス・マルチスレッドにして、複数プロセッサを活用する
   § →これが最も現実的
   プロセッサボトルネックの解消方法
   9
   

   View Slide

10. Mobility Technologies Co., Ltd.
    § プロセッサ、特にGPUはコンピュータシステムの中で最も高価な資源
    § そのため、CPUやGPUボトルネックはシステムを使い倒せている証拠
    § 機械学習のワークロードであればGPU使用率100%を目指すべき
    § 性能要件を満たせていれば、プロセッサボトルネックはシステムが健全な証拠
    プロセッサボトルネックは悪くない
    10
    

    View Slide

11. Mobility Technologies Co., Ltd.
    § ネットワークボトルネックとは
    § ネットワークインターフェースへの送信・受信容
    量が回線の帯域の80%程度で張り付いている
    § TCP/IPだと80%程度で頭打ちになる
    § 例：1Gbpsの回線で800Mbps利用して張り付い
    ている
    § 確認方法
    § EC2のメトリック
    § dstat コマンドのrecv, sendの値
    § よくある落とし穴
    § 上り回線と下り回線は別。
    § EC2インスタンスによって使えるネットワーク帯
    域は異なる
    § EC2のネットワークインターフェースに余裕は有
    っても、ネットワーク経路全体にボトルネックが
    あるとだめ。ゲートウェイ、NAT、等。このデバ
    ッグはかなり難しい
    ネットワークボトルネック
    11
    図：dstatの出力結果でネットワークの利用量がわかる
    図：EC2のインスタンス毎にネットワーク帯域幅が異なる
    

    View Slide

12. Mobility Technologies Co., Ltd.
    § ディスクボトルネックとは
    § CPUのIO waitの値が100%になる。
    § ディスクの使用率が60％程度、
    IOキューが増えている
    § 確認方法
    § dstatコマンドのwaiの値
    § ディスクの使用率やキュー長はiostatやsarコマンドだが、見方が難しい
    § よくある落とし穴
    § AWSにはEC2のマシンに搭載されているローカルディスク(SSD)とリモー
    トディスク(EBS)の2種類がある
    § EBSは最初は速いが後に遅くなるバーストという特徴がある
    § Linuxにはファイルシステムキャッシュがあるため、キャッシュに乗るか
    乗らないかで大きな違いが有る
    ディスクボトルネック
    12
    図：dstatの出力結果でCPUのI/O待ちの割合がわかる
    

    View Slide

13. Mobility Technologies Co., Ltd.
    § ファイルシステムキャッシュとは
    § LinuxにあるディスクI/Oを高速化する仕組み
    § ディスクからの読み出しをメモリ上にキャッシュし、そのデータ
    への応答をメモリから返す
    § ディスクへの書きこみはメモリ上に書いた時点でプロセスに応答
    し、ディスクへの永続化は非同期で行う
    § ファイルシステムキャッシュは余ってるメモリ領域から自動的に作ら
    れる
    § 何に注意すべきか
    § ファイルシステムキャッシュに使えるメモリ量が減ってなことを注意
    § 減ると→ディスクI/Oが増える→ディスクボトルネックになりやす
    くなる
    § どうやって確認にするか
    § freeコマンドや、vmstatコマンドのbuffとcacheの値
    ディスクボトルネックで注意すべきファイルシステムキャッシュ
    13
    プロセス/スレッド
    ディスク
    ファイルシステム
    キャッシュ
    図：ファイルシステムキャッシュの位置
    図：freeコマンドのバッファとキャッシュの値
    

    View Slide

14. Mobility Technologies Co., Ltd.
    § メモリがボトルネックになることはほぼ無い
    § メモリへの読み書き速度はディスクの100倍以上は速いため、ボトルネックになることは殆どない
    § ただし、メモリの使用量は少ないほうが良い
    § プログラムが使用するメモリが増えるとどうなるか
    § OSからkillされる場合
    § プログラムは強制停止される。いわるゆ「OOM Killer」
    § OSからkillされない場合
    § 必要なメモリ量が物理メモリでは足りないため、ディスクにデータが書かれるようになる。い
    わるゆ「スワップアウト」。これが発生すると、プログラムが劇的に遅くなる。
    § これが発生しているかはfreeコマンドやvmstatのswpの値を見ればわかる
    § プログラミングの実行環境でGC（ガベージコレクション）が発生し、遅くなる
    § Java, Python, Goはおきる。Rustはこれがない。
    メモリは？
    14
    図：freeコマンドのスワップの値
    

    View Slide

15. Mobility Technologies Co., Ltd.
    § ハードウェアリソースボトルネックがない場合は「ソフトウェアリソースのボトルネック」も
    しくは「外部から待たされている」
    § ソフトウェアリソースのボトルネックの例
    § OS
    § プロセス・スレッド数限界
    § ファイルディスクリプタの数限界
    § アプリケーション
    § 排他ロック
    § スレッドプール枯渇
    § 外部から待たされている例
    § DBからの応答待ち
    § APIからの応答待ち
    § 利用者のキーボード入力待ち
    ハードウェアリソースボトルネックがない場合
    15
    アプリケーションの実装に依る
    

    View Slide

16. Mobility Technologies Co., Ltd.
    § 一番詳しいのは「詳解システム・パフォーマンス」
    参考図書
    16
    § 700ページ近くあるので、初学者にはおすすめできない。
    § このスライドを見ながら性能問題対応を実践し、ある程度経験を積んでからこ
    の本を見ると納得感がすごい
    

    View Slide

17. confidential
    文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。
    Mobility Technologies Co., Ltd.
    17
    

    View Slide