Zdenek Kotala wrote:
> Zdenek Kotala napsal(a):
>> Heikki Linnakangas napsal(a):
>>> Zdenek Kotala wrote:
>>>> My conclusion is that new implementation is about 8% slower in OLTP
>>>> workload.
>>>
>>> Can you do some analysis of why that is?
>
> I tested it several times and last test was surprise for me. I run
> original server (with old FSM) on the database which has been created by
> new server (with new FSM) and performance is similar (maybe new
> implementation is little bit better):
>
> MQThL (Maximum Qualified Throughput LIGHT): 1348.90 tpm
> MQThM (Maximum Qualified Throughput MEDIUM): 2874.76 tpm
> MQThH (Maximum Qualified Throughput HEAVY): 2422.20 tpm
>
> The question is why? There could be two reasons for that. One is
> realated to OS/FS or HW. Filesystem could be defragmented or HDD is
> slower in some part...
Ugh. Could it be autovacuum kicking in at different times? Do you get
any other metrics than the TPM out of it.
> Second idea is that new FSM creates heavy defragmented data and index
> scan needs to jump from one page to another too often.
Hmm. That's remotely plausible, I suppose. The old FSM only kept track
of pages with more than avg. request size of free space, but the new FSM
tracks even the smallest free spots. Is there tables in that workload
that are inserted to, with very varying row widths?
FWIW, I just got the results of my first 2h DBT-2 results, and I'm
seeing no difference at all in the overall performance or behavior
during the test. Autovacuum doesn't kick in in those short tests,
though, so I schedule a pair of 4h tests, and might run even longer
tests over the weekend.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
