write performance on global mounted se6920 ufs

Hi,

We抳e a 3-node e2900 cluster with se6920 storage into production primarily as a database server.

The database is performing as fast as we expected and no complaints there, however we are noticing some behaviour on the globally mounted ufs partitions that we did not expect to see?br>

Writing log files to the global storage is much slower by comparison to writing log files locally on the system disk. We do open and close the log file each time so I guess there has to be some read going on each time?and the log files can grow up to 20mb.

Maybe this is not so strange? It could be that we just have tuned the se6920 for our Sybase application to the detriment of this type of I/O?br>

SE6920 profile properties:

Profile:

Description:

RAID Level:1

Segment Size: 64KB

Read Ahead:off

Optimal Number of Drives: variable

Array Type:Best Available Match IOPS

Virtualization Strategy:concatenate

Dedicated Hot Spare:no

Profile in Use:yes

Factory Profile:no

Unfortunately, apart from running a few iostat commands and comparing the times it takes to write log files to local and global ufs?I抦 not too sure how I can determine if there is some configuration issue here.

Does anybody know if there is some way to verify what is happening on the se6920 ufs partitions? - there is no measurable differences for cp files ranging from 10mb to 2 gb between the local and global partitions.

Here are some iostat results for writing a 500k log file (opening/closing for each line appended):

Local (svm d40):

Time: 32s

Sample iostat:

r/sw/skr/skw/s wait actv wsvc_t asvc_t %w %b device

0.0 273.00.0 4366.4 0.2 60.80.6 222.7 15 98 d40

0.0 377.40.0 6035.0 0.0 2.00.05.40 77 d40

0.0 421.20.0 6701.1 0.0 2.20.05.21 69 d40

0.0 292.20.0 4036.7 0.1 135.10.4 462.2 13 94 d40

0.2 253.81.6 3152.1 0.6 426.32.3 1678.2 57 100 d40

0.0 277.60.0 4011.7 0.4 102.61.6 369.6 43 100 d40

0.0 178.00.0 1592.0 0.1 210.80.3 1184.45 99 d40

0.037.40.0 299.2 0.0 17.00.0 455.80 32 d40

Global (c5t600015D000042D00000000000000110Dd0) :

Time: Had to stop the logging application ?had only completed 43k lines in 17mins

Sample iostat:

r/sw/skr/skw/s wait actv wsvc_t asvc_t %w %b device

0.010.60.028.4 0.0 0.00.01.802 c5t600015D000042D00000000000000110Dd0

0.012.20.056.6 0.0 0.00.01.502 c5t600015D000042D00000000000000110Dd0

2.810.49.440.1 0.0 0.00.01.402 c5t600015D000042D00000000000000110Dd0

3.022.212.4 100.0 0.0 0.00.01.704 c5t600015D000042D00000000000000110Dd0

2.610.810.033.5 0.0 0.00.01.202 c5t600015D000042D00000000000000110Dd0

2.614.210.271.2 0.0 0.00.01.702 c5t600015D000042D00000000000000110Dd0

3.018.212.266.3 0.0 0.00.01.303 c5t600015D000042D00000000000000110Dd0

3.018.412.666.5 0.0 0.00.02.004 c5t600015D000042D00000000000000110Dd0

0.615.43.241.3 0.0 0.00.02.103 c5t600015D000042D00000000000000110Dd0

0.017.60.0 124.0 0.0 0.10.03.606 c5t600015D000042D00000000000000110Dd0

0.27.21.216.4 0.0 0.00.02.001 c5t600015D000042D00000000000000110Dd0

0.014.80.046.8 0.0 0.00.01.803 c5t600015D000042D00000000000000110Dd0

0.424.02.084.1 0.0 0.00.01.703 c5t600015D000042D00000000000000110Dd0

0.419.41.869.5 0.0 0.00.01.503 c5t600015D000042D00000000000000110Dd0

Thanks for your time!

Trevor

[3471 byte] By [trevor_tec] at [2007-11-26 10:07:32]
# 1

The solution you are dealing with here is quite complex and expensive! To think that it would be freely supportable through a user to user forum is simple-minded in the extreme ( this remark is not intended to offend anyone ).

Some research on this issue led me to the following document:

http://www.sun.com/software/whitepapers/wp-globalfileservices/wp-globalfileserv ices.pdf

I found it very informative, I know it is not the latest version of Sun Cluster software, but it does explain the CFS architecture very well. I think the combination of the write token system overhead and heavy IO profile of writing logs to the global file system are slowing performance down. ( As you mention yourself it is recommended to do logs locally ).

Considering your investment in this solution I would suggest that you have the solution's performance analyzed professionally. There are a number of tools currently available free of charge, but my recommendation would be either Sun vdbench and the Storage Workload Analysis Tool ( SWAT ) or Ortera Atlas ( http://www.ortera.com/ ). The Sun product is only available through a Sun service engineer or authorized partner, but I think the vdbench tool has some very unique features, it can recreate a workload to emulate an application I/O profile. Atlas is a 3rd party storage analysis tool, by that I mean that it is independent of any storage vendor ( a major plus from a quality control standpoint ), and the depth of information obtained using it is substantial. Here is a blog from Adrian Cockcraft ( Solaris tuner supremo ):

http://perfcap.blogspot.com/2005/08/solving-storage-tuning-problems.html

mlennon at 2007-7-7 1:47:56 > top of Java-index,Storage Forums,Storage General Discussion...
# 2

Hi, thanks for the feedback. We have opened a support case with Sun at the time and when we get some answers I will update this post.

I guess I just posted this here in the forum also for my own benefit as others may have had similar issues and like in the case of the reply from m-lennon I got some useful links and comments...

trevor_tec at 2007-7-7 1:47:56 > top of Java-index,Storage Forums,Storage General Discussion...
# 3

Yes, I would be interested in reading any additional information you get on this issue. The main thing to keep in mind is that the midrange systems are better supported directly through Sun or an authorized partner, your investment in the solution and the hardware is considered to be too great to be trusted to the user to user forum. This is not to say that people using this forum haven't the ability to support the hardware, but if you were misinformed about configuration and it compromised application availability or further degraded performance, you could impact the solution warranty from Sun!

mlennon at 2007-7-7 1:47:56 > top of Java-index,Storage Forums,Storage General Discussion...