Re: [ovirt-users] Question about Huge Pages

[Michal Skrivanek]

> On 20 Apr 2017, at 17:39, Gianluca Cecchi  wrote:
> 
> On Thu, Apr 20, 2017 at 10:35 AM, Michal Skrivanek  > wrote:
> 
>> On 19 Apr 2017, at 16:28, Gianluca Cecchi > > wrote:
>> 
>> On Wed, Apr 19, 2017 at 3:44 PM, Martin Polednik > > wrote:
>> 
>> 
>> If you are using recent CentOS (or I guess Fedora), there isn't any
>> extra setup required. Just create the custom property:
>> 
>> Both my engine and my hosts are CentOS 7.3 + updates
> 
> that’s good
> 
>>  
>> 
>> On the host where engine is running:
>> 
>> $ engine-config -s "UserDefinedVMProperties=hugepages=^.*$"
>> $ service ovirt-engine restart
>> 
>> and you should see 'hugepages' when editing a VM under custom properties.
>> 
>> So no vdsm hook at all to install?
> 
> today you still need the hook.
> 
>> 
>>  
>> Set the number to (desired memory / 2048) and you're good to go. The
>> VM will run with it's memory backed by hugepages.
>> 
>> As in sysctl.conf? So that if I want 4Gb of Huge Pages I have to set 2048?
> 
> yes. there might be some 
> 
>> 
>>  
>> If you need
>> hugepages even inside the VM, do whatever you would do on a physical
>> host.
>> 
>> mpolednik
>> 
>> 
>> yes, the main subject is to have Huge Pages inside the guest, so that Oracle 
>> RDBMS at startup detect them and use them
> 
> yes, so if you do that via sysctl.conf on real HW just do the same here, or 
> modify kernel cmdline.
> 
> Note that those are two separate things
> the hook is making QEMU process use hugepages memory in the host - that 
> improves performance of any VM
> then how it looks in guest is no concern to oVirt, it’s guest-side hugepages. 
> You can enable/set them regardless the previous step, which may be fine if 
> you just want to expose the capability to some app  - e.g. in testing that 
> the guest-side Oracle can work with hugepages in the guest.
> But you probably want both Oracle to see hugepages and also actually use them 
> - then you need both reserve that on host for qemu process and then inside 
> guest reserve that for oracle. I.e. you need to add a “buffer” on host side 
> to accommodate the non-hugepages parts of the guest e.g. on 24GB host you can 
> reserve 20GB hugepages for VMs to use, and then run a VM with 20GB memory, 
> reserving 16GB hugepages inside the guest for oracle to use.
> 
> Thanks,
> michal
> 
>> 
>> Gianluca 
> 
> 
> I'm making some tests right now. 
> Steps done: 
> - configure huge pages on hypervisor
> 
> [root@ractor ~]# cat /etc/sysctl.d/huge-pages.conf 
> # 20/04/2017 8Gb
> vm.nr_hugepages = 4096
> [root@ractor ~]# 
> 
> rebooted host (I also updated in the mean time it to latest 4.1.1 packages 
> with vdsm-4.19.10.1-1.el7.centos.x86_64 and 
> vdsm-hook-hugepages-4.19.10.1-1.el7.centos.noarch)
> I also set "transparent_hugepage=never" boot parameter because I know that 
> they are in conflict with Huge Pages
> 
> So the situation is:
> 
> [root@ractor ~]# cat /proc/cmdline 
> BOOT_IMAGE=/vmlinuz-3.10.0-514.16.1.el7.x86_64 root=/dev/mapper/centos-root 
> ro rd.lvm.lv =centos/root rd.lvm.lv 
> =centos/swap rhgb quiet LANG=en_US.UTF-8 
> transparent_hugepage=never
> [root@ractor ~]# 
> 
> [root@ractor ~]# cat /proc/meminfo | grep -i huge
> AnonHugePages: 0 kB
> HugePages_Total:4096
> HugePages_Free: 4096
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> [root@ractor ~]# 
> 
> I edited a pre-existing CentOS 6 VM setting for it 8Gb of ram and 2048 pages 
> (4Gb) in custom property forhugepages.
> 
> When I power on I get this addition in qemu-kvm process definition as 
> expected:
> 
> -mem-path /dev/hugepages/libvirt/qemu
> 
> I noticed that now I have on host
> 
> [root@ractor vdsm]# cat /proc/meminfo | grep -i huge
> AnonHugePages: 0 kB
> HugePages_Total:6144
> HugePages_Free: 2048
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> [root@ractor vdsm]# 
> 
> So apparently it did allocated 2048 new huge pages...
> Does it mean that actually I have not to pre-allocate huge pages at all on 
> host and it eventually will increase them (but not able to remove then I 
> suppose) ?
> 
> Anyway the count doesn't seem correct... because it seems that a total of 
> 4096 pages are in use/locked... (HugePages_Total - HugePages_Free + 
> HugePages_Rsvd)
> while they should be 2048.
> 
> [root@ractor vdsm]# ll /dev/hugepages/libvirt/qemu/
> total 0
> [root@ractor vdsm]# ll /hugetlbfs/libvirt/qemu/
> total 0
> [root@ractor vdsm]# 
> 
> If I power off the VM
> 
> [root@ractor vdsm]# cat /proc/meminfo | grep -i huge
> AnonHugePages: 0 kB
> HugePages_Total:4096
> HugePages_Free: 4096
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> [root@ractor vdsm]# 
> 
> Does this mean that in CentOS 7.3 Huge Pages could be reclaimed???

