Hello guys,
I've been trying to "hunting down" my problem and reached the following:
1) Emre Hasegeli has suggested to reduce my shared buffers, but it's already low:
total server memory: 141 GB
shared_buffers: 16 GB
Maybe it's too low? I've been thinking to increase to 32 GB.
max_connections = 500 and ~400 connections average
2) Being "hanging" on "semop" I tried the following, as suggested on some "tuning page" over web.
echo "250 32000 100 128" > /proc/sys/kernel/sem
3) I think my problem could be something related to "LwLocks", as I did some googling and found some related problems and slides. There is some way I can confirm this?
4) Rebooting the server didn't make any difference.
Appreciate any help,
Rafael
On Tue, Jun 11, 2013 at 9:48 AM, Rafael Domiciano <rafael.domiciano@xxxxxxxxx> wrote:
Hello all you guys,Since saturday I'm get stucked in a very strange situation: from time to time (sometimes with intervals less than 10 minutes), the server get "stucked"/"hang" (I dont know how to call it) and every connections on postgres (dont matter if it's SELECT, UPDATE, DELETE, INSERT, startup, authentication...) seems like get "paused"; after some seconds (say ~10 or ~15 sec, sometimes less) everything "goes OK".So, my first trial was to check disks. Running "iostat" apparently showed that disks was OK. It's a Raid10, 4 600GB SAS, IBM Storage DS3512, over FC. IBM DS Storage Manager says that disks is OK.Then, memory. Apparently no swap being used:[###@### data]# free -mtotal used free shared buffers cachedMem: 145182 130977 14204 0 43 121407-/+ buffers/cache: 9526 135655Swap: 6143 65 6078No error on /var/log/messages.Following, is some strace of one processes, and some others, maybe, useful infos. Every processes I've straced bring the same scenario: seems it get stucked on semop.There's no modification in server since last monday, that I changed pg_hba.conf to login in LDAP. The LDAP Server apparently is OK, and tcpdump doesnt show any slow on response, neither big activity on this port.Any help appreciate,[###@### ~]# strace -ttp 5209Process 5209 attached - interrupt to quit09:01:54.122445 semop(2293765, {{15, -1, 0}}, 1) = 009:01:55.368785 semop(2293765, {{15, -1, 0}}, 1) = 009:01:55.368902 semop(2523148, {{11, 1, 0}}, 1) = 009:01:55.368978 semop(2293765, {{15, -1, 0}}, 1) = 009:01:55.369861 semop(2293765, {{15, -1, 0}}, 1) = 009:01:55.370648 semop(3047452, {{6, 1, 0}}, 1) = 009:01:55.370694 semop(2293765, {{15, -1, 0}}, 1) = 009:01:55.370762 semop(2785300, {{12, 1, 0}}, 1) = 009:01:55.370805 access("base/2048098929", F_OK) = 009:01:55.370953 open("base/2048098929/PG_VERSION", O_RDONLY) = 5[###@### data]# ipcs -l- Shared Memory Limits -max number of segments = 4096max seg size (kbytes) = 83886080max total shared memory (kbytes) = 17179869184min seg size (bytes) = 1------ Semaphore Limits --------max number of arrays = 128max semaphores per array = 250max semaphores system wide = 32000max ops per semop call = 32semaphore max value = 32767------ Messages: Limits --------max queues system wide = 32768max size of message (bytes) = 65536default max size of queue (bytes) = 65536[###@### data]# ipcs -u----- Semaphore Status -------used arrays: 34allocated semaphores: 546[###@### data]# uname -aLinux ### 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linuxpostgres=# select version();version--------------------------------------------------------------------------------------------------------------PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 64-bit(1 registro)[###@### data]# cat /etc/redhat-releaseCentOS release 6.3 (Final)
