Объясните эту модель потребления памяти в Amazon RDS / Mysql?

Question

Народ,

Может кто-нибудь объяснить эту модель потребления памяти на Amazon RDS под управлением Mysql?На этом графике я обновил до db.m2.2xlarge с 34 ГБ доступной памяти в 03:30.Вы можете видеть переключение очень четко.Когда клиенты начинают подключаться и подключаться к этому экземпляру, объем свободной памяти резко падает до 5 ГБ, где он сейчас и завис.При моем предыдущем обновлении между размерами экземпляров БД я видел ту же схему, пока объем свободной памяти не уменьшился до чуть менее 1 ГБ и завис там бесконечно.

Что этот экземпляр делает с 03:30 до 07:30?Почему он не освобождает неиспользуемую память, когда она становится доступной?Полагаю, я ожидал бы, что этот график будет иметь форму волны, соответствующую моделям использования и трафика, а также форме экспоненциального затухания, что говорит о том, что это супер-ленивый и / или сломанный алгоритм сбора мусора.

Также обратите внимание, что около 2/3 операций с БД являются операциями записи, а 1/3 - операциями чтения, а около 2 ГБ памяти memcache перед БД.

Answer 1

MySQL поддерживает кэш недавно использованных таблиц, запросов и результатов в памяти, чтобы возвращать более быстрые результаты. Например, если вы запросите «select * from company, где id = 1» от клиента 1 миллион раз, только первый запрос должен быть отправлен на диск, следующие 999 999 поступят прямо из кэша оперативной памяти. У MySQL нет оснований для истечения срока действия этого кэша, пока он не узнает, что ему нужно больше памяти, поэтому он сохраняет данные до тех пор, пока ему не понадобится освободить ОЗУ для другой работы или более часто используемых результатов.

Я не претендую на звание эксперта - я понимаю, что оптимизация кэша запросов к БД - очень сложная и глубокая наука. Программисты в Oracle, Microsoft и других компаниях потратили годы и годы на разработку наилучшего способа управления пространством кеша, поэтому трудно предсказать со стороны.