it tries to…wel

Re: [ovirt-users] Question about Huge Pages

[Gianluca Cecchi]

On Thu, Apr 20, 2017 at 10:35 AM, Michal Skrivanek 
wrote:

>
> On 19 Apr 2017, at 16:28, Gianluca Cecchi 
> wrote:
>
> On Wed, Apr 19, 2017 at 3:44 PM, Martin Polednik 
> wrote:
>
>>
>>>
>> If you are using recent CentOS (or I guess Fedora), there isn't any
>> extra setup required. Just create the custom property:
>>
>
> Both my engine and my hosts are CentOS 7.3 + updates
>
>
> that’s good
>
>
>
>>
>> On the host where engine is running:
>>
>> $ engine-config -s "UserDefinedVMProperties=hugepages=^.*$"
>> $ service ovirt-engine restart
>>
>> and you should see 'hugepages' when editing a VM under custom properties.
>>
>
> So no vdsm hook at all to install?
>
>
> today you still need the hook.
>
>
>
>
>> Set the number to (desired memory / 2048) and you're good to go. The
>> VM will run with it's memory backed by hugepages.
>
>
> As in sysctl.conf? So that if I want 4Gb of Huge Pages I have to set 2048?
>
>
> yes. there might be some
>
>
>
>
>> If you need
>> hugepages even inside the VM, do whatever you would do on a physical
>> host.
>>
>> mpolednik
>>
>>
> yes, the main subject is to have Huge Pages inside the guest, so that
> Oracle RDBMS at startup detect them and use them
>
>
> yes, so if you do that via sysctl.conf on real HW just do the same here,
> or modify kernel cmdline.
>
> Note that those are two separate things
> the hook is making QEMU process use hugepages memory in the host - that
> improves performance of any VM
> then how it looks in guest is no concern to oVirt, it’s guest-side
> hugepages. You can enable/set them regardless the previous step, which may
> be fine if you just want to expose the capability to some app  - e.g. in
> testing that the guest-side Oracle can work with hugepages in the guest.
> But you probably want both Oracle to see hugepages and also actually use
> them - then you need both reserve that on host for qemu process and then
> inside guest reserve that for oracle. I.e. you need to add a “buffer” on
> host side to accommodate the non-hugepages parts of the guest e.g. on 24GB
> host you can reserve 20GB hugepages for VMs to use, and then run a VM with
> 20GB memory, reserving 16GB hugepages inside the guest for oracle to use.
>
> Thanks,
> michal
>
>
> Gianluca
>
>
>
I'm making some tests right now.
Steps done:
- configure huge pages on hypervisor

