On 26 Oct, Bruce Momjian wrote:
> Mark Wong wrote:
>> > > Here are a pair of results where I just raise the load on the
>> > > database, where increasing the load increases the area of the database
>> > > touched in addition to increasing the transaction rate. The overall
>> > > metric increases somewhat, but the response time for most of the
>> > > interactions also increases significantly:
>> > >
>> > > http://developer.osdl.org/markw/dbt2-pgsql/158/ [baseline]
>> > > - load of 100 warehouses
>> > > - metric 1249.65
>> > >
>> > > http://developer.osdl.org/markw/dbt2-pgsql/149/
>> > > - load of 140 warehouses
>> > > - metric 1323.90
>> >
>> > I looked at these charts and they looked normal to me. It looked like
>> > your the load increased until your computer was saturated. Is there
>> > something I am missing?
>>
>> I've run some i/o tests so I'm pretty sure I haven't saturated that. And it
>> looks like I have almost 10% more processor time left. I do agree that it
>> appears something might be saturated, I just don't know where to look...
>
> Could the 10% be context switching time, or is the I/O saturated?
There are about 14,000 to 17,000 context switches/s according to the
vmstat output. This is on a 1.5Ghz hyperthreaded Xeon processor. I
don't know what I'm supposed to be able to expect in terms of context
switching. I really doubt the i/o is saturated because I've run
disktest (part of the Linux Test Project suite) and saw much higher
throughput for various sequential/random read/write tests.
I'm starting to collect oprofile data (and will hopefully have some
results soon) to get an idea where the database is spending its time,
just in case that may have something to do with it.
Mark
