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