postgres is not using tas
hi all
i'm working with pg7.2 on irix6.5 platform and i've realized that postgres is using semop instead of tas, pg_config_os.h has define HAVE_TEST_AND_SET, and i don't kwow where could be the mistake.
any suggestion?
thanks and regards
"Luis Alberto Amigo Navarro" <lamigo@atc.unican.es> writes:
i'm working with pg7.2 on irix6.5 platform and i've realized that postgres =
is using semop instead of tas, pg_config_os.h has define HAVE_TEST_AND_SET,=
and i don't kwow where could be the mistake.
s_lock.h seems to think that __sgi is predefined on IRIX. Perhaps that
is not true in your setup? What compiler are you using?
regards, tom lane
hi tom
It is compiled with mips pro compilers
I've tried to remove if defined in s_lock.h, but it's still using semop, is
there any other side it could be defined.
thanks and regards.
As i know, it's only using semop, even with TAS_AND_SET defined, this is an
extract from postmaster's process registry
2515.934mS(+ 5914uS)[ 4] postgres(38089): read(25, <00 00 00 00 68
a9 6e 10 00 00 00 22 00 a8 00 c8>..., 8192) = 8192
2520.497mS(+ 4562uS)[ 4] postgres(38089): read(25, <00 00 00 00 68
a9 9a 18 00 00 00 22 00 a8 00 c8>..., 8192) = 8192
2526.496mS(+ 5998uS)[ 4] postgres(38089): read(25, <00 00 00 00 68
a9 c6 38 00 00 00 22 00 a8 00 c8>..., 8192) = 8192
2527.115mS(+ 619uS)[ 4] postgres(38089): semop(1568, 0x7fff1c70,
1) OK
2527.314mS(+ 198uS)[ 4] postgres(38089): semop(1568, 0x7fff1c70,
1) OK
2527.390mS(+ 76uS)[ 4] postgres(38089): semop(1568, 0x7fff1c70,
1) OK
2532.199mS(+ 4809uS)[ 4] postgres(38089): read(25, <00 00 00 00 68
a9 f2 40 00 00 00 22 00 a8 00 c8>..., 8192) = 8192
2537.896mS(+ 5696uS)[ 4] postgres(38089): read(25, <00 00 00 00 68
aa 1e 48 00 00 00 22 00 a8 00 c8>..., 8192) = 8192
2543.147mS(+ 5251uS)[ 4] postgres(38089): read(25, <00 00 00 00 68
aa 4a 68 00 00 00 22 00 a8 00 c8>..., 8192) = 8192
Thanks and regards
here is the execution of one backend summary:
System call summary:
Average Total
Name #Calls Time(ms) Time(ms)
-----------------------------------------
semop 39305 0.06 2497.53
select 7 19.86 139.01
unlink 1 22.96 22.96
close 49 0.04 2.06
recv 1 0.72 0.72
send 1 0.11 0.11
fsync 1 0.07 0.07
prctl 1 0.01 0.01
exit 1 0.00 0.00
As u can see it's amazing
Thanks and regards
"Luis Alberto Amigo Navarro" <lamigo@atc.unican.es> writes:
As i know, it's only using semop, even with TAS_AND_SET defined, this is an
extract from postmaster's process registry
The fact that there are some semops in the strace doesn't prove
anything. We do use semaphores when we have to block the current
process.
regards, tom lane
hi tom
could you please tell me where to find info on when and why is semop used,
this thread began because i had excessive sem usage as u can see
thanks and regards
"Luis Alberto Amigo Navarro" <lamigo@atc.unican.es> writes:
could you please tell me where to find info on when and why is semop used,
It's used when we need to block the current process (or to unblock
another process that had been waiting). Look for calls to
IpcSemaphoreLock and IpcSemaphoreUnlock.
A large number of semops may mean that you have excessive contention on
some lockable resource, but I don't have enough info to guess what resource.
Have you tried doing profiling of the backend?
regards, tom lane
Theoriginal problem was the low cpu usage due to semaphores, most of orange
zone is due to sems
thanks and regards
Attachments:
hi tom
If i track a single backend during an 8 read-only queries parallel execution
these are the results(
System call summary:
Average Total
Name #Calls Time(ms) Time(ms)
-----------------------------------------
semop 3803 0.20 774.03
select 4 19.58 78.33
recv 1 2.41 2.41
brk 6 0.08 0.48
close 1 0.14 0.14
send 1 0.14 0.14
semctl 1 0.05 0.05
prctl 1 0.01 0.01
exit 1 0.00 0.00
I think it's a bit excessive for a 8 SMP
what do u think?
thanks and regards
"Luis Alberto Amigo Navarro" <lamigo@atc.unican.es> writes:
If i track a single backend during an 8 read-only queries parallel execution
these are the results(
System call summary:
Average Total
Name #Calls Time(ms) Time(ms)
-----------------------------------------
semop 3803 0.20 774.03
select 4 19.58 78.33
recv 1 2.41 2.41
brk 6 0.08 0.48
close 1 0.14 0.14
send 1 0.14 0.14
semctl 1 0.05 0.05
prctl 1 0.01 0.01
exit 1 0.00 0.00
Considering that there are no read() or write() calls listed, and that
8 client queries would surely require at least one send() and one recv()
apiece, I don't think I believe a word of those stats. Well, maybe the
1 exit() is correct ;-)
regards, tom lane
hi tom
how may we have believable statistics?
what do u think about the graph i've sent to you, there are retrieved using
hardware counters, i believe they are exact.
Any idea?
Thanks and regards