Hide Forgot
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.
I suggest to set it to the theoretical limit of the architecture, which for x86_64 was 64G and 4G respectively. (see bug #660036)
(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
(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?
(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.
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?
Anybody from initscripts-maint-list can advise on this?
Sandro, can we use a workaround via puppet for settings the theoretical limit on jenkins slaves, until the fedora bug will be fixed?
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.
systemd maintainers, can you answer on comment #5
Temporary workaround: # engine-setup --otopi-environment="OVESETUP_SYSTEM/shmmax=int:68719476736"
*** Bug 1057011 has been marked as a duplicate of this bug. ***
kernel maintainers, can you answer on comment #5 ?
(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?
(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
1) No for the reasons specified in the other bug 2) Yes.
(In reply to Josh Boyer from comment #16) > 1) No for the reasons specified in the other bug 2) Yes. Thanks
We'll fix this by setting shmmax ourselves on setup. Need to be verified with DWH too before merging.
merged on master, 3.4, 3.3 and 3.3.3 branches.
Closing as 3.3.3 has been released.