[root@ractor ~]# cat /etc/sysctl.d/huge-pages.conf
# 20/04/2017 8Gb
vm.nr_hugepages = 4096
[root@ractor ~]#

rebooted host (I also updated in the mean time it to latest 4.1.1 packages
with vdsm-4.19.10.1-1.el7.centos.x86_64 and vdsm-hook-hugepages-4.19.
10.1-1.el7.centos.noarch)
I also set "transparent_hugepage=never" boot parameter because I know that
they are in conflict with Huge Pages

So the situation is:

[root@ractor ~]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-514.16.1.el7.x86_64 root=/dev/mapper/centos-root
ro rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF-8
transparent_hugepage=never
[root@ractor ~]#

[root@ractor ~]# cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
HugePages_Total:4096
HugePages_Free: 4096
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
[root@ractor ~]#

I edited a pre-existing CentOS 6 VM setting for it 8Gb of ram and 2048
pages (4Gb) in custom property forhugepages.

When I power on I get this addition in qemu-kvm process definition as
expected:

-mem-path /dev/hugepages/libvirt/qemu

I noticed that now I have on host

[root@ractor vdsm]# cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
HugePages_Total:6144
HugePages_Free: 2048
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
[root@ractor vdsm]#

So apparently it did allocated 2048 new huge pages...
Does it mean that actually I have not to pre-allocate huge pages at all on
host and it eventually will increase them (but not able to remove then I
suppose) ?

Anyway the count doesn't seem correct... because it seems that a total of
4096 pages are in use/locked... (HugePages_Total - HugePages_Free
+ HugePages_Rsvd)
while they should be 2048.

[root@ractor vdsm]# ll /dev/hugepages/libvirt/qemu/
total 0
[root@ractor vdsm]# ll /hugetlbfs/libvirt/qemu/
total 0
[root@ractor vdsm]#

If I power off the VM

[root@ractor vdsm]# cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
HugePages_Total:4096
HugePages_Free: 4096
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
[root@ractor vdsm]#

Does this mean that in CentOS 7.3 Huge Pages could be reclaimed???

Nevertheless, when I configure huge pages in guest it seems to work as
expected

[root@dbtest ~]# cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
HugePages_Total:2048
HugePages_Free: 2048
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB

Going into Oracle DB initialization, after configuring its dedicated memory
(SGA) to 2354Mb, I get this confirmation inside its log file

Re: [ovirt-users] Question about Huge Pages

[Michal Skrivanek]

> On 19 Apr 2017, at 16:28, Gianluca Cecchi  wrote:
> 
> On Wed, Apr 19, 2017 at 3:44 PM, Martin Polednik  > wrote:
> 
> 
> If you are using recent CentOS (or I guess Fedora), there isn't any
> extra setup required. Just create the custom property:
> 
> Both my engine and my hosts are CentOS 7.3 + updates

that’s good

>  
> 
> On the host where engine is running:
> 
> $ engine-config -s "UserDefinedVMProperties=hugepages=^.*$"
> $ service ovirt-engine restart
> 
> and you should see 'hugepages' when editing a VM under custom properties.
> 
> So no vdsm hook at all to install?

today you still need the hook.

> 
>  
> Set the number to (desired memory / 2048) and you're good to go. The
> VM will run with it's memory backed by hugepages.
> 
> As in sysctl.conf? So that if I want 4Gb of Huge Pages I have to set 2048?

yes. there might be some 

> 
>  
> If you need
> hugepages even inside the VM, do whatever you would do on a physical
> host.
> 
> mpolednik
> 
> 
> yes, the main subject is to have Huge Pages inside the guest, so that Oracle 
> RDBMS at startup detect them and use them

