Thread: 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 registry2515.934mS(+ 5914uS)[ 4] postgres(38089): read(25, <00 00 00 00 68 a9 6e 10 00 00 00 22 00 a8 00 c8>..., 8192) = 81922520.497mS(+ 4562uS)[ 4] postgres(38089): read(25, <00 00 00 0068 a9 9a 18 00 00 00 22 00 a8 00 c8>..., 8192) = 81922526.496mS(+ 5998uS)[ 4] postgres(38089): read(25, <00 00 00 0068 a9 c6 38 00 00 00 22 00 a8 00 c8>..., 8192) = 81922527.115mS(+ 619uS)[ 4] postgres(38089): semop(1568, 0x7fff1c70, 1) OK2527.314mS(+ 198uS)[ 4] postgres(38089): semop(1568, 0x7fff1c70, 1) OK2527.390mS(+ 76uS)[ 4] postgres(38089): semop(1568, 0x7fff1c70, 1) OK2532.199mS(+ 4809uS)[ 4] postgres(38089): read(25, <00 00 00 00 68 a9 f2 40 00 00 00 22 00 a8 00 c8>..., 8192) = 81922537.896mS(+ 5696uS)[ 4] postgres(38089): read(25, <00 00 00 0068 aa 1e 48 00 00 00 22 00 a8 00 c8>..., 8192) = 81922543.147mS(+ 5251uS)[ 4] postgres(38089): read(25, <00 00 00 0068 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
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
Theoriginal problem was the low cpu usage due to semaphores, most of orange zone is due to sems thanks and regards
postgres is compiled with Mipspro compiler, how may i prepare it for profiling. Thanks and regards