3.1.4.2 Configuring Huge Pages
You can configure a virtual machine for high performance, so that it runs with performance
metrics as close to bare metal as possible. When you choose high performance optimization,
the virtual machine is configured with a set of automatic and recommended manual settings
for maximum efficiency. By using huge pages, you increase the page size which reduces the
page table, reduces the pressure on the Translation Lookaside Buffer cache, and improves
performance.
Huge pages are pre-allocated when a virtual machine starts to run (dynamic allocation is
disabled by default).
**** Are Virtual machines mentioned here with high performance option ? So they turn off
transparent huge pages by default and use traditional huge pages instead ??
**** Most normal virtual machines use large transparent pages by default in their
operating systems.
Note
If you configure huge pages for a virtual machine, you cannot hotplug or hot uplug
memory.
To configure huge pages:
1. In the Custom Properties tab, select hugepages from the custom properties list, which
displays Please select a key… by default.
2. Enter the huge page size in KB.
You should set the huge page size to the largest size supported by the pinned host. The
recommended size for x86_64 is 1 GB.
The huge page size has the following requirements:
* The virtual machine’s huge page size must be the same size as the pinned host’s huge
page size.
* The virtual machine’s memory size must fit into the selected size of the pinned host’s
free huge pages.
* The NUMA node size must be a multiple of the huge page’s selected size.
To enable dynamic allocation of huge pages:
1. Disable the HugePages filter in the scheduler.
2. In the [performance] section in /etc/vdsm/vdsm.conf set the following:
use_dynamic_hugepages = true
**** what kind of hugepage it is ? Tradition Hugepages or Transparent Hugepages ? And
it is archived by VDSM ??
**** I’m really get confused.
From: Strahil Nikolov <hunter86_bg(a)yahoo.com>
Sent: Thursday, September 30, 2021 11:35 PM
To: Tommy Sway <sz_cuitao(a)163.com>; 'users' <users(a)ovirt.org>
Subject: Re: [ovirt-users]Re: 回复: Re: About the vm memory limit
Each VM for that 4TB host will be a single process. When that process addresses some
memory location, the kernel will lookup in the translation lookaside buffer (TLB) and in
case the Host is using Hugepages the kernel needs less time to find the memory page (page
table walk), which slows the process (in your case the VM).
Simplified said -> the VM process should be seen as an Oracle DB. On bare metal you
want to disable transparent hugepages and enable the 2M hugepages for ODB - so logically
VMs doing the same workload should be treated the same way.
Here is a link to Oracle's OLVM (based on oVirt):
https://docs.oracle.com/en/virtualization/oracle-linux-virtualization-man...
Best Regards,
Strahil Nikolov
On Thu, Sep 30, 2021 at 6:25, Tommy Sway
<sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> > wrote:
In my scenario, the physical machine has a lot of memory (4TB), with dozens of virtual
machines running on it, each vm is running a database, and every vm is set up with
traditional large-page memory.
In this case, whether it is necessary to set up large page memory on the physical machine
and what type of large page memory should be set up, this issue has not been determined, I
am also very confused.
-----Original Message-----
From: users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org>
<users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org> > On Behalf Of
Strahil Nikolov via Users
Sent: Wednesday, September 29, 2021 8:50 PM
To: 'users' <users(a)ovirt.org <mailto:users@ovirt.org> >; Tommy Sway
<sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> >
Subject: [ovirt-users]Re: 回复: Re: About the vm memory limit
I got a 3 TB host (physical) with Oracle without Traditional Hugepages. The DB will work
even without hugepages... but how much memory will be lost - that's another story.
Disable the transparent Huge Pages and check this documentation - should be valid for
oVirt 4.3 and OLVM 4.3 as they share the same source:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/...
Best Regards,
Strahil Nikolov
В сряда, 29 септември 2021 г., 15:20:54 ч. Гринуич+3, Tommy Sway <sz_cuitao(a)163.com
<mailto:sz_cuitao@163.com> > написа:
I’am 4.3, but the memory of the VM and the SGA is large , 32GB, so the vm should set the
traditional hugepage for the database SGA.
I don't know how to set up a large page on a KVM host.
Because if I make it a traditional big page, how big should I make it? Will non-VM SGA
usage of many VMs be affected?
After all, not all memory used by QEMU needs to be HugePage, and traditional large page
memory needs to be used by specific code calls and is not transparent.
These are all questions.
From: users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org>
<users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org> > On Behalf Of
Strahil Nikolov via Users
Sent: Wednesday, September 29, 2021 5:39 PM
To: Tommy Sway <sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> >;
'users' <users(a)ovirt.org <mailto:users@ovirt.org> >
Subject: [ovirt-users]Re: 回复: Re: About the vm memory limit
If you are on 4.3 -> disable transparent hugepages both Hypervisor and VM.
If you are using 4.4 -> disable transparent hugepages and also cobfigure regular huge
pages.
Best Regards,
Strahil Nikolov
On Wed, Sep 29, 2021 at 5:34, Tommy Sway <sz_cuitao(a)163.com
<mailto:sz_cuitao@163.com> > wrote:
From the Oracle OLVM support:
Configuring the Hugepages for guest VMs should be suffice, however, it needs the KVM
hosts too configured with the Hugepages.
Since, if it not you may end with issues while staring the guest VMs.
I really don't know what to do now.
-----Original Message-----
From: users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org>
<users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org> > On Behalf Of
Strahil Nikolov via Users
Sent: Tuesday, September 28, 2021 3:39 PM
To: 'users' <users(a)ovirt.org <mailto:users@ovirt.org> >; Tommy Sway
<sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> >
Subject: [ovirt-users]Re: 回复: Re: About the vm memory limit
I think that if you run VMs with Databases, you must disable transparent huge pages on
Hypervisour level and on VM level. Yet, if you wish you can use regular huge pages on VM
level.
Best Regards,
Strahil Nikolov
В вторник, 28 септември 2021 г., 09:21:09 ч. Гринуич+3, Tommy Sway <sz_cuitao(a)163.com
<mailto:sz_cuitao@163.com> > написа:
What problem will appear if I use the default transparent huge page enabled mode for
physical hosts, but configure traditional huge page memory on the virtual machine for
database SGA ?
Or is it better to disable transparent huge page on physical machines and still use
traditional huge page memory on virtual machines?
Which one is prefer ?
From: users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org>
<users-bounces(a)ovirt.org <mailto:users-bounces@ovirt.org> > On Behalf Of
Strahil Nikolov via Users
Sent: Tuesday, September 28, 2021 12:05 AM
To: tommy <sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> >; 'users'
<users(a)ovirt.org <mailto:users@ovirt.org> >
Subject: [ovirt-users]Re: 回复: Re: About the vm memory limit
https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/di
sabling-transparent-hugepages.html
https://access.redhat.com/solutions/1320153
<
https://access.redhat.com/solutions/1320153%20> (requires RH dev
subscription or other type of subscription) -> In short add
'transparent_hugepage=never' to the kernel params
SLES11/12/15 ->
https://www.suse.com/c/sles-1112-os-tuning-optimisation-guide-part-1/
Best Regards,
Strahil Nikolov
> On Mon, Sep 27, 2021 at 16:33, tommy <sz_cuitao(a)163.com
<mailto:sz_cuitao@163.com> > wrote:
> thank you!
>
> and how to get the config info of Transparent huge pages and how to
> disable it?
>
>
>
>
>
> 发自我的华为手机
>
>
> -------- 原始邮件 --------
> 发件人: Strahil Nikolov <hunter86_bg(a)yahoo.com <mailto:hunter86_bg@yahoo.com>
>
> 日期: 2021年9月27日周一 21:13
> 收件人: 'users' <users(a)ovirt.org <mailto:users@ovirt.org> >, Tommy
Sway <sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> >
> 主 题: Re: [ovirt-users] Re: About the vm memory limit>> Transparent
> huge pages are enabled by default, so you need to stop >> them.I
> would use huge pages on both host and VM, but theoretically it >>
> shouldn't be a problem running a VM with enabled HugePages without >>
> configuring on Host.Best Regards,Strahil NikolovВ събота, 25 >>
> септември 2021 г., 15:25:10 ч. Гринуич+3, Tommy Sway >>
> <sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> > написа: transparent huge
pages are not used on vm
> >> and physical host. But, can I enable hugepage memory on virtual
> >> machines but not on a physical machine?For database running on vm,
> >> and it needs to config hugepage. From: Strahil Nikolov >>
> <hunter86_bg(a)yahoo.com <mailto:hunter86_bg@yahoo.com> > Sent: Saturday,
September 25, 2021 5:32 PMTo:
> >> Tommy Sway <sz_cuitao(a)163.com <mailto:sz_cuitao@163.com>
>Subject: Re: [ovirt-users] About the
> vm >> memory limit It depends on the numa configuration of the host.
> If you >> have 256G per CPU, it's best to stay into that range. Also,
> consider >> disabling transparent huge pages on the host & VM. Since
> 4.4 Regular >> Huge Pages (do not confuse them with THP) can be used
> on the >> Hypervisors, while on 4.3 there were some issues but I
> can't provode >> any details. Best Regards,Strahil Nikolov> On Fri,
> Sep 24, 2021 at >> 6:40, Tommy Sway> <sz_cuitao(a)163.com
<mailto:sz_cuitao@163.com> > wrote:> I
> would like to ask if >> there is any limit on the memory size of
> virtual machines, or >> performance curve or something like that?> As
> long as there is memory >> on the physical machine, the more virtual
> machines the better?> > In >> our usage scenario, there are many
> virtual machines with databases, >> and their memory varies greatly.
> > For some virtual machines, 4G >> memory is enough, while for some
> virtual machines, 64GB memory is >> needed.> > I want to know what
> is the best use of memory for a >> virtual machine, since the virtual
> machine is just a QEMU emulation >> process on a physical machine,
> and I worry that it is not using as >> much memory as a physical
> machine. Understand this so that we can >> develop guidelines for
> optimal memory usage scenarios for virtual >> machines.> > Thank
> you!> > > >> _______________________________________________Users
> mailing list -- >> users(a)ovirt.orgTo <mailto:users@ovirt.orgTo>
unsubscribe send an email to >>
> users-leave(a)ovirt.orgPrivacy <mailto:users-leave@ovirt.orgPrivacy> Statement:
>>
>
https://www.ovirt.org/privacy-policy.htmloVirt
<
https://www.ovirt.org/privacy-policy.htmloVirt%20> Code of Conduct: >>
>
https://www.ovirt.org/community/about/community-guidelines/List
<
https://www.ovirt.org/community/about/community-guidelines/List%20> >>
> Archives: >>
>
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y6XDOIM
> >>
> KCP4JEJF7M5DLJ33U2ENJKGAN/___________________________________________
> >> ____Users mailing list -- users(a)ovirt.orgTo <mailto:users@ovirt.orgTo>
unsubscribe send an
> email >> to users-leave(a)ovirt.orgPrivacy
<mailto:users-leave@ovirt.orgPrivacy> Statement: >>
>
https://www.ovirt.org/privacy-policy.htmloVirt
<
https://www.ovirt.org/privacy-policy.htmloVirt%20> Code of Conduct: >>
>
https://www.ovirt.org/community/about/community-guidelines/List
<
https://www.ovirt.org/community/about/community-guidelines/List%20> >>
> Archives: >>
>
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3YHTUBA
> >>
> G42YRNEUCWG4DF5TEP2I22DMH/___________________________________________
> ____Users mailing list -- users(a)ovirt.orgTo <mailto:users@ovirt.orgTo>
unsubscribe send an email
> to users-leave(a)ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement:
>
https://www.ovirt.org/privacy-policy.htmloVirt
<
https://www.ovirt.org/privacy-policy.htmloVirt%20> Code of Conduct:
>
https://www.ovirt.org/community/about/community-guidelines/List
<
https://www.ovirt.org/community/about/community-guidelines/List%20>
> Archives:
>
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GRNMITH
> SDUEUB2JL2HM522ZGBTF4OPIC/
_______________________________________________Users mailing list -- users(a)ovirt.orgTo
<mailto:users@ovirt.orgTo> unsubscribe send an email to
users-leave(a)ovirt.orgPrivacy <mailto:users-leave@ovirt.orgPrivacy> Statement:
https://www.ovirt.org/privacy-policy.htmloVirt
<
https://www.ovirt.org/privacy-policy.htmloVirt%20> Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/List
<
https://www.ovirt.org/community/about/community-guidelines/List%20> Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QBQHER4G
2VLM6IVZ45XUZNV6AUEE4AR5/
_______________________________________________
Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-leave(a)ovirt.org <mailto:users-leave@ovirt.org>
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XZ7PQ6ZHZP5...
_______________________________________________
Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-leave(a)ovirt.org <mailto:users-leave@ovirt.org>
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5OWROWEV32Q...