yes, so if you do that via sysctl.conf on real HW just do the same here, or 
modify kernel cmdline.

Note that those are two separate things
the hook is making QEMU process use hugepages memory in the host - that 
improves performance of any VM
then how it looks in guest is no concern to oVirt, it’s guest-side hugepages. 
You can enable/set them regardless the previous step, which may be fine if you 
just want to expose the capability to some app  - e.g. in testing that the 
guest-side Oracle can work with hugepages in the guest.
But you probably want both Oracle to see hugepages and also actually use them - 
then you need both reserve that on host for qemu process and then inside guest 
reserve that for oracle. I.e. you need to add a “buffer” on host side to 
accommodate the non-hugepages parts of the guest e.g. on 24GB host you can 
reserve 20GB hugepages for VMs to use, and then run a VM with 20GB memory, 
reserving 16GB hugepages inside the guest for oracle to use.

Thanks,
michal

> 
> Gianluca 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Question about Huge Pages

[Gianluca Cecchi]

On Wed, Apr 19, 2017 at 3:44 PM, Martin Polednik 
wrote:

>
>>
> If you are using recent CentOS (or I guess Fedora), there isn't any
> extra setup required. Just create the custom property:
>

Both my engine and my hosts are CentOS 7.3 + updates


>
> On the host where engine is running:
>
> $ engine-config -s "UserDefinedVMProperties=hugepages=^.*$"
> $ service ovirt-engine restart
>
> and you should see 'hugepages' when editing a VM under custom properties.
>

So no vdsm hook at all to install?



> Set the number to (desired memory / 2048) and you're good to go. The
> VM will run with it's memory backed by hugepages.


As in sysctl.conf? So that if I want 4Gb of Huge Pages I have to set 2048?



> If you need
> hugepages even inside the VM, do whatever you would do on a physical
> host.
>
> mpolednik
>
>
yes, the main subject is to have Huge Pages inside the guest, so that
Oracle RDBMS at startup detect them and use them

Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Question about Huge Pages

[Martin Polednik]

On 19/04/17 14:01 +0200, Gianluca Cecchi wrote:

On Wed, Apr 19, 2017 at 8:03 AM, Michal Skrivanek 
wrote:



Why not reserving regular hugepages for VMs on boot?



Do you mean at hypervisor level? In this case it is what I'm doing normally
for physical servers where I install Oracle RDBMS



then you can use
it with vdsm hook for that Oracle VM.



Which hook are you referring?
This one:
http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/
?
In case is it still current? In the sense that I need to mount the
hugetblfs virtual file system at hst level?
The hook description seems low detailed...
Normally if I want oracle user able to use huge pages on physical server, I
have to specify

#
# Huge pages
#
vm.hugetlb_shm_group = 2000
# 18GB allocatable
vm.nr_hugepages = 9216
#

where 2000 is the group id for dba group, the main group of oracle user

How to map this with vrtualization?
Eg:
1) vm.hugetlb_shm_group at hypervisor side should be set to the group of
the qemu user as the qemu-kvm process runs with it?
2) Then I have to set VM for VM the hugepages=xxx value in the hook and
that will bypass the sysctl.conf configuration in the guest?
3) I presume I have to set the vm.hugetlb_shm_group parameter at guest
level


If you are using recent CentOS (or I guess Fedora), there isn't any
extra setup required. Just create the custom property:

On the host where engine is running:

$ engine-config -s "UserDefinedVMProperties=hugepages=^.*$"
$ service ovirt-engine restart

and you should see 'hugepages' when editing a VM under custom properties.
Set the number to (desired memory / 2048) and you're good to go. The
VM will run with it's memory backed by hugepages. If you need
hugepages even inside the VM, do whatever you would do on a physical
host.

mpolednik


Thanks,
Gianluca




It improves VM performance in
general, the only drawback is less flexibility since that memory can't
be used by others unless they specifically ask for  hugepages.



