Amazon RDS耗尽可用内存。 我应该担心吗？
我有一个Amazon RDS实例。 Freeable Memory自build立1-2周以来一直在下降，从15GB内存降到250MB左右。 由于它在最后几天已经下降了，所以它已经开始像一个锯齿图案，其中Freeable Memory下降到这个范围（250-350MB），然后以锯齿图案返回到500-600MB。
应用质量没有显着下降。 但是，我担心DB会耗尽内存并崩溃。
RDS实例是否存在内存不足的危险？ 是否有一些设置或参数，我应该看看，以确定实例设置是否正确？ 是什么造成了这种锯齿图案？
MySQL使用可用内存字段缓冲和caching自己的进程。 随着时间的推移，Freeable内存的数量会减less，这是正常的。 我不会担心它会踢出旧信息，因为它需要更多的空间。
简短的回答 – 除非它变得非常低（大约100-200 Mb），否则不应该担心FreeableMemory，或者发生重要的交换（请参阅RDS SwapUsage指标）。
FreeableMemory不是MySQL度量标准，而是OS度量标准。 很难给出准确的定义，但你可以把它作为内存，操作系统将能够分配给任何人请求它（在你的情况下，它可能会是MySQL）。 MySQL有一组设置，它将整个内存的使用限制在某个上限（你可以使用类似的方法来实际计算）。 由于一般情况下，您永远不会达到最大连接数，所以您的实例不可能达到此限制，但这仍然是可能的。
现在回到FreeableMemory指标的“下降”。 对于MySQL来说大部分的内存是由InnoDB缓冲池消耗的（详情请看这里 ）。 默认情况下，默认情况下，RDS实例的缓冲区大小设置为主机物理内存的75％，在您的情况下，大小约为12 GB。 该缓冲区用于caching在读取和写入操作中使用的所有DB数据。 所以在你的情况下，因为这个缓冲区真的很大 – 缓慢地填充caching的数据（很可能这个缓冲区实际上足够大以便caching所有的DB）。 所以当你第一次启动你的实例时，这个缓冲区是空的，而且一旦你开始读取/写入数据到DB中，所有这些数据都被带入caching。 他们将留在这里，直到这个caching变满，新的请求来了。 这时最近最less使用的数据将被新数据取代。 因此，DB实例重启后FreeableMemory的初始衰落就解释了这一事实。 这不是一件坏事，因为你实际上要尽可能地把你的数据caching起来，以便你的DB更快地工作。 唯一可以讨厌的是当这个缓冲区的部分或全部将被推出物理内存交换。 在这一点上，你将有巨大的performance下降。
作为一种预防性保健措施，如果FreeableMemory指标始终处于100-200 Mb的级别，则调整用于不同事物的MySQL最大内存可能是一个好主意，只是为了减less交换的可能性。
