Re: Better LWLocks with compare-and-swap (9.4) - Mailing list pgsql-hackers

Em Dom, 2013-05-19 às 09:29 +0300, Heikki Linnakangas escreveu:
> On 18.05.2013 03:52, Dickson S. Guedes wrote:
> >> pgbench -S is such a workload. With 9.3beta1, I'm seeing this
> >> profile, when I run "pgbench -S -c64 -j64 -T60 -M prepared" on a
> >> 32-core Linux machine:
> >>
> >> -  64.09%  postgres  postgres           [.] tas - tas - 99.83%
> >> s_lock - 53.22% LWLockAcquire + 99.87% GetSnapshotData - 46.78%
> >> LWLockRelease GetSnapshotData + GetTransactionSnapshot +   2.97%
> >> postgres  postgres           [.] tas +   1.53%  postgres
> >> libc-2.13.so       [.] 0x119873 +   1.44%  postgres  postgres
> >> [.] GetSnapshotData +   1.29%  postgres  [kernel.kallsyms]  [k]
> >> arch_local_irq_enable +   1.18%  postgres  postgres           [.]
> >> AllocSetAlloc ...
> >
> > I'd like to test this here but I couldn't reproduce that perf output
> > here in a 64-core or 24-core machines, could you post the changes to
> > postgresql.conf and the perf arguments that you used?
>
> Sure, here are the non-default postgresql.conf settings:


Thank you for your information.


> While pgbench was running, I ran this:
>
> perf record -p 6050 -g -e cpu-clock
>
> to connect to one of the backends. (I used cpu-clock, because the
> default cpu-cycles event didn't work on the box)


Hum, I was supposing that I was doing something wrong but I'm getting
the same result as before even using your test case and my results is
still different from yours:


+ 71,27% postgres postgres         [.] AtEOXact_Buffers
+  7,67% postgres postgres         [.] AtEOXact_CatCache
+  6,30% postgres postgres         [.] AllocSetCheck
+  5,34% postgres libc-2.12.so     [.] __mcount_internal
+  2,14% postgres [kernel.kallsyms][k] activate_page


It's a 64-core machine with PGDATA in a SAN.

vendor_id       : GenuineIntel
cpu family      : 6
model           : 47
model name      : Intel(R) Xeon(R) CPU E7- 4830  @ 2.13GHz
stepping        : 2
cpu MHz         : 1064.000
cache size      : 24576 KB
physical id     : 3
siblings        : 16
core id         : 24
cpu cores       : 8
apicid          : 241
initial apicid  : 241
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx
smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt aes
lahf_lm ida arat epb dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4255.87
clflush size    : 64
cache_alignment : 64
address sizes   : 44 bits physical, 48 bits virtual
power management:


Would you like that I test some other configuration to try to simulate
that expected workload?


[]s
--
Dickson S. Guedes
mail/xmpp: guedes@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A