This seems to confirm that I have to set a statich sysctl.conf entry at
hypervisor level such as
vm.nr_hugepages = 



Also, I suppose you disable KSM, and I'm not sure about ballooning,
unless you need it I'd disable it too.



I kept the defaults at the moment that I suppose should be

a) KSM disabled

ksm has been configured to start by default as normally, but ksmtuned has
been disabled:

[g.cecchi@ov300 ~]$ sudo systemctl status ksm
● ksm.service - Kernel Samepage Merging
  Loaded: loaded (/usr/lib/systemd/system/ksm.service; enabled; vendor
preset: enabled)
  Active: active (exited) since Tue 2017-04-11 11:07:28 CEST; 1 weeks 1
days ago
 Process: 976 ExecStart=/usr/libexec/ksmctl start (code=exited,
status=0/SUCCESS)
Main PID: 976 (code=exited, status=0/SUCCESS)
  CGroup: /system.slice/ksm.service

Apr 11 11:07:28 ov300.datacenter.polimi.it systemd[1]: Starting Kernel
Samepage Merging...
Apr 11 11:07:28 ov300.datacenter.polimi.it systemd[1]: Started Kernel
Samepage Merging.

[g.cecchi@ov300 ~]$ sudo systemctl status ksmtuned
● ksmtuned.service - Kernel Samepage Merging (KSM) Tuning Daemon
  Loaded: loaded (/usr/lib/systemd/system/ksmtuned.service; disabled;
vendor preset: disabled)
  Active: inactive (dead)
[g.cecchi@ov300 ~]$


b) ballooning enabled for a newly created VM unless I explicitly disable it
(at least I see this happens in 4.1.1)

What to do for a) and b) to not interfere with huge pages?



The hook is being improved right now in master, but it should be
usable in stable too.



I will be happy to test and verify and contribute to its description, as
soon as I understand its usage

Gianluca



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Question about Huge Pages

[Gianluca Cecchi]

On Wed, Apr 19, 2017 at 8:03 AM, Michal Skrivanek 
wrote:

>
> Why not reserving regular hugepages for VMs on boot?


Do you mean at hypervisor level? In this case it is what I'm doing normally
for physical servers where I install Oracle RDBMS


> then you can use
> it with vdsm hook for that Oracle VM.


Which hook are you referring?
This one:
http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/
?
In case is it still current? In the sense that I need to mount the
hugetblfs virtual file system at hst level?
The hook description seems low detailed...
Normally if I want oracle user able to use huge pages on physical server, I
have to specify

#
# Huge pages
#
vm.hugetlb_shm_group = 2000
# 18GB allocatable
vm.nr_hugepages = 9216
#

where 2000 is the group id for dba group, the main group of oracle user

How to map this with vrtualization?
Eg:
1) vm.hugetlb_shm_group at hypervisor side should be set to the group of
the qemu user as the qemu-kvm process runs with it?
2) Then I have to set VM for VM the hugepages=xxx value in the hook and
that will bypass the sysctl.conf configuration in the guest?
3) I presume I have to set the vm.hugetlb_shm_group parameter at guest
level

Thanks,
Gianluca



> It improves VM performance in
> general, the only drawback is less flexibility since that memory can't
> be used by others unless they specifically ask for  hugepages.
>

This seems to confirm that I have to set a statich sysctl.conf entry at
hypervisor level such as
vm.nr_hugepages = 


> Also, I suppose you disable KSM, and I'm not sure about ballooning,
> unless you need it I'd disable it too.
>

I kept the defaults at the moment that I suppose should be

a) KSM disabled

ksm has been configured to start by default as normally, but ksmtuned has
been disabled:

[g.cecchi@ov300 ~]$ sudo systemctl status ksm
● ksm.service - Kernel Samepage Merging
   Loaded: loaded (/usr/lib/systemd/system/ksm.service; enabled; vendor
preset: enabled)
   Active: active (exited) since Tue 2017-04-11 11:07:28 CEST; 1 weeks 1
