前提
開発環境 AWS cloud9 (t2.micro)
ボリューム 現在20GB
Swap領域の使用 1GB分
[参考] EC2インスタンスのSwap領域を作成する - Qiita
LaravelでのWebアプリケーション開発にCloud9を使用しております。
開発中のプロジェクト4件分のディレクトリが同一環境内に保存されています。
不具合の発生頻度は頻度としては1日につき1,2回程度です。
現状、こちらには退避策もあり致命傷には至っておりませんので、回答予定の閲覧者様には余裕のある時にご確認いただきたく思います。
発生している問題
ファイルの保存を行おうとすると時々、上部にしばらく Saving... と表示されます(通常であれば、瞬時に保存処理が終わる)。
しばらく待って All changes saved. と出る場合もありその時は安堵するのですが、
大半の場合は赤色のアラートが出現し Failed to write to '(ファイルの中身)'. Failed to retrieve resource from '[ファイルの絶対パスURL]' with code 0. と警告されます。
一度こうなってしまうと、ターミナルも固まって df -h コマンドなどが試せない状況です。
この状況でページの更新・cloud9の開き直しを行っても、良くても同様の不具合が再現されるまでで、
悪い場合は大きくConnecting… と表示されたままで、いつまで待ってもCloud9が立ち上がらなくなってしまいます。
どの道このままでは作業になりませんので、
EC2 > インスタンス > インスタンスの状態 > インスタンスの停止
と進み、インスタンスが「停止済み」になるのを確認してから再度cloud9を開くことで、
環境のリフレッシュを行った気になってやり過ごしています。
環境を操作することで解決をはかる
以下、環境の遍歴を時系列順に記します。(特にボリューム増設に関しては後戻りができないので、このような書き方をしています)
[0] ボリュームが10GBしかない環境下で、容量不足が原因と思える不具合が小出しに出始める
↓ 症状: ファイルを開くのがスムーズにできなかったり、時々保存に時間がかかると感じる程度。
[1] 講習で指定がありSwap領域を使用していたが、ボリュームを優先しSwap領域を解放する
↓ 症状: メモリが不足しファイルの保存に支障が出る
[2] ググった限りではボリュームを増設した方がストレスを軽減できそうだと判断し、10GBから20GBに増設
↓ 症状: ボリュームを増やしても同じ不具合が出る
[3] Swap領域を再度確保し、メモリの使用を安定させる
現在の症状: 頻度は減ったものの、まだ同じ不具合が出る
[ボリューム増設時に引っかかったこと]
ボリュームの増設に際して「おや？」と思ったことがありました。
EC2 > ボリューム から容量を変更したところまで済んだら、次はCloud9上で容量を割り当てるコマンドを打つ必要があるそうです。
ですが、lsblk コマンドを打って確認すると、/dev/xvda1 のサイズが既に20MBに変更済みになっていました。
それでも念のため、パーティションの拡張コマンド(sudo growpart /dev/xvda 1)とファイルシステムの拡張コマンド(sudo resize2fs /dev/xvda1)を打ち込んではみました。
パーティション拡張に対する返答: NOCHANGE: partition 1 is size 41940959. it cannot be grown
ファイルシステムの拡張に対する返答: The filesystem is already 5242619 (4k) blocks long. Nothing to do!
やはりコマンドを打つまでもなかったようでした。
ボリューム増設時に参考にしたサイトはこちらです。
【画像あり】AWS Cloud9の容量不足を解決する方法
その他
ボリューム拡張後は、Swap領域を使用し始めてから不具合の頻度が減っています。
また、Swap領域を使わないと「メモリが残り149MBしかないよ！」といったアラートが高頻度で出現するので、なんとなく心臓に悪くて外せないでいます。
話は反れますが、PCのタスクマネージャーやスマホの設定で目にする「メモリ・ディスク・ストレージ」や、AWS内での「メモリ・ボリューム」など、自分の頭の中では一括して「容量」と捉えてしまっています。どの「容量」が切迫しているのかきちんと切り分けないといけないのですが、もしこの質問における私の認識がとっ散らかっているようでしたら遠慮なくご指摘いただければ幸甚です。
ご指摘を受けて (2021/08/20 09:00 追記)
ご指摘と同時に便利なコマンドを教えていただいたので、今からでもバックグラウンドで何が起こっているのか調査することにしました。
(デフォルトで入っていると聞いて早速sarを打ってみましたが、自分で消したのかそもそも入っていなかったのか「インストールしてね！」と言われたので、sar をインストールして以後活用しようと思います)
メモリとディスクの現状を vmstat コマンドで表示してくれるので、さっそく打ってみました。
私の場合は「メモリがネックの可能性が高い」とヒントを頂きました。
そこでメモリに着目すると、ページキャッシュ(cache)がメモリの大半を食っています。
これが邪魔をしてメモリのパフォーマンスが落ちていた、のでしょうか……。
とりあえず、 echo 3 > /proc/sys/vm/drop_caches 等と打つことでbuffとcacheの掃除ができるようで。
一旦これで様子を見ます。
[df -h の結果について]
こちらが現状、「ボリューム拡張後・Swap使用中」です。
記憶する限り、
ボリューム拡張前・Swap使用中 /dev/xvda1 99%
ボリューム拡張前・Swap開放後 /dev/xvda1 85%
という変化を観測しています。
[2021/08/20 17:30 追記]
現状、数字的な根拠を追っている最中ですが、負荷が強まる要因として心当たりがあるのは、次の2点です。
- ファイルの編集・ターミナルの使用でPaneを4つ使っている
php artisan tinker, php artisan serve系を中断しない癖がついている
これを最初の「前提」に書けなかったのは、自分の中では「Laravelプロジェクトを効率よく組立てたくて、普通に使っているだけなのに…」という思い込みがあったからだと思います。
vmstat でリアルタイム値を計測したり sar でログを追ったりするうちに、
「負荷のかかるタイミングを見極められるのであれば、Cloud9の運用方法そのものを改善できるのでは」と気づかされました。
案件を捌くのを優先しつつ、ゆとりのある時にじっくり追ってみようと考えています。
[2021/08/20 18:30 追記]
最初にこの質問を投稿して以来、初めて同じ問題が再現されました。
本記事内のアラートメッセージの記述も修正済みです。
そのタイミングで行っていたのは、以下の2点です。
- 1つのPaneにつき5件ほど開いていたファイルを必要に応じてクローズ
cd コマンドによる操作ディレクトリの移動
sar コマンドで表示された記録をスクショしました。追ってアップロードします。
(情報量が多いため、必要部分のみ抽出しておきます。)
発生日時は2021/08/20 18:00頃です。
Q&A
