GoodHosting
New Member
Hello VPSBoard,
<introrant> First I would like to start out by saying that by no means am I some expert in this field, while I have been providing hosting services for many years; there is still quite a lot of things I could learn. The things I often portray as "facts" in my speech, could all very well be fictitious information based on improper research or bad ideals; who knows. Hence I figured I would open up a thread, and ask what other aspiring / startup providers, as well as the industry leading providers had to say regarding these issues that are "pressing" to me. </introrant>
Test Service
I am currently offering trials on our Chicago1 and Phoenix1 locations for our Nebula Enterprise Cloud on packages Ci1 through Ci3 (therefore, no Windows OS; sorryabusers clients.)
URL: http://goodhosting.co/
Voucher Code: 40CNWJ36VQ
Valid For: Ci1, Ci2, Ci3 [Feb 01-Feb 08]
Period: FIRST MONTH 100% DISCOUNT
cgroup / KVM abuse troubles
I've recently had a steady increase of trouble (almost all of it coming from LowEndTalk) of Windows VPS clients purchasing the smallest possible plan, then abusing the absolute ever living hell out of the CPU they are assigned. Regardless of the intermediate layer or panel I use, 1 core = 1 core. Shares don't seem to mean anything, unless the host node is already over 100 us% CPU (ie: not usable for me, where I'd like to keep the host nodes with at least 30-50% free CPU of breathing room.) It doesn't seem to matter if the cpuset quota is set to 1 or 100000, or if the cpu_period is 1 or 10000 ; the Windows VPS guest is still able to use 100% of one core as a minimum, regardless of how low I try and set the limitations; which makes density of WIndows VPS literally impossible to me.
Surely other hosts have found some way to overcome this, so I figured I would open this thread in the hopes that someone might know.
Example config in cgroups:
<introrant> First I would like to start out by saying that by no means am I some expert in this field, while I have been providing hosting services for many years; there is still quite a lot of things I could learn. The things I often portray as "facts" in my speech, could all very well be fictitious information based on improper research or bad ideals; who knows. Hence I figured I would open up a thread, and ask what other aspiring / startup providers, as well as the industry leading providers had to say regarding these issues that are "pressing" to me. </introrant>
Test Service
I am currently offering trials on our Chicago1 and Phoenix1 locations for our Nebula Enterprise Cloud on packages Ci1 through Ci3 (therefore, no Windows OS; sorry
URL: http://goodhosting.co/
Voucher Code: 40CNWJ36VQ
Valid For: Ci1, Ci2, Ci3 [Feb 01-Feb 08]
Period: FIRST MONTH 100% DISCOUNT
cgroup / KVM abuse troubles
I've recently had a steady increase of trouble (almost all of it coming from LowEndTalk) of Windows VPS clients purchasing the smallest possible plan, then abusing the absolute ever living hell out of the CPU they are assigned. Regardless of the intermediate layer or panel I use, 1 core = 1 core. Shares don't seem to mean anything, unless the host node is already over 100 us% CPU (ie: not usable for me, where I'd like to keep the host nodes with at least 30-50% free CPU of breathing room.) It doesn't seem to matter if the cpuset quota is set to 1 or 100000, or if the cpu_period is 1 or 10000 ; the Windows VPS guest is still able to use 100% of one core as a minimum, regardless of how low I try and set the limitations; which makes density of WIndows VPS literally impossible to me.
Surely other hosts have found some way to overcome this, so I figured I would open this thread in the hopes that someone might know.
Example config in cgroups:
Code:
[[email protected] ~]# for FH in /cgroup/cpu/libvirt/qemu/one-5/vcpu0/*; do echo "----- $FH -----" ; cat $FH ; echo ; done
----- /cgroup/cpu/libvirt/qemu/one-5/vcpu0/cgroup.procs -----
16013
----- /cgroup/cpu/libvirt/qemu/one-5/vcpu0/cpu.cfs_period_us -----
100000
----- /cgroup/cpu/libvirt/qemu/one-5/vcpu0/cpu.cfs_quota_us -----
-1
----- /cgroup/cpu/libvirt/qemu/one-5/vcpu0/cpu.rt_period_us -----
1000000
----- /cgroup/cpu/libvirt/qemu/one-5/vcpu0/cpu.rt_runtime_us -----
0
----- /cgroup/cpu/libvirt/qemu/one-5/vcpu0/cpu.shares -----
1024