色々原因はあるだろうけど、今回はセキュリティグループもルートテーブルも正しく設定しているのになぜ。。 と思ったら、ルートテーブルの設定は反映されるまで多少時間がかかるっぽい。 ルートテーブルの設定変更から数分経ったら直った。 そんなことあるのか。。
AWS Elastic Inferenceは全然Elasticじゃなかった
Elastic Inferenceには以下の制約がある。
・EC2一つに対して一つしかGPUをアタッチできない ・EC2起動時しかアタッチできない ・デタッチできない。使うのをやめる場合はインスタンスを終了しないといけない
いや、普通にGPUインスタンス起動した方がいいでしょ。。一体どこに使いどころがあるんだこれ。。
参考:
ログに「Created TensorFlow device・・・」が大量に出て実行に時間がかかる問題
以下のログが大量に出る問題。
2019-02-27 10:46:30.637017: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 10758 MB memory) -> physical GPU (device: 0, name: Tesla K80, pci bus id: 0000:00:1e.0, compute capability: 3.7) 2019-02-27 10:46:30.885004: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1511] Adding visible gpu devices: 0 2019-02-27 10:46:30.885058: I tensorflow/core/common_runtime/gpu/gpu_device.cc:982] Device interconnect StreamExecutor with strength 1 edge matrix: 2019-02-27 10:46:30.885074: I tensorflow/core/common_runtime/gpu/gpu_device.cc:988] 0 2019-02-27 10:46:30.885081: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1001] 0: N
原因は以下のコードだった。
padded_image: Tensor = tf.image.resize_image_with_crop_or_pad( resized_image, dst_height, dst_width) result_image: np.ndarray = tf.Session().run(padded_image)
・tf.image.resize_image_with_crop_or_padが使いたかった
・その後もcv2.cvtColorを使って色を変えたりしたかったのでTensorをndarrayに変換したかった
・tf.Session().runを使ってndarrayに変換していたが、tf.Session().runはSessionを作成・破棄するので非常に高コストだった
前処理は全部ndarrayでやるか、Tensorでやるか統一しないといけないんだね。。
AWSでDeep Learningの学習データをどこに保存するか
最初はEBSに全部置いていたが、すぐに容量がいっぱいになってしまった。。 今のところ以下が良さそう。
- データの原本・前処理結果・モデルはすべてS3に保存する
- 学習時にS3から学習データを取得する。その際インスタンスストアにキャッシュする。二回目以降はインスタンスストアから取得する
参考:
AWSのインスタンスストアはEBSよりかなり速い
インスタンスストアとEBSの違いがよくわかってなかったのでこんな違うと思わなかった。。 シーケンシャルリードで3倍程度の差がある。 EBSはネットワークストレージなので転送速度は低いようだ。
参考:
Linuxで容量の大きいフォルダを探す方法
du --max-depth=7 /* | sort -n
を実行すると大きい順にソートしてくれる。
いっぱい出てくるのでこんな感じでテストデータなどを置いてるフォルダだけに絞ってもいいかも。 du --max-depth=7 /* | grep work | sort -n
参考: