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
|
| Список | 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 по дате отправления: