+1
SSD might help, but only might.
If you think about the underlying machines they are limited on the
dimensions of CPU, RAM, and disk. If the provider uses SSD that would
generally improve the disk performance but if that means they then cram
more customers onto the box because they have more IOPs to share you
might then bump into the limits of shared CPU.
The virtualisation tech may be correlated to overselling but isn't the
root cause. You can get horribly oversold Xen/KVM same as you can get
horribly oversold OpenVZ. It comes down to price:performance and
provider's desired profit margin.
In my conversations with VPS providers I generally ask what hardware
they're running, and ask if it's reasonable to expect X level of
performance from the service. i.e. I specifically ask if they monitor IO
latency, and how much they oversell the CPUs if the VPS does not come
with dedicated cores. Having these pre-sales conversations also gives
you a good opportunity to evaluate the provider's competence & attitude
to customer service.
On 10/04/2014 11:16 PM, Rick Dunn wrote:
Wow that's some pretty ridiculous I/O lag. It's pretty obvious the VPS you
have isn't intended for anything I/O intensive (or has too much I/O
intensive stuff on it already). I'd recommend moving to a VPS provider
that has fully virtualized containers rather than the para-virtualized ones
you have now. Most places advertise these as "cloud" VPS servers, and most
providers of them that I've seen have much better I/O times from higher
performance SANs.
On Thu, Apr 10, 2014 at 8:37 AM, pilger <pilger...@gmail.com> wrote:
Did a ioping instead. I believe it does the trick of measuring.
Here's what I got:
*4.0 kb from . (ext4 /dev/ploop48624p1): request=1 time=283 us4.0 kb from
. (ext4 /dev/ploop48624p1): request=2 time=540 us 4.0 kb from . (ext4
/dev/ploop48624p1): request=3 time=421 us4.0 kb from . (ext4
/dev/ploop48624p1): request=4 time=429 us4.0 kb from . (ext4
/dev/ploop48624p1): request=5 time=7.5 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=6 time=30.7 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=7 time=483 us4.0 kb from . (ext4
/dev/ploop48624p1): request=8 time=619 us4.0 kb from . (ext4
/dev/ploop48624p1): request=9 time=47.2 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=10 time=13.8 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=11 time=12.7 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=12 time=519 us4.0 kb from . (ext4
/dev/ploop48624p1): request=13 time=456 us4.0 kb from . (ext4
/dev/ploop48624p1): request=14 time=327 us 4.0 kb from . (ext4
/dev/ploop48624p1): request=15 time=17.8 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=16 time=37.4 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=17 time=178.2 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=18 time=288 us 4.0 kb from . (ext4
/dev/ploop48624p1): request=19 time=20.9 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=20 time=1.1 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=21 time=41.9 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=22 time=32.7 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=23 time=20.2 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=24 time=12.9 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=25 time=123.6 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=26 time=36.4 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=27 time=38.3 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=28 time=670 us4.0 kb from . (ext4
/dev/ploop48624p1): request=29 time=55.7 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=30 time=19.1 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=31 time=220 us4.0 kb from . (ext4
/dev/ploop48624p1): request=32 time=43.1 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=33 time=33.2 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=34 time=31.0 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=35 time=58.7 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=36 time=577 us4.0 kb from . (ext4
/dev/ploop48624p1): request=37 time=26.6 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=38 time=586.4 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=39 time=41.4 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=40 time=17.5 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=41 time=254 us4.0 kb from . (ext4
/dev/ploop48624p1): request=42 time=102.0 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=43 time=212.3 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=44 time=33.6 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=45 time=434.5 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=46 time=360.5 ms 4.0 kb from . (ext4
/dev/ploop48624p1): request=47 time=40.4 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=48 time=132.2 ms4.0 kb from . (ext4
/dev/ploop48624p1): request=49 time=141.2 ms^[4.0 kb from . (ext4
/dev/ploop48624p1): request=50 time=26.9 ms ^C--- . (ext4
/dev/ploop48624p1) ioping statistics ---50 requests completed in 52.1 s,
16
iops, 65.0 kb/smin/avg/max/mdev = 220 us / 61.5 ms / 586.4 ms / 113.3 ms*
A couple of them were way above 15ms. I still couldn't link a stutter to
I/O lag yet. With that I mean that I didn't experience a "hiccup" while
noticing the I/O increase at the same time. I tried disabling replays and
logs yesterday but it hat little effect since the system was behaving
better than usual. Looks like it depends on the neighbours noise, indeed.
Is that a solid evidence to go to the host and ask to move or get an SSD!?
And, repeating myself a bit, would SSD help!?
Thanks guys!
_pilger
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
