Hi All, Could anybody point me in the right direction for setting the kernel parameter, max_stack_depth, to 10240 for database tuning? I have currently set it by running 'ulimit -s 10240' but this does not survive a reboot. I've Googled plenty and can't find any solution, thanks Michael
Could anybody point me in the right direction for setting the kernel parameter, max_stack_depth, to 10240 for database tuning? I have currently set it by running 'ulimit -s 10240' but this does not survive a reboot. Look at the file /etc/security/limits.conf For documentation, 'man limits.conf' - Thomas
Hi Thomas,> Could anybody point me in the right direction for setting the kernel > parameter, max_stack_depth, to 10240 for database tuning? > > I have currently set it by running 'ulimit -s 10240' but this does not > survive a reboot. > >Thanks for the response, I've been nosing around that file recently but noted the first two lines; #This file sets the resource limits for the users logged in via PAM. #It does not affect resource limits of the system services.> Look at the file /etc/security/limits.conf > > For documentation, 'man limits.conf' > > - Thomas > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >I added these two lines to the end of the file * soft stack 12288 * hard stack 12288 in an attempt to set the stack depth to 12MB so that I can configure postgresql max_stack_depth = 10MB. I rebooted, ulimit -s shows 12288. When I restart my service (#It does not affect resource limits of the system services.) becomes apparent. Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >LOG: invalid value for parameter "max_stack_depth": 10240 Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >DETAIL: "max_stack_depth" must not exceed 7680kB. Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >HINT: Increase the platform's stack depth limit via "ulimit -s" or local equivalent. So, I then run 'ulimit -s 12288' and still can't restart my service. How can I increase stack depth for system processes, not just PAM authenticated users? Thanks in advance, Michael
On 08/14/2015 07:19 AM, Michael H wrote:> I have currently set it by running 'ulimit -s 10240' but this does not > survive a reboot.It's already been pointed out that you'll need to modify the init script, but just to make clear why that is the case, I thought it should be pointed out that "ulimit" is a bash built-in command. When you run "ulimit -s 10240" you're not modifying the system, as a whole. You're only modifying that shell's environment and any child process that you start from that shell. Not only does the command not survive a reboot, it doesn't persist between logins. And that's one of the better features of systemd. Because services are always started by systemd, they don't inherit environment, or process limits, or SELinux context from a login shell. If they start correctly interactively, via systemctl, they'll start correctly the next time the system boots. Under the old init system, that wasn't true.
On 8/15/2015 1:17 PM, Gordon Messmer wrote:> On 08/14/2015 07:19 AM, Michael H wrote: >> I have currently set it by running 'ulimit -s 10240' but this does >> not survive a reboot. > > It's already been pointed out that you'll need to modify the init > script, but just to make clear why that is the case, I thought it > should be pointed out that "ulimit" is a bash built-in command. When > you run "ulimit -s 10240" you're not modifying the system, as a > whole. You're only modifying that shell's environment and any child > process that you start from that shell. Not only does the command not > survive a reboot, it doesn't persist between logins. > > And that's one of the better features of systemd. Because services > are always started by systemd, they don't inherit environment, or > process limits, or SELinux context from a login shell. If they start > correctly interactively, via systemctl, they'll start correctly the > next time the system boots. Under the old init system, that wasn't true.The problem with it though is it ignores system wide and user specific baseline settings. If systemd still obeyed ulimits.conf I would agree that it was an improvement.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos