Re: dbt2 NOTPM numbers

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: dbt2 NOTPM numbers
Дата
Msg-id 46657180.7010604@enterprisedb.com
обсуждение исходный текст
Ответ на Re: dbt2 NOTPM numbers  (Markus Schiltknecht <markus@bluegap.ch>)
Ответы Re: dbt2 NOTPM numbers  (Markus Schiltknecht <markus@bluegap.ch>)
Список pgsql-performance
Markus Schiltknecht wrote:
> Hi,
>
> Heikki Linnakangas wrote:
>> I still suspect there's something wrong with plans, I doubt you can
>> get that bad performance unless it's doing something really stupid.
>
> Agreed, but I'm still looking for that really stupid thing...  AFAICT,
> there are really no seqscans..., see the pg_stat_user_tables below.
>
>> I'd suggest setting log_min_duration_statement = 5000, and seeing what
>> you get. Also check pg_stat_user_table.seq_scan just to be extra sure
>> there's no seq scans.
>
> I've also added some of the log messages for min_duration_statement
> below. Both were taken after two or three test runs.
>
> I'm really wondering, if the RAID 6 of the ARECA 1260 hurts so badly.
> That would be disappointing, IMO. I'll try if I can reconfigure it to do
> RAID 1+0, and then test again. (Unfortunately the box has already been
> shipped to the customer, so that's getting tricky to do via ssh..:-( ).

Maybe, TPC-C is very write-intensive. I don't know much about RAID
stuff, but I think you'd really benefit from a separate WAL drive. You
could try turning fsync=off to see if that makes a difference.

Oh, and how many connections are you using? DBT-2 can be quite sensitive
to that. 30 seems to work pretty well for me.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

В списке pgsql-performance по дате отправления:

Предыдущее
От: Markus Schiltknecht
Дата:
Сообщение: Re: dbt2 NOTPM numbers
Следующее
От: Douglas J Hunley
Дата:
Сообщение: Re: upgraded to pgsql 8.2.4, getting worse performance then 7.4.x