HPE Storage Users Group

A Storage Administrator Community




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: SSD write service times
PostPosted: Wed Jul 19, 2017 6:33 am 

Joined: Tue Oct 21, 2014 3:26 am
Posts: 55
I have an 8200 with 8x 1,920 SSDs. Just one CPG with TPDD volumes.

During a normal working day, looking at the Exported Volumes perf reports, write service times never goes above 0.3ms. Looking at the PD perf reports over the last two months, write service times are slowly creeping up towards 2ms, a few peaks above it. From what I can see write IOs have increased over the last few months, no change in IO size, so I assuming its an increase in workload. I also don't see any delack during this period.

So my question is, if I'm not seeing high service times at the vlun level and no delack, PD service times floating around 2ms is not a concern?


Top
 Profile  
Reply with quote  
 Post subject: Re: SSD write service times
PostPosted: Wed Jul 19, 2017 4:23 pm 

Joined: Mon Feb 01, 2016 12:55 pm
Posts: 51
it depends on the services using those volumes. some are ok with high latencies, some are not.

to give you a comparison our busiest 8200 with 480GB SSDs and tdvv has PD service times around 4ms and export volume service times between 4-10ms (we use iSCSI). no complaints about performance.


Top
 Profile  
Reply with quote  
 Post subject: Re: SSD write service times
PostPosted: Thu Jul 20, 2017 3:29 am 

Joined: Tue Oct 21, 2014 3:26 am
Posts: 55
Its a VDI environment. Performance problems have been reported. However, looking at host port stats and exported volume stats, they never appear to go above 0.3ms. The only thing I've noticed is the PD service times creeping up and after taking a closer look, seeing some delack during the end of the day (an average of 3 in an hour sample).

If PDs are struggling with writes I would expect to see host service times to increase?


Top
 Profile  
Reply with quote  
 Post subject: Re: SSD write service times
PostPosted: Thu Jul 20, 2017 4:44 am 

Joined: Wed Nov 19, 2014 5:14 am
Posts: 505
Usually the first indication of a performance problem will be high service times at the VLUN, first and simplest place to check is the back-end PD if it's overloaded then bingo, if not then you can start moving up the stack. So it's always good to have a baseline of your PD's i.e. what does normal look like for when something abnormal happens.

In this case you have low service times on VLUN's so nothing to worry about. The odd delack shouldn't be an issue and could be caused by transient stuff related to the business or internal system processes, so long as you aren't seeing sustained delacks accumulating rapidly then you should be fine.


Top
 Profile  
Reply with quote  
 Post subject: Re: SSD write service times
PostPosted: Thu Jul 20, 2017 4:50 am 

Joined: Tue Oct 21, 2014 3:26 am
Posts: 55
Thanks.

I'm starting to go back in months to get a trend. I've noticed recently, one particular volume write I/O size is quite large so could be the cause of the increase PD write service time.

I do see on this 8200 a defrag system task constantly running. Do you think this could have contention? Or is it a low priority task?


Top
 Profile  
Reply with quote  
 Post subject: Re: SSD write service times
PostPosted: Thu Jul 20, 2017 6:52 am 

Joined: Wed Nov 19, 2014 5:14 am
Posts: 505
Even for large block sizes 3PAR will break these up into 16KB pages so larger block sizes won't necessarily translate to higher PD service times, but it will depend on the intensity (IOps). Backend service time isn't a great indicator as other system tasks like garbage collection will take available IO as it becomes available, but note the 8200 is the baby box so has less CPU, Memory, Bandwidth to spare for these processes. However they are throttled and will be masked by wide striping and cache, otherwise you'd be seeing an impact at the VLUN which really is the pinch point and where performance issues will be felt first by users.

If the users had a problem with storage it should be pretty evident at either the VLUN or host port level, so for now I'd just keep an eye on those baselines. If you were to identify a problem workload in the future, then assuming it can't be resolved at the host you could consider using QOS (now part of the all inclusive licensing) to limit bandwidth or IOps.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 


Who is online

Users browsing this forum: Google [Bot] and 116 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group | DVGFX2 by: Matt