|
|
|
|
|
|
by snom320
4181 days ago
|
|
|
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). |
|
|
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.