Memory leak solved—finally!
If you use the beta app at all, you’ve probably noticed very serious slowness and downtime. It hasn’t been fun. However, after weeks of investigating, we’ve finally managed to iron out the memory leak and things are good to go :)
What that means to you is that the beta version of Dress to Impress, where all the latest features go (including outfit saving), is now up and running, and we don’t foresee any downtime. It also means that, now that things over there are stable, we can go back to an intense focus on building up new, awesome features, and can be confident in soon bringing it out of beta. Woot!
So, that’s your DTI news for the day. The beta app is happy, and you should be, too. If you’re one of those technical folks who’s interested in what caused the issues, however, read on.
What we were dealing with was a “memory leak.” Here, when we talk about memory, we mean RAM, which is where computer programs store things that they expect to use in the near future, rather than having to read that information off of the hard drive. For instance, an essay you wrote a year ago can sit on your hard drive for years, but will only be loaded into RAM when you open it up.
However, what would happen if, after you closed the Word document, it stayed in RAM rather than being cleared out? You only have a limited amount of RAM, so, if it never got cleared out, you would eventually run out of that memory space, forcing the computer to fall back on the hard drive for memory, making things run very, very slowly. This is a “memory leak,” and it’s what was plaguing the Dress to Impress beta app. Every time someone loaded a web page, DTI allocated a bit of RAM (that’s okay; it needs space to work), but wouldn’t always free up that space when it was done. So, as more and more requests came in, it didn’t take long for the application to push the server’s RAM limits, requiring the app to be restarted on a regular basis.
So, what exactly was causing the leak?…well, that’s the odd bit. We’re not totally certain what was wrong, but we do know what fixed it. We found a leak in the rails_warden plugin we were using for authentication, so moved to the Devise authentication framework, instead. That fixed the leak when running personal copies of Dress to Impress for testing, but, when we pushed those changes to the server, the leak persisted.
Eventually, we noticed that our Rubygems on the server weren’t up to date. (Dress to Impress is written in the Ruby programming language, and a “gem” is the standard way of sharing large pieces of code for others to use. We use a lot of gems.) We had assumed that the development environment (personal computer) and production environment (the server) were pretty much identical, but not so: many gems had been updated since we first uploaded Dress to Impress Beta to the server, and we hadn’t downloaded those updates yet.
So, we updated the gems, and everything was good to go. Our best guess right now is that there was a bug in how the rack-fiber_pool gem interacted with the Thin web server, but, ultimately, it doesn’t matter. What matters is that someone in the magical world of open-source found the bug we happened to be dealing with, they fixed it, we downloaded the changes, and now everything’s good to go. I love the open-source community :)
So, that’s that. Memory leak gone. Thanks for reading! (And, hey! If you understood a lot of this, maybe you’d be interested in working on Dress to Impress, too. Drop me a line at webmaster % openneo ! net. Thanks!)