days ago
  Process: 976 ExecStart=/usr/libexec/ksmctl start (code=exited,
status=0/SUCCESS)
 Main PID: 976 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/ksm.service

Apr 11 11:07:28 ov300.datacenter.polimi.it systemd[1]: Starting Kernel
Samepage Merging...
Apr 11 11:07:28 ov300.datacenter.polimi.it systemd[1]: Started Kernel
Samepage Merging.

[g.cecchi@ov300 ~]$ sudo systemctl status ksmtuned
● ksmtuned.service - Kernel Samepage Merging (KSM) Tuning Daemon
   Loaded: loaded (/usr/lib/systemd/system/ksmtuned.service; disabled;
vendor preset: disabled)
   Active: inactive (dead)
[g.cecchi@ov300 ~]$


b) ballooning enabled for a newly created VM unless I explicitly disable it
(at least I see this happens in 4.1.1)

What to do for a) and b) to not interfere with huge pages?


> The hook is being improved right now in master, but it should be
> usable in stable too.
>
>
I will be happy to test and verify and contribute to its description, as
soon as I understand its usage

Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Question about Huge Pages

[Michal Skrivanek]

> On 18 Apr 2017, at 18:03, Gianluca Cecchi  wrote:
>
> Hello,
> I'm testing virtualization of some Oracle servers.
> I have 4.1.1 with CentOS 7.3 servers as hypervisors.
> Typically on physical Oracle servers I configure huge pages for Oracle memory 
> areas.
> In particular I disable Transparent Huge Pages, because they are known to be 
> in conflict with Oracle performances, both in RAC and in standalone 
> configurations.
> In RHEL systems I configure "transparent_hugepage=never" boot parameter, 
> while in Oracle Linux OS uek kernels it is already disabled by default.
> I notice that in CentOS 7.3, by default, transparent huge pages are 
> configured:
>
> [root@ov300 ~]# cat /proc/meminfo | grep -i huge
> AnonHugePages:  17006592 kB
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> [root@ov300 ~]#
>
> I'm going to configure a VM with 64Gb of ram and with an Oracle RDBMS that 
> would have 16Gb of SGA.
> I suspect that I could have problems if I dont' change configuration at 
> hypervisor level...
>
> What do you think about this subject?
> Is there any drawback if I manually configure the hypervisors to boot with  
> the "transparent_hugepage=never" boot parameter?

Why not reserving regular hugepages for VMs on boot? then you can use
it with vdsm hook for that Oracle VM. It improves VM performance in
general, the only drawback is less flexibility since that memory can't
be used by others unless they specifically ask for  hugepages.
Also, I suppose you disable KSM, and I'm not sure about ballooning,
unless you need it I'd disable it too.

The hook is being improved right now in master, but it should be
usable in stable too.

Thanks,
michal
>
> Thanks in advance,
> Gianluca
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Question about Huge Pages

[Gianluca Cecchi]

Hello,
I'm testing virtualization of some Oracle servers.
I have 4.1.1 with CentOS 7.3 servers as hypervisors.
Typically on physical Oracle servers I configure huge pages for Oracle
memory areas.
In particular I disable Transparent Huge Pages, because they are known to
be in conflict with Oracle performances, both in RAC and in standalone
configurations.
In RHEL systems I configure "transparent_hugepage=never" boot parameter,
while in Oracle Linux OS uek kernels it is already disabled by default.
I notice that in CentOS 7.3, by default, transparent huge pages are
configured:

[root@ov300 ~]# cat /proc/meminfo | grep -i huge
AnonHugePages:  17006592 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
[root@ov300 ~]#

I'm going to configure a VM with 64Gb of ram and with an Oracle RDBMS that
would have 16Gb of SGA.
I suspect that I could have problems if I dont' change configuration at
hypervisor level...

What do you think about this subject?
Is there any drawback if I manually configure the hypervisors to boot with
 the "transparent_hugepage=never" boot parameter?

Thanks in advance,
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users