Comment by SwellJoe | Hacker News Reader

Comment by SwellJoe | Hacker News Reader

Parent Full thread

I would recommend anything other than Virtuozzo/OpenVZ, because of broken memory allocation. Virtuozzo allows hosts to oversell RAM, without properly handling over-allocation. So, memory allocations fail while reporting available memory, making it difficult to troubleshoot, and difficult for users to predict what their VM can accommodate.

If intermittent failures without useful error messages is the worst kind of failure (and it is, IMHO), then Virtuozzo intentionally subjects its users to the worst kind of failure. Unless you know how to spot this kind of problem, it's easy to bang your head on it for days or weeks; and we've had users who were ecstatic when we diagnose their problem and provide the knowledge they need to spot it in the future (though resolving it may be more tricky than diagnosing it). Even without the host intentionally overselling, we've seen this behavior happen, because allocation seems to require contiguous blocks of memory (or something else that means that even with enough available memory allocations can fail).

I am not deeply familiar with the code, only with spotting this problem in the wild. I've seen assertions, spanning years (including from Parallels), that it's been fixed, or that as long as the host isn't overselling RAM it won't happen. But, we still get these support requests regularly. I'm not an expert on their software, but I'm an expert on spotting when it's their software that is causing our customer's despair. (Note that the support requests are usually about Postfix, Apache, MySQL or other services "crashing"; it rarely manifests with our software specifically, since our software rarely needs to allocate large amounts of memory.)

If you happen to be stuck on a Virtuozzo or OpenVZ system, and have mysterious failures of services, you can find out of it is this problem by checking /proc/bc/* or /proc/user_beancounters.

I don't really get what your problem is? You can disable the memory limitations if your use case requires it, or set the limits as high as you want.

How else would you suggest that OpenVZ should handle over-allocation? It is, after all, one of the points of virtualization (and the reason why you can get such containers for cheap).

You can't really blame OpenVZ if the users or sysadmins are unaware that the container has hard limits and that you're able to see if you've run into them using /proc/user_beancounters. Of course, if OpenVZ fails to allocate memory when you're under the limit, that's a separate problem that should be adressed (although I've yet to run into that one).

But also to be fair, OpenVZ introduced VSwap (http://wiki.openvz.org/VSwap) to address some of the confusion that occurred under the previous resource management solution. User bean counters was notoriously hard to comprehend for mere mortals, and the default limits were reasonably tight, so most commonly Java based applications were unreliable in OpenVZ.

Otherwise I agree with you that admins should detect VZ-related OOM conditions. But a good project takes ownership over the most common pitfalls and finds ways of making their software easier to use (if their goal is to remain popular or grow).

"I don't really get what your problem is?"

It isn't my problem, it is Parallels problem, and the problem of their customers. Though, it becomes my problem when our customers come to us for help due to Parallels failure.

You say it is working as designed, I say that design is broken. Those are not mutually exclusive assertions.

"You can't really blame OpenVZ if the users or sysadmins are unaware that the container has hard limits and that you're able to see if you've run into them using /proc/user_beancounters."

It is not the "hard" limit that is the problem...it is the "soft limit" which is arbitrary and can be unallocate-able, with the user having no way to know that it will be unallocate-able until it causes a service to exit. So-called "burst" RAM in VZ containers would better be called Schrödinger's RAM, and it has no place in a server.

Further, it doesn't even seem to exclusively be a problem of "burst" RAM. We've had support requests show up on systems that had, say, 1 GB of "guaranteed" RAM and 2 GB of "burst" RAM, but still behave as though it has significantly less than 1 GB of allocate-able RAM. I've addressed that in my comment above, but I didn't give an example. Perhaps this is more clear?

Regardless, the behavior of VZ containers even when they are working as designed is so user-hostile that I just can't recommend it. Our products support OpenVZ containers, because we had a number of customers tied to the platform from before their were better alternatives, but I've never been fond of them.

If it works for you, and you don't share your system with anyone else, go ahead and do what makes you happy. But, from my perspective, as someone supporting probably more web hosting server users than anyone else I know (except maybe some friends who work at large hosting providers and a friend who works at our largest direct competitor), I know that VZ containers cause a lot of confusion.

Reply on news.ycombinator.com