解放可能なメモリが不足しているAmazon RDS。心配する必要がありますか？
Amazon RDSインスタンスがあります。フリーアブルメモリは、セットアップ後1〜2週間で、15 GBのメモリから約250 MBまで減少しています。過去数日間でこの低値を下回ったため、Freeable Memoryがこの範囲（250〜350MB）に低下する鋸歯状パターンに似始め、その後鋸歯状パターンで500〜600MBに戻ります。
アプリケーションの品質に顕著な低下はありませんでした。ただし、DBのメモリが不足してクラッシュするのではないかと心配しています。
RDSインスタンスがメモリ不足になる危険性はありますか？インスタンスが正しく設定されているかどうかを判断するために検討する必要がある設定またはパラメーターはありますか？この鋸歯状パターンの原因は何ですか？
MySQLは、自身のプロセスのバッファリングとキャッシュのために解放可能なメモリフィールドを使用します。通常、Freeableメモリの量は時間とともに減少します。より多くのスペースを必要とするため、古い情報が追い出されるのを心配する必要はありません。
簡単な答え-FreeableMemoryが本当に低くなった場合（約100-200 Mb）または大幅なスワッピングが発生した場合を除き、心配するべきではありません（RDS SwapUsageメトリックを参照）。
FreeableMemoryはMySQLメトリックではなく、OSメトリックです。正確な定義を与えることは困難ですが、OSがそれを要求するすべての人に割り当てることができるメモリとして扱うことができます（あなたの場合は、おそらくMySQLです）。 MySQLには、全体的なメモリ使用量をある上限に制限する一連の設定があります（実際に計算するには this などを使用できます）。一般に、接続の最大数に到達することはないため、インスタンスがこの制限に達することはほとんどありませんが、これは可能です。
次に、FreeableMemoryメトリックの「減少」に戻ります。 MySQLの場合、ほとんどのメモリはInnoDBバッファープールによって消費されます（詳細については here を参照）。そこにあるRDSインスタンスのデフォルトでは、このバッファのサイズはホストの物理メモリの75％に設定されています-あなたの場合は約12 GBです。このバッファーは、読み取り操作と書き込み操作の両方で使用されるすべてのDBデータをキャッシュするために使用されます。したがって、あなたの場合、このバッファは本当に大きいため、キャッシュされたデータでゆっくりといっぱいになります（このバッファは実際にはすべてのDBをキャッシュするのに十分な大きさである可能性があります）。したがって、最初にインスタンスを起動すると、このバッファーは空になり、DBへの読み取り/書き込みを開始すると、このデータはすべてキャッシュに取り込まれます。このキャッシュがいっぱいになり、新しいリクエストが来たときまで、彼らはここに留まります。この時点で、少なくとも最近使用したデータは新しいデータに置き換えられます。したがって、DBインスタンスの再起動後のFreeableMemoryの最初の減少は、この事実を説明しています。これは悪いことではありません。実際には、DBがより高速に動作するために、できる限り多くのデータをキャッシュする必要があります。厄介なことができる唯一のことは、このバッファの一部またはすべてが物理メモリからスワップにプッシュされるときです。その時点で、パフォーマンスが大幅に低下します。
予防措置として、FreeableMemoryメトリックが常にスワップの可能性を減らすために100〜200 Mbのレベルにある場合に、異なるものに使用されるMySQL最大メモリを調整することをお勧めします。
AWSでのいくつかのサポートチケットの後、パラメータグループを調整すると、特に共有バッファが、メモリ不足によるドロップやフェイルオーバーを回避するために予約された量を維持するためにそれらを下げるのに役立つことがわかりました