|
|
Posted by Robert Klemme on 08/21/06 13:01
On 21.08.2006 14:26, boa sema wrote:
> Thanks for replying so fast. Don't know about you guys, but I find
> discussions/challenges like these very interesting. Not too many people
> to discuss with where I am now, so thanks again.
Same here.
> Some things have changed since the original post. The guy responsible
> for the import job has been working the entire weekend, found a couple
> of bugs and has also suddenly decided that it is possible to run the job
> at night instead of 24/7. This means that the theory probably will
> remain a theory as the import doesn't block out the customers anymore. A
> good thing!
OTOH you cannot verify your theory and learn something which in itself
is a bad thing. :-) Also, your traffic might increase and you're back
to square 0.
Apart from that this is of course a good solution. Now you can even
skip your disk allocation and give the full IO bandwidth to *all*
processes. :-)
>> I see these issues with your theory:
>>
>> - Disks with cache on them will optimize accesses to minimize latency
>> created by head moves.
>>
>> - With a RAID since disk != physical disk there is not a single head
>> that moves and read and write requests are scheduled by the RAID
>> controller to optimize IO operations.
>
> I agree that these issues are real, OTOH isn't "my theory" also the
> reason one places the transaction logs on separate drives? If not,
> what's the difference?
Access patterns are completely different for data files and TX log. In
an OLTP environment TX log is continuously written and you need a RAID
level that supports fast writing and high reliability. Data files are
read and written with arbitrary (although optimized) access patterns.
>> As I said earlier, to me it seems that you basically reserve IO
>> bandwidth for certain tasks and thus most IO bandwidth is unused most
>> of the time.
>
> Correct. The aim was to get good, predicable performance all the time,
> not maximum, but unpredictable performance most of the time. So I did
> plan to 'waste' some IO bandwidth approx 66% of the time, but that's OK.
The question is if it had worked out the way you planned. I don't know
how SQL Server schedules disk accesses for different sessions but in the
worst case your import would occupy the whole buffer and other sessions
would have to wait until the import has written all pages to disk via
the bandtwith restricted IO channel.
>> This reminds me a bit of when packet switching was introduced to
>> networks: before that you needed a physical channel per connection
>> which gave reproducible throughput at the cost of added links. With
>> packet switching the whole bandwidth is available to all connections
>> so nothing is wasted.
>
> Yeah, but networks don't have seek time, do they? ;-)
Um, yes. But they have latency, roundtrip times etc. and a SAN has
actually also seek times. :-)
Cheers
robert
Navigation:
[Reply to this message]
|