(no commit message)
authordillon <dillon@web>
Mon, 22 Oct 2018 02:37:31 +0000 (02:37 +0000)
committerIkiWiki <ikiwiki.info>
Mon, 22 Oct 2018 02:37:31 +0000 (02:37 +0000)
performance/index.html

index 51ca49d..91c7d18 100644 (file)
 
 <p>With the huge amount of SMP work done since 2012, the entire query path no longer has any SMP contention whatsoever and we expect a roughly linear curve until we run out of CPU cores and start digging into hyperthreads.  The only possible sources of contention are increasing memory latencies as more cores load memory, and probably a certain degree of cache mastership ping-ponging that occurs even when locks are shared and do not contend.</p>
 
-<p>The purple curve is the TPS, the green curve is the measured TPS/cpu-thread (with 16 threads selected as the baseline 1.0 ratio), and the light blue curve shows the approximate drop in cpu core frequency as the thread count increases and more CPU cores get loaded.  This particular CPU was running at around 4.2 GHz with one thread and 2.8 GHz or so with all 32 cores loaded.  pgbench was allowed to heat-up during each run, an average of the last three 60-second samples is then graphed.</p>
+<p>The purple curve is the TPS, the green curve is the measured TPS/cpu-thread (with 16 threads selected as the baseline 1.0 ratio), and the light blue curve shows the approximate cpu performance for the system (load x CPU frequency).  This particular CPU was running at around 4.16 GHz with one thread, 3.73 GHz @ 16 threads, 3.12 GHz @ 32 threads, and 2.90 GHz or so at 64 threads.  The horizontal thread count is the number of client processes.  There is also a server process for each client process so the actual number of CPU cores in use begins to use hyperthreads past 16, but don't fully load full cores until it hits 32 due to the IPC between client and server.  pgbench was allowed to heat-up during each run, an average of the last three 60-second samples is then graphed.</p>
 
-[[!img tr2990wx01.png align="right" size="" alt=""]]
+[[!img tr2990wx02.png align="right" size="" alt=""]]
+
+<p>To best determine actual cpu performance, the load factor percentage is multiplied against the CPU frequency of the non-idle cores and then normalized to fit against the TPS graph.  The match-up starts to diverge significantly at just below 32 clients (32 client and 32 server processes).  At n=1 the load is 1.6%, at n=16 the load is 25.7%, at n=32 the load is 51%, and at 64 the load is 100% x 2.9 GHz.</p>
+
+<p>From this it is reasonable to assume, roughly, that the hyperthreads really get dug into past n=32.  At n=32 we had around 750K TPS and at n=64 we had 1180K TPS, 57% higher.  So, roughly, hyperthreading adds around 50-60% more TPS to the results.</p>
 
-<p>As we can see, query TPS scales very well with cores on this cpu.  Keeping in mind that this cpu starts digging into its hyperthreads past 32 (really past 28 or so given the client-vs-server breakdown), there is an expectation of seeing the curve go non-linear past 32 threads and then going flat at 64 threads is borne out.  In particular, we can note that hyperthreading gives us approximately 50% more TPS performance, capping out at around 1.18M TPS/sec.</p>