Guys We've splitted solving of this issue into two parts: 1) there is a review which fixes the fact that we do not have scheduler filters configured https://review.openstack.org/#/c/90106 2) all other improvements should be discussed in the blueprint https://blueprints.launchpad.net/fuel/+spec/scheduler-config-improvements
Thus, I am closing this thread. All other discussions regarding Fuel should be performed in openstack-dev ML with '[Fuel]' prefix in email subject. On Sun, Apr 6, 2014 at 12:38 AM, Andrey Korolev <[email protected]>wrote: > On Sun, Apr 6, 2014 at 12:24 AM, Roman Sokolkov <[email protected]> > wrote: > > > > Andrey, > > > > What i know: > > > > KVM not maps directly vRAM to physical.So VM will use just as much as it > > needs. > Yes, true for Linux VMs, false for Windows - they trying to allocate > all dedicated memory by writing zeros at the very beginning. Anyway, > on long-running periods even Linux VM will allocate all available RAM. > Then, even if host evict some RAM pages to swap, they will remain > in-RAM for guest OS causing long scheduler lockups on operations with > chunks placed to the swap by host. I propose, without any kind of > resource allocation/management in nova, simple approach, like ashes to > ashes, dust to dust - do NOT push VM` memory to the swap, instead add > large swap partition if necessary and introduce it to the VM. Do not > make any kind of memory overcommit, even with KSM in place, metrics > from KSM are very rough and not applicable even between two physical > hosts with same workload, KSM/UKSM behaviour is indeterministic. > > > Red Hat recommends to make swap partition with specific size to be > protected > > from out of memory cases. > > As I said before it will thrash VM` performance for sure. I am not > very familiar with RHEV resource allocation options, but for such > "zero-effort-to-make-it-useable" resource police as appeared in > current Nova, that`s BS recommendation. Can be true for very specific > and quiet workloads with low memory page eviction rate, but in common > it is not :). One can adjust oom_score and live with let-it-fail > approach for VMs, but for most users there is no point too. > > > > > (0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size > > > > I think it is reasonable solution, because most of the loads are far from > > 100%. But i agree in case if 100% load applications it's reasonable to > make > > it <=1. > > > > Thanks > > > > > > > > On Sat, Apr 5, 2014 at 12:42 AM, Andrey Korolev <[email protected]> > > wrote: > >> > >> Just a small question - how the hell memory overcommit can be higher > >> than 1? This will result in OOM and continuous weird behavior as soon > >> as enough number of VMs will be launched. > >> > >> On Sat, Apr 5, 2014 at 3:02 AM, Roman Sokolkov <[email protected]> > >> wrote: > >> > Just small update about overcommit ratios > >> > > >> > As recommended by Red Hat > >> > vCPU/CPU (cpu_allocation_ratio) = 5 (default 16) > >> > vRAM/RAM (ram_allocation_ratio) = 1.5 > >> > > >> > Thanks. > >> > > >> > > >> > > >> > On Fri, Apr 4, 2014 at 1:04 PM, Roman Sokolkov < > [email protected]> > >> > wrote: > >> >> > >> >> Folks, > >> >> > >> >> Any updates on that? > >> >> Customers that run Fuel for production exactly need finely tuned > >> >> scheduler. > >> >> My two latest projects were affected by default "RAW" scheduling. > >> >> > >> >> Thank you. > >> >> > >> >> > >> >> On Fri, Mar 21, 2014 at 7:18 AM, Bogdan Dobrelya > >> >> <[email protected]> > >> >> wrote: > >> >>> > >> >>> On 03/21/2014 03:04 PM, Dmitry Ukov wrote: > >> >>> > Core and Disk filters should be enabled (they are disabled by > >> >>> > default) > >> >>> > in order to avoid compute node oveloading > >> >>> > - cpu_allocation_ratio=1.0 - was customer requirement. I think > 16.0 > >> >>> > is > >> >>> > way to big over commit ratio (potentially 16 vms on 1 core). I > would > >> >>> > say > >> >>> > 2.0 or 3.0 will be reasonable here. > >> >>> > - disk_allocation_ratio=1.0 - it is unsafe to over commit disk > >> >>> > - ram_allocation_ratio=1.0 - this was customer requirement. > Actually > >> >>> > we > >> >>> > can use default value here. (AFAIR default is 1.5 ) > >> >>> > - ram_weight_multiplier=0.0 and scheduler_host_subset_size=30 will > >> >>> > help > >> >>> > us to get random VMs distribution if compute nodes significantly > >> >>> > differ > >> >>> > from each other in terms of total RAM amount > >> >>> > >> >>> Thank you, that makes sense. I vote for enable these ones (leaving > the > >> >>> ram_allocation_ratio defaults) for Fuel nova manifests for Puppet. > >> >>> That > >> >>> do you think? > >> >>> > >> >>> > > >> >>> > > >> >>> > > >> >>> > On Thu, Mar 20, 2014 at 2:58 PM, Bogdan Dobrelya > >> >>> > <[email protected] > >> >>> > <mailto:[email protected]>> wrote: > >> >>> > > >> >>> > On 03/20/2014 08:47 AM, Mike Scherbakov wrote: > >> >>> > > Hi Dmitry, > >> >>> > > I was running through bp created by > >> >>> > > you: > >> >>> > > >> >>> > > >> >>> > > https://blueprints.launchpad.net/fuel/+spec/scheduler-config-improvements. > >> >>> > > > >> >>> > > >> >>> > Interesting, why CPU overcommitment defaults ( > >> >>> > > >> >>> > > >> >>> > > https://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L1759 > >> >>> > ) are so 'bad' to being changed so drastically 16->1? > >> >>> > > >> >>> > > I'm wondering whether this config will work fine for every > >> >>> > installation > >> >>> > > we do with Fuel.. what are the possible limitations / corner > >> >>> > cases? > >> >>> > > > >> >>> > > Thanks, > >> >>> > > -- > >> >>> > > Mike Scherbakov > >> >>> > > #mihgen > >> >>> > > > >> >>> > > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Best regards, > >> >>> > Bogdan Dobrelya, > >> >>> > Skype #bogdando_at_yahoo.com <http://bogdando_at_yahoo.com> > >> >>> > Irc #bogdando > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Kind regards > >> >>> > Dmitry Ukov > >> >>> > IT Engineer > >> >>> > Mirantis, Inc. > >> >>> > > >> >>> > >> >>> > >> >>> -- > >> >>> Best regards, > >> >>> Bogdan Dobrelya, > >> >>> Skype #bogdando_at_yahoo.com > >> >>> Irc #bogdando > >> >>> > >> >>> -- > >> >>> Mailing list: https://launchpad.net/~fuel-dev > >> >>> Post to : [email protected] > >> >>> Unsubscribe : https://launchpad.net/~fuel-dev > >> >>> More help : https://help.launchpad.net/ListHelp > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Roman Sokolkov, > >> >> Deployment Engineer, > >> >> Mirantis, Inc. > >> >> Skype rsokolkov, > >> >> [email protected] > >> > > >> > > >> > > >> > > >> > -- > >> > Roman Sokolkov, > >> > Deployment Engineer, > >> > Mirantis, Inc. > >> > Skype rsokolkov, > >> > [email protected] > >> > > >> > -- > >> > Mailing list: https://launchpad.net/~fuel-dev > >> > Post to : [email protected] > >> > Unsubscribe : https://launchpad.net/~fuel-dev > >> > More help : https://help.launchpad.net/ListHelp > >> > > > > > > > > > > > -- > > Roman Sokolkov, > > Deployment Engineer, > > Mirantis, Inc. > > Skype rsokolkov, > > [email protected] > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru [email protected]
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
