Hi Jason,
On 14/08/15 16:45, Jason Warr wrote:
On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote:
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.
What CentOS version?
CentOS7.1
Look at the file /etc/security/limits.conf
For documentation, 'man limits.conf'
- Thomas
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
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?
If this is CentOS 7 then you may need to put the ulimit directives in the service file.
An example is I needed to increase the NOFILE limit for nfs-secure on a Fedora 20 machine so I set
LimitNOFILE=16384
In /etc/systemd/system/nfs-secure.service
I located the service file for postgresql-9.4
[root@db1 multi-user.target.wants]# locate postgresql-9.4.service
/etc/systemd/system/multi-user.target.wants/postgresql-9.4.service
/usr/lib/systemd/system/postgresql-9.4.service
I've edited
/etc/systemd/system/multi-user.target.wants/postgresql-9.4.service and added
LimitSTACK=12288
to the [Unit] section of the service file.
systemctl daemon-reload
systemctl restart postgresql-9.4
I'm still getting the same errors when I try to start my service...
Aug 17 08:23:58 db1 pg_ctl[16839]: < 2015-08-17 08:23:58.533 BST >LOG:
invalid value for parameter "max_stack_depth": 10240
Aug 17 08:23:58 db1 pg_ctl[16839]: < 2015-08-17 08:23:58.533 BST
>DETAIL: "max_stack_depth" must not exceed 7680kB.
I have tried moving the 'LimitSTACK=12288' to other sections of the
service file, when I do I don't get my error from postgresql I see this
in /var/log/messages
Aug 17 08:38:47 db1 systemd: Reloading.
Aug 17 08:38:47 db1 systemd:
[/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue
'RemoveOnStop' in section 'Socket'
Aug 17 08:38:47 db1 systemd:
[/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue
'RemoveOnStop' in section 'Socket'
Aug 17 08:38:49 db1 systemd: Starting PostgreSQL 9.4 database server...
Aug 17 08:38:49 db1 kernel: postgresql94-ch[3021]: segfault at
7ffcd1a28f30 ip 00007f116054c79e sp 00007ffcd1a28f30 error 6 in
libc-2.17.so[7f1160458000+1b6000]
Aug 17 08:38:49 db1 systemd: postgresql-9.4.service: control process
exited, code=killed status=11
Aug 17 08:38:49 db1 systemd: Failed to start PostgreSQL 9.4 database server.
Aug 17 08:38:49 db1 systemd: Unit postgresql-9.4.service entered failed
state.
Thanks in advance,
Michael
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
Should I, or can I make this change elsewhere?
thanks
Michael
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
