Bug 1039616 - Setting shmmax on F19 is not enough for starting postgres
Summary: Setting shmmax on F19 is not enough for starting postgres
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-installer
Version: 3.4
Hardware: All
OS: Unspecified
urgent
high
Target Milestone: ---
: 3.3.3
Assignee: Sandro Bonazzola
QA Contact: bugs@ovirt.org
URL:
Whiteboard: integration
: 1057011 (view as bug list)
Depends On: 1045351
Blocks: 1024889 1050084
TreeView+ depends on / blocked
 
Reported: 2013-12-09 15:50 UTC by Alex Lourie
Modified: 2014-02-14 09:56 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-14 09:56:53 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 23641 0 None None None Never
oVirt gerrit 23652 0 None None None Never
oVirt gerrit 23653 0 None None None Never
oVirt gerrit 23654 0 None None None Never

Description Alex Lourie 2013-12-09 15:50:39 UTC
Setting shmmax on F19 to ~40Mb is not enough for starting postgres server. This leads the setup to fail on current master on fedora 19 in certain flows.

Comment 1 Sandro Bonazzola 2013-12-11 07:36:33 UTC
I suggest to set it to the theoretical limit of the architecture, which for x86_64 was 64G and 4G respectively. (see bug #660036)

Comment 2 Sandro Bonazzola 2013-12-11 07:37:35 UTC
(In reply to Sandro Bonazzola from comment #1)
> I suggest to set it to the theoretical limit of the architecture, which for
> x86_64 was 64G and 4G respectively. (see bug #660036)

shmmax = 64G
shmall = 4G

Comment 3 Alon Bar-Lev 2013-12-11 07:51:58 UTC
(In reply to Sandro Bonazzola from comment #2)
> (In reply to Sandro Bonazzola from comment #1)
> > I suggest to set it to the theoretical limit of the architecture, which for
> > x86_64 was 64G and 4G respectively. (see bug #660036)
> 
> shmmax = 64G
> shmall = 4G

I think it pre-allocate all this memory as reserved, so it actually takes memory even if unused for the page tables. Are you sure we need it that high?

Comment 4 Sandro Bonazzola 2013-12-11 08:01:53 UTC
(In reply to Alon Bar-Lev from comment #3)
> (In reply to Sandro Bonazzola from comment #2)
> > (In reply to Sandro Bonazzola from comment #1)
> > > I suggest to set it to the theoretical limit of the architecture, which for
> > > x86_64 was 64G and 4G respectively. (see bug #660036)
> > 
> > shmmax = 64G
> > shmall = 4G
> 
> I think it pre-allocate all this memory as reserved, so it actually takes
> memory even if unused for the page tables. Are you sure we need it that high?

Those are default settings in a cleanly installed RHEL.
I'm not really sure on how it works, maybe we can ask Fedora upstream initscripts maintainer to take a look into this issue, CCing.

Comment 5 Sandro Bonazzola 2013-12-11 14:09:12 UTC
Hi Lukas,
can you advise on why Fedora don't use theoretical limit of the architecture for shmmax and shmall as RHEL do?
Is it safe to override Fedora defaults with those values?
Should this be fixed in Fedora?

Comment 6 Sandro Bonazzola 2013-12-18 08:16:33 UTC
Anybody from initscripts-maint-list can advise on this?

Comment 7 Eyal Edri 2014-01-04 20:08:44 UTC
Sandro, can we use a workaround via puppet for settings the theoretical limit on jenkins slaves, until the fedora bug will be fixed?

Comment 8 Sandro Bonazzola 2014-01-07 09:29:44 UTC
Eyal, you can just set kernel.shmmax = 68719476736 in /etc/sysctl.conf on x86_64 as workaround.

See https://bugzilla.redhat.com/attachment.cgi?id=476993 for other architectures.

Comment 10 Sandro Bonazzola 2014-01-20 08:25:28 UTC
systemd maintainers, can you answer on comment #5

Comment 11 Sandro Bonazzola 2014-01-23 06:40:22 UTC
Temporary workaround:

# engine-setup --otopi-environment="OVESETUP_SYSTEM/shmmax=int:68719476736"

Comment 12 Sandro Bonazzola 2014-01-23 10:46:09 UTC
*** Bug 1057011 has been marked as a duplicate of this bug. ***

Comment 13 Sandro Bonazzola 2014-01-23 13:50:22 UTC
kernel maintainers, can you answer on comment #5 ?

Comment 14 Josh Boyer 2014-01-23 14:49:02 UTC
(In reply to Sandro Bonazzola from comment #13)
> kernel maintainers, can you answer on comment #5 ?

You've opened bug 1045351 to track that.  Why are you asking for status on it in two different bugs?

Comment 15 Sandro Bonazzola 2014-01-23 14:56:39 UTC
(In reply to Josh Boyer from comment #14)
> (In reply to Sandro Bonazzola from comment #13)
> > kernel maintainers, can you answer on comment #5 ?
> 
> You've opened bug 1045351 to track that.  Why are you asking for status on
> it in two different bugs?

oVirt is a different product that is just installable on Fedora.
While Fedora is thinking about how to handle it I need to have oVirt running on Fedora since we have 2 upcoming releases soon.
So I need to understand:
 1) If Fedora is going to fix it soon or if we've to provide workaround in oVirt.
 2) If we have to provide the workaround if is it safe to override Fedora defaults with those values

Comment 16 Josh Boyer 2014-01-23 15:06:05 UTC
1) No for the reasons specified in the other bug 2) Yes.

Comment 17 Sandro Bonazzola 2014-01-23 15:07:19 UTC
(In reply to Josh Boyer from comment #16)
> 1) No for the reasons specified in the other bug 2) Yes.

Thanks

Comment 18 Sandro Bonazzola 2014-01-23 15:16:57 UTC
We'll fix this by setting shmmax ourselves on setup.
Need to be verified with DWH too before merging.

Comment 19 Sandro Bonazzola 2014-01-24 12:27:57 UTC
merged on master, 3.4, 3.3 and 3.3.3 branches.

Comment 20 Sandro Bonazzola 2014-02-14 09:56:53 UTC
Closing as 3.3.3 has been released.


Note You need to log in before you can comment on or make changes to this bug.