The Guts 'n' Glory of Database Internals: The Curse of Old Age
As databases age, there are a number of problems to look out for ranging from memory links to fragmentation. This article tells you what to keep an eye out for.
Join the DZone community and get the full member experience.Join For Free
This is a fun series to write, but I'm running out of topics where I can speak about the details at a high level without getting into nitty gritty details that will make no sense to anyone but database geeks. If you have any suggestions for additional topics, I would love to hear about them.
This post, however, is about another aspect of running a database engine. It is all about knowing what is actually going on in the system. A typical web application has very little state (maybe some caches, but that is pretty much about it) and can be fairly easily restarted if you run into some issue (memory leak, fragmentation, etc) to recover from most problems while you investigate exactly what is going on. A surprising number of production systems actually have this feature that they just restart on a regular basis, for example. IIS will restart a web application every 29 hours, and I have seen production deployment of serious software where the team was just unaware of that. It did manage to reduce a lot of the complexity because the application never got around to live long enough to actually carry around that much garbage.
A database tends to be different. A database engine lives for a very long time, typically weeks, months, or years, and it is pretty bad when it goes down — it isn't a single node in the farm that is temporarily missing or slow while it is filling the cache, this is the entire system being down without anything that you can do about it (note, I'm talking about single node systems here, distributed systems have high-availability systems that I'm ignoring at the moment). That tends to give you a very different perspective on how you work.
For example, if you are using are using Cassandra, it had (at least used to have) an issue with memory fragmentation over time. It would still have a lot of available memory, but certain access patterns would chop that off into smaller and smaller slices until just managing the memory at the JVM level caused issues. In practice, this can cause very long GC pauses (multiple minutes). And before you think that this is a situation unique to managed databases, Redis is known to suffer from fragmentation as well, which can lead to higher memory usage (and even kill the process, eventually) for pretty much the same reason.
Databases can't really afford to use common allocation patterns (so no malloc/free or the equivalent) because they tend to hold onto memory for a lot longer, and their memory consumption is almost always dictated by the client. In other words, saving increasingly large records will likely cause memory fragmentation, which I can then utilize further by doing another round of memory allocations, slightly larger than the round before (forcing even more fragmentation, etc). Most databases use dedicated allocators (typically some form of arena allocators) with limits that allow them to have better control of that and mitigate that issue. (For example, by blowing the entire arena on failure and allocating a new one, which doesn't have any fragmentation).
But you actually need to build this kind of thing directly into the engine, and you need to also account for that. When you have a customer calling with "why is the memory usage going up?" you need to have some way to inspect this and figure out what to do about that. Note that we aren't talking about memory leaks, we are talking about when everything works properly, just not in the ideal manner.
Memory is just one aspect of that — if one that is easy to look at. Another thing that you need to watch for is anything that has a linear cost proportional to your runtime. For example, if you have a large LRU cache, you need to make sure that after a couple of months of running, pruning that cache isn't going to be an O(N) job running every finding minutes, never finding anything to prune, but costing a lot of CPU time. The number of file handles is also a good indication of a problem in some cases. Some databases engines have a lot of files open (typically LSM ones), and they can accumulate over time until the server is running out of those.
Part of the job of the database engine is to consider not only what is going on now, but how to deal with (sometimes literally) abusive clients that try to do very strange things, and how to manage to handle them. In one particular case, a customer was using a feature that was designed to have a maximum of a few dozen entries in a particular query to pass 70,000+ entries. The amazing thing that this worked, but as you can imagine, all sorts of assumptions internal to that feature were very viciously violated, requiring us to consider having a hard limit on this feature so it is within its design specs or trying to see if we could redesign the entire thing so it could handle this kind of load.
And the most "fun" is when those sorts of bugs are only present after a couple of weeks of harsh production systems running. So even when you know what is causing the issue, actually reproducing the scenario (you need memory fragmented in a certain way, a certain number of cache entries, and the application requesting a certain load factor) can be incredibly hard.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.