Tuesday, April 2, 2019

High Memory Use With Vapor and MySQL

Tanner (via Ilja A. Iwas):

MySQL 3.2.4 has been tagged with a fix that reduces peak memory usage by 10-15x for the sample project. See vapor/mysql#232 if you’re interested to see what was fixed.


Here’s a small recap of what went wrong, and also why it took so long to find it. The main blocker was that we initially thought this was a Linux-only memory leak[…]


The problem was not leaking memory, but overly high peak memory usage which lead to fragmentation. Which, importantly, we were also seeing on macOS. This meant it was highly likely the problem was in Vapor.


Due to optimizations in Swift’s String, Valgrind may think bytes have been “definitely lost” even though they haven’t. This seems to only happen when you stop Valgrind while it is still busy doing work.


To help prevent issues like this from happening in the future, we need to improve Vapor’s DB driver performance benchmarking. Currently, benchmarks are for small, unrealistic models and test run time only. Benchmarks that could have caught this issue early would test realistically sized models (with diverse properties and types) and also memory usage alongside run time. Implementing these benchmarks is unfortunately much easier said than done, but it’s something that has been on our list long before this issue.

2 Comments RSS · Twitter

Isn't MySQL at 8.x these days?

@bob: In this case, v 3.2.4 is the version number of Vapor's MySQL driver. Naming should be improved to avoid confusion.

Leave a Comment