ECSタスクが起動しなくなった、という場合。普通のサーバだったらまずログを見に行くがECSタスクだとサーバが起動しないとすぐ タスクが停止されるということもありログが取りにくい。 そんな場合は停止したタスクの詳細の停止理由のところを見るといい。詳細は以下。
楽観ロックでもデッドロックは発生する
sqlでDBのデータをupdateする場合、updateした行はcommitされるまでロックされるため、 複数行を複数回SQLを実行してUpdateすると、デッドロックが発生する可能性がある。詳細は以下サイト参照。
ただし、複数行のUpdateがAtomicな操作で一度に行われればデッドロックは起きない。 なので対策としてはテーブル・レコードの更新順を決めてみんなでそれを守るか、bulk insertを使うなどして一度のupdate実行でデータを更新する、になるかなと思う。 DBにはデッドロック検知機能があるらしいので保険としてそれを使うと良さそう。
sagemaker.get_execution_role()を実行すると「KeyError: 'UserSettings'」エラー
以下の記事では解決できなかったが、解決方法が見付かった。
原因はSageMaker SDKの不具合で、2.46以上であれば修正されているらしい。 SageMaker StudioでPython 3(Data Science)を起動するとsagemakerのバージョンが2.40.0だったので
!pip install -U sagemaker
をセルに入力して実行し、sagemakerをUpgradeし、kernelをrestartしたら直った。
参考：
conda環境の本番と開発の差分ができにくくしたい
普通にやると、prod.yamlとdev.yamlを作ってそれぞれを使って本番のconda環境と開発のconda環境を 作ると思うが、そうすると例えばprodのtensorflowのバージョンは上げたけどdevの方は上げ忘れた・・ということが起き得るので 二重管理にならないようにしたい。
conda updateコマンドを使うと既存のconda環境にパッケージを追加することができるので、dev.yamlにはprod.yamlにないパッケージだけを定義するようにして、以下のようにcreateしてupdateすれば良さそう。
conda env create --file prod.yaml conda env update --name myenv --file dev.yml --prune
condaがnpmのpackage.jsonのようにdevDependencies機能を持っていたらいいのに・・
参考：
AESのブロック長は128bit固定
勘違いしてたけど、AESのブロック長は128bit固定。なのでIVも常に128bit。
鍵長は128,192,256から選べる。
鍵はデータとXORを取るために使うのに、なぜブロック長と鍵長が一致しなくてもいいのかが不思議だ。以下の記事から想像するに、↓のようにしているのかなと思う。
- 鍵の先頭から32bit分を取り出す
- ブロックを32bitずつ分けて1とのXORを取る
- 鍵から次の32bit分を取り出し、再度XORを取る。この繰り返し
AddRoundKeyの処理を詳しく書いてる資料がなかなか見付からないな。。
box driveのcacheを削除する
box driveのcacheフォルダの容量が20GBぐらいになっていた。直接削除してもいいのかも知れないが、Boxのサイトにログアウトするとcacheが削除されると記載されていたので一度ログアウトした。無事cacheが削除されました。
参考： support.box.com