New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Yep, looks like 32 is best for OVZ
But did you use real info?
Lmao
Nope :P
:O
Uncle doesnt know me yet.
We are working through limited companies
How about that for a paranoia ! Do I win the prize for the most paranoic person here or not ?
The wooden brain I think...
I think almost on par with @William with the paranoia
At least you are not heavily armed as he is...
WHERE DA AMMO AT? (cycles shotgun)
Hum... How do you know that ? I am already scared....
You hate cars, i doubt you love weapons ;-) Besides i don't think the arm sale / ownership in Romania is very liberal, as it is in Austria.
And don't be afraid, i am not that scary ;-) I just look like that ;-)
VSwap is fun
All new orders are being put on our CentOS 6 node and in 6 days we'll begin upgrading all of our CentOS 5 nodes to CentOS 6.
We've been using VSwap all along.
@concerto49 how old is your oldest server with vSwap enabled for clients?
We've also been using vSwap all along with no ill effects.
17:18:14 up 136 days, 3:28, 0 users, load average: 0.25, 0.17, 0.11
17:18:15 up 109 days, 7:04, 0 users, load average: 0.00, 0.00, 0.00
17:18:15 up 136 days, 3:28, 0 users, load average: 0.00, 0.00, 0.00
17:18:14 up 109 days, 7:04, 0 users, load average: 0.29, 0.25, 0.20
17:19:34 up 136 days, 3:29, 0 users, load average: 0.00, 0.00, 0.00
17:19:34 up 136 days, 3:29, 0 users, load average: 0.08, 0.09, 0.08 17:19:35 up 136 days, 3:29, 0 users, load average: 0.18, 0.18, 0.17
The oldest server is a few months old. Never crashed/rebooted. However, we started off with rounds of testing/trials with users and rebooted to tweak things.
Current uptime is 27 days since we officially sold anything.
We are a new host. Nothing to hide. Been said in a few posts.
@concerto49 that's mainly what I'm getting at, claiming you've always had it, doesn't mean a whole lot when you're a new startup that is taking advantage of this after the fact. Older hosts who already have a good number of nodes set up will of course probably need to transition over the next few months once it's been determined that the transition will benefit them.
Sorry if you've misunderstood anything. If you read the comments here, a lot of new hosts have said they had it. I never claimed to have had it for years just to be clear.
@concerto49 for some reason I thought you had already mentioned it once or twice before the comment I referenced as such seemed almost like poking at the others in the thread.
@John_R In a nutshell: New providers are obviously already using it, as CentOS6 is the way to go if you're starting fresh with SolusVM+OpenVz etc, Existing providers with a client base already will likely only provide it on new servers, and will probably not migrate existing servers unless there's a complaint or transfer request.
No, was my first post here. I saw the long thread when I first checked LET today.
OpenVZ's RHEL6 kernels were released into the stable branch well before the uptime of your servers and those kernels definitely weren't stable until a few months later.
35.1 was the first "stable" kernel (August 2011), but it wasn't useable until 55.10 (May 2012).
over 200 days OpenVZ node uptime on 053.5 ... with vSwap.
@jarland all you are doing is faking free to think there's less ram used. That fakeswap simply takes meminfo at the time you run it and makes it a static file with fake swap. It's not effecting memory usage. It's just making free -m use fake statistics.
@dmmcintyre3 My understanding is that this output effects how some applications load themselves into memory. I understand that it isn't a fix, but it does alter memory usage displayed from more than the free command. To me it's most noticeable when launching unity, because I will actually see fluctuations in the memory used, but it's still 1/4 of what it is otherwise. So it's not faking every value or surely it would be static.
Again, not to be seen as a fix, but meant to make note of the difference of the mere illusion of the availability of swap. Which is understandable, systems are supposed to have swap. Not having it is the strange situation.
Have been using vSwap since January. The restart was applied to add additional hardware to those nodes, which is why they have similar uptimes
Uh-oh. Our 150+ day uptime node (with vSwap) just went offline, due to a kernel panic.
Seems like the disk partitions are damaged, luckily it wasn't caused by OpenVZ kernel being unstable (however this problem is worse).