Perf Benchmarking and regression.
От | Mithun Cy |
---|---|
Тема | Perf Benchmarking and regression. |
Дата | |
Msg-id | CAD__OuhPmc6XH=wYRm_+Q657yQE88DakN4=Ybh2oveFasHkoeA@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Perf Benchmarking and regression.
(Andres Freund <andres@anarazel.de>)
|
Список | pgsql-hackers |
I tried to do some benchmarking on postgres master head
commit 72a98a639574d2e25ed94652848555900c81a799
Author: Andres Freund <andres@anarazel.de>
Date: Tue Apr 26 20:32:51 2016 -0700
commit 72a98a639574d2e25ed94652848555900c81a799
Author: Andres Freund <andres@anarazel.de>
Date: Tue Apr 26 20:32:51 2016 -0700
CASE : Read-Write Tests when data exceeds shared buffers.
Non Default settings and test
./postgres -c shared_buffers=8GB -N 200 -c min_wal_size=15GB -c max_wal_size=20GB -c checkpoint_timeout=900 -c maintenance_work_mem=1GB -c checkpoint_completion_target=0.9 &
./pgbench -i -s 1000 postgres
./pgbench -c $threads -j $threads -T 1800 -M prepared postgres
./postgres -c shared_buffers=8GB -N 200 -c min_wal_size=15GB -c max_wal_size=20GB -c checkpoint_timeout=900 -c maintenance_work_mem=1GB -c checkpoint_completion_target=0.9 &
./pgbench -i -s 1000 postgres
./pgbench -c $threads -j $threads -T 1800 -M prepared postgres
Machine : "cthulhu" 8 node numa machine with 128 hyper threads.
>numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0 65 66 67 68 69 70 71 96 97 98 99 100 101 102 103
node 0 size: 65498 MB
node 0 free: 37885 MB
node 1 cpus: 72 73 74 75 76 77 78 79 104 105 106 107 108 109 110 111
node 1 size: 65536 MB
node 1 free: 31215 MB
node 2 cpus: 80 81 82 83 84 85 86 87 112 113 114 115 116 117 118 119
node 2 size: 65536 MB
node 2 free: 15331 MB
node 3 cpus: 88 89 90 91 92 93 94 95 120 121 122 123 124 125 126 127
node 3 size: 65536 MB
node 3 free: 36774 MB
node 4 cpus: 1 2 3 4 5 6 7 8 33 34 35 36 37 38 39 40
node 4 size: 65536 MB
node 4 free: 62 MB
node 5 cpus: 9 10 11 12 13 14 15 16 41 42 43 44 45 46 47 48
node 5 size: 65536 MB
node 5 free: 9653 MB
node 6 cpus: 17 18 19 20 21 22 23 24 49 50 51 52 53 54 55 56
node 6 size: 65536 MB
node 6 free: 50209 MB
node 7 cpus: 25 26 27 28 29 30 31 32 57 58 59 60 61 62 63 64
node 7 size: 65536 MB
node 7 free: 43966 MB
node distances:
node 0 1 2 3 4 5 6 7
0: 10 21 21 21 21 21 21 21
1: 21 10 21 21 21 21 21 21
2: 21 21 10 21 21 21 21 21
3: 21 21 21 10 21 21 21 21
4: 21 21 21 21 10 21 21 21
5: 21 21 21 21 21 10 21 21
6: 21 21 21 21 21 21 10 21
7: 21 21 21 21 21 21 21 10
>numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0 65 66 67 68 69 70 71 96 97 98 99 100 101 102 103
node 0 size: 65498 MB
node 0 free: 37885 MB
node 1 cpus: 72 73 74 75 76 77 78 79 104 105 106 107 108 109 110 111
node 1 size: 65536 MB
node 1 free: 31215 MB
node 2 cpus: 80 81 82 83 84 85 86 87 112 113 114 115 116 117 118 119
node 2 size: 65536 MB
node 2 free: 15331 MB
node 3 cpus: 88 89 90 91 92 93 94 95 120 121 122 123 124 125 126 127
node 3 size: 65536 MB
node 3 free: 36774 MB
node 4 cpus: 1 2 3 4 5 6 7 8 33 34 35 36 37 38 39 40
node 4 size: 65536 MB
node 4 free: 62 MB
node 5 cpus: 9 10 11 12 13 14 15 16 41 42 43 44 45 46 47 48
node 5 size: 65536 MB
node 5 free: 9653 MB
node 6 cpus: 17 18 19 20 21 22 23 24 49 50 51 52 53 54 55 56
node 6 size: 65536 MB
node 6 free: 50209 MB
node 7 cpus: 25 26 27 28 29 30 31 32 57 58 59 60 61 62 63 64
node 7 size: 65536 MB
node 7 free: 43966 MB
node distances:
node 0 1 2 3 4 5 6 7
0: 10 21 21 21 21 21 21 21
1: 21 10 21 21 21 21 21 21
2: 21 21 10 21 21 21 21 21
3: 21 21 21 10 21 21 21 21
4: 21 21 21 21 10 21 21 21
5: 21 21 21 21 21 10 21 21
6: 21 21 21 21 21 21 10 21
7: 21 21 21 21 21 21 21 10
I see some regression when compared to 9.5
Sessions | PostgreSQL-9.5 scale 1000 | PostgreSQL-9.6 scale 1000 | %diff |
1 | 747.367249 | 892.149891 | 19.3723557185 |
8 | 5281.282799 | 4941.905008 | -6.4260484416 |
16 | 9000.915419 | 8695.396233 | -3.3943123758 |
24 | 11852.839627 | 10843.328776 | -8.5170379653 |
32 | 14323.048334 | 11977.505153 | -16.3760054864 |
40 | 16098.926583 | 12195.447024 | -24.2468312336 |
48 | 16959.646965 | 12639.951087 | -25.4704351271 |
56 | 17157.737762 | 12543.212929 | -26.894715941 |
64 | 17201.914922 | 12628.002422 | -26.5895542487 |
72 | 16956.994835 | 11280.870599 | -33.4736448954 |
80 | 16775.954896 | 11348.830603 | -32.3506132834 |
88 | 16609.137558 | 10823.465121 | -34.834273705 |
96 | 16510.099404 | 11091.757753 | -32.8183466278 |
104 | 16275.724927 | 10665.743275 | -34.4683980416 |
112 | 16141.815128 | 10977.84664 | -31.9912503461 |
120 | 15904.086614 | 10716.17755 | -32.6199749153 |
128 | 15738.391503 | 10962.333439 | -30.3465450271 |
When I run git bisect on master (And this is for 128 clients).
2 commitIds which affected the performance1. # first bad commit: [ac1d7945f866b1928c2554c0f80fd52d7f977772] Make idle backends exit if the postmaster dies.
15947.21546 (15K +) to 13409.758510 (arround 13K+).
2. # first bad commit: [428b1d6b29ca599c5700d4bc4f4ce4c5880369bf] Allow to trigger kernel writeback after a configurable number of writes.
this made performance to drop further to 10962.333439 (10K +)
I think It did not recover afterwards.
--
В списке pgsql-hackers по дате отправления: