Ruby on Rails開発のインターン （Day 9）
こんにちは、皆さん！
2回目の月曜日がやってきた。いい週末だった。ゆっくり休みをとって後はリラックスしてって感じ。
今週から勤務時間がもとの6時間に戻るから、楽になる。
今日はTwilioで利用したアプリケーションのテストと例の困ったメモリリークの続き。
- トピック：
- 疑問：
- 問題：
- データベースがめちゃくちゃに (解決)
- 学習した内容：
heroku logs -tでライブのHerokuログが見れる- Memory bloatたるものが存在する
- 今後やりたいこと：
- Twilioについてもっと勉強する
- リソース：
Herokuのデータベースを確認する方法
heroku runをつければ、ほとんどHeroku上でも使える。こうやって、一つのコマンドの意味と本当に正しい使い方を知ると一層プログラミングが楽しくなるものだ。で、これがどうやって利用できるかというと、データベースがめちゃくちゃになっちゃった僕のデータベースにはいったい何があるのか気になったのでローカルでよくやるRailsのコンソールを以下のようにHerokuで実行した。
heroku run rails c
その後、User.allでデータベースのUserの部分にアクセス。それで、空集合が返ってきたのでデータベースに,Userが何もないことを知った。
結局、以下のように以前に取っておいたバックアップでデータベースを復帰させた。(もちろんいくつかのデータは失った）
$ heroku pg:backups restore [id of backups]
僕は同じHerokuアプリで複数の異なるコードをテストしていたので、これからこれにって感じで移動したときにデータベースの内容が混ぜったのが原因。みなさんは絶対に混ぜないでね(笑)
新しいマイグレーションを追加したときなどはちゃんと以下のコマンドでテーブルを更新しよう。
$ heroku run rake db:migrate
Memory Bloat vs Memory Leak
個人的にこのサイト（Debugging memory bloat）の以下の写真が一番２つの違いを理解しやすくしてくれるだろう。
見ての通り、memory bloatでは短い期間にメモリの使用量が急増している。しかし、そのメモリの使用量も最終的にはある一定の範囲内に落ち着く。これはメモリの使用量がどんどん上昇するだけではないことを示している。
一方で、memory leakは少しだが、ずっとメモリの使用量が上昇し続けている。よって、最終的にはメモリを使い切ってしまうのだ。
よって、memory bloat はmemory leakよりも安全であり、必ずしもプログラムをクラッシュさせるとは限らない。しかし、memory leakはそのまま放っておくとあっという間にプログラムをクラッシュさせる要因となりうる！！
まとめ
それと、memory leakだと思っていたものが単なるmemory bloatである可能性が高くなってきた。少し安心した。今のプログラムでそれのせいでクラッシュしない可能性があるからね。
ご精読ありがとうございました。では、また次回まで✌
