Debugging MySQL Memory Alerts: When innodb_buffer_pool_size Isn't the Whole Story
Posted on MySQL Ninjas | August 2026 Every DBA has been there. An alert fires. You SSH into the box, run free -h , and see MySQL consuming far more RAM than you configured. You double-check innodb_buffer_pool_size . It's set correctly. So where is the memory going? This is the story of debugging exactly that — on a Google Cloud c4d-standard-4 instance with 14.7 GB RAM, MySQL configured with a 7168 MB buffer pool, and mysqld RSS sitting at 10.4 GB . That's a 3.2 GB gap nobody could explain. The Setup We run a large MySQL fleet on GCP — over 200 DR replica nodes across three datacenters. As part of a buffer pool tuning project (fitting the right pool size to the right machine class), we set innodb_buffer_pool_size = 7168 MB on our c4d-standard-4 nodes (16 GB RAM, 14.7 GB usable). Shortly after, memory alerts started firing. When I looked at what was actually happening: $ ps aux | grep mysqld | awk '{print $6/1024 " MB"}' 10490 MB ...


Looks good! (Though I'm not very knowledgeable about Nginx and Lua).
ReplyDeleteIt's worth noting that in a Raft setup, even if you do happen to make a request to a non-leader node, the node you communicate with will forward the request to the leader. This works when the node you communicate with can _see_ the leader. It's best to communicate to the leader directly.
Thanks much for the clarification! Please keep guiding us.
DeleteIt is so nice blog. I was really satisfied by seeing this blog.
ReplyDeleteWorkday Integration Course India
Workday Online Integration Course Hyderabad