On 09/16/2014 10:01 AM, Ski Kacoroski wrote:
> On 09/16/2014 08:39 AM, Alan Robertson wrote:
>> On 09/16/2014 09:12 AM, Ski Kacoroski wrote:
>>> Hi,
>>>
>>> We installed a new student records system over over the summer that
>>> runs on MS SQL server. Everything seems to be ok, but for one thing
>>> that I am not sure is an issue waiting to bit me or something I can
>>> ignore. On the SAN, the volume for the transaction logs has 125ms
>>> read response times (write response times are around 2ms). This is
>>> the only volume on the SAN with such large response times. Has anyone
>>> seen this before and if so, is it something I need to be concerned
>>> about.
>> Since write times are fast, then it's not likely a SAN congestion
>> issue. Is the transaction log RAID5? Are there rebuilds in progress?
>>
>> 125ms is really really slow. It's about 10x slower than the real
>> underlying disk - including seek times. Unless you have a rebuild
>> underway, it sounds broken to me.
>>
>> If you can afford it (and you probably can), I'd recommend RAID10 for
>> transaction logs - or even RAID1 SSD (even though it's pricey,
>> transaction logs aren't usually huge).
>
> The disks are RAID1+0, 10k.
Sounds perfect.
> And yes I agree something is fishy here as this the only place I see
> the problem on the SAN.
"Busted" is the technical term that comes to mind. Usually, reads are
big (I would imagine they read in the entire log when doing a commit).
Keep in mind those writes are just to (non-volatile) cache, not to disk
- so they will tie up the disk later without showing in write latencies.
Is this a raw partition? Or is there a filesystem under the logs?
>
> We are no where near the maximum IOPs on the array so that is not the
> problem.
If you were, it would likely slow down writes to cache too. I hope your
write cache is nonvolatile - because otherwise that's way too fast for
writes.
>
> I am not sure about SAN disk alignment - I will check on this with the
> vendor.
Don't see how that could be causing this magnitude of problem. But you
might check on the filesystem (if any) for that partition.
-- Alan Robertson
[email protected]
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
