EC2インスタンスでの/ tmpのサイズの増加

EC2 ebsでUbuntuサーバーを実行していますが、アプリケーションには/ tmpに割り当てられた大量の一時ディスク領域が必要です。ただし、ec2では、/ tmpも含むルートドライブはかなり小さく、約10GBです。残りのディスク領域はすべて/ mntの下にマウントされます。その結果、/ tmpがいっぱいになっているように見えるため、アプリケーションで「ディスク領域不足」エラーが返されます。

この問題を解決する最良の方法は何ですか？私が考えることができる1つのことは、/ mnt / tmpを作成してシンボリックリンクを作成することです

/tmp --> /mnt/tmp

しかし、私は非常に多くのLinuxプログラムやツールで使用されているものをいじくり回すことに少し消極的です。すべてのプログラムがシンボリックリンクを正しく解決するかどうか、またそれがパフォーマンスにどう影響するかはわかりません。

EBS-backedイメージを使用すると、エフェメラルストレージは引き続き利用可能です。デフォルトでは、ブロックインスタンスとしてマッピングされません（インスタンスストアイメージの場合と同様）。

アマゾンのドキュメントはこちら、便利なブログの投稿はこちら

要約すると、イメージを起動するときにコマンドラインでこのマッピングを指定し、それを通常のボリュームとしてにマウントできます/dev/sd[x]。または、独自のAMIをロールする場合は、そのAMIへのマッピングをベイクして、そこから起動されたすべてのイメージが最初からAMIにアクセスできるようにすることができます。

シンボリックリンク/tmpは機能しますが、大量の一時ストレージが使用されているこの場合はお勧めしません。あなたはデバイスマッピングが使用可能にしたら、デバイスとしてマウントされていることができます/tmpの中で/etc/fstab。

小規模なインスタンスでは、150 GBのインスタンスストアを無料で利用できるはずです。言うまでもなく、インスタンスが再起動すると、このストレージは停止します。使用方法が一時的でない場合は、独自の新しいEBSボリュームを作成し、そのようにマウントする必要があります。

/ tmpマウントポイントを/ mnt / tmpにバインドできます。

sudoマウント-B / tmp / mnt / tmp

質問で提案されているシンボリックリンクはそれほど悪い解決策ではありません。ただし、その際には注意が必要です。ボリュームのマウントに関連する正確な手順を統合するには、次のとおりです。

1）AWSコンソールで新しいボリュームを作成します。インスタンスにアタッチします。

2）フォーマットしてマウントする /mnt/vol1

3）/tmp可能な限りクリーンアップします。

4） mkdir /mnt/vol1/tmp && mv /tmp/* /mnt/ && rmdir /tmp && ln -s /mnt/vol1/tmp /tmp