Monitoring IO performance

[neuralnode]

Hi All,

As in the title. What to use?

I have a 2-node cluster (SC 3.2) with latest update of Solaris 10 running. There are 20 Oracle databases running on both nodes, and the used filesystem is VxFS.

The goal is to provide IO utilization statistics over a 14-day period.

I tried to use vxstat, but for some reason if I run it in the background, the data collection stops after 2 hours or so.

Today I also came accress a tool called JKstat, but I'm not really sure how to configure it (do I need Apache/Tomcat running on the server? Should I use X-Window forwarding?).

So my questions are:
1. What tool would be best for the job?
2. How to quickly configure JKstat?

Thanx in advance!


--

 

[bluedragon2]

Since you are running Oracle Databases, I would suggest Oracle GRID control which not only is good for monitoring your databases, but also gives performance data that you are looking for as well.

[Blue]Blue[/Blue] [Dragon]

If I wasn't Blue, I would just be a Dragon...

 

[Annihilannic]

In the past I have used vxstat in combination with a graphing tool (MRTG in that case, these days I would use rrdtool). It's quite a manual way to do it though and requires some scripting effort and ongoing maintenance.

I'm curious about the 2 hour thing though since I've never had that problem; what options are you using with vxstat? Could something else be killing it? Are you running it with nohup or from cron?

Annihilannic
[small]tgmlify - code syntax highlighting for your tek-tips posts[/small]

 

[tarn]

Have you tried the Sun Support GUDS script ... this may not solve all your problems but does provide a substantial analysis output ...

Note:

http://solarispedia.com/index.php?title=Script:Solaris_GUDS

Also this explains at high level what GUDS can do for you ...

http://solaristroubleshootingtips.blogspot.co.uk/2011/01/solaris-tools.html[/URL]]
Sun 'Add-on' Tools - GUDS

GUDS is a wrapper script around Solaris native commands, though it is actually much more. It collects data periodically, based on input parameters, and places data into output files with time stamps. The breadth of data collected with GUDS and the administrative accounting of the output files by the GUDS scripts are the two reasons it is a key tool in many performance related issues.

The following GUDS command line will collect data for approximately an hour ((10 samples at a 30 second interval) x (12 iterations) =~ 60 minutes):

# ./guds_<version_number> -q -w0 -c30 -i10 -n12 -s<Sun case number>

To collect 'extended' data, the following command line is used:

# ./guds_<version_number> -q -X2 -w0 -c30 -i10 -n12 -s<Sun case number>

In both cases the output, including a compressed file that can be transferred to Sun for analysis, is place in /var/tmp/<Sun case number> directory. In the latter case, the extended option flag will make GUDS take longer to run than an hour.

IHTH

Laurie.

 

[Annihilannic]

Trust you to come up with the GUDS, Laurie.

Annihilannic
[small]tgmlify - code syntax highlighting for your tek-tips posts[/small]

 

[tarn]

Annihilannic (MIS)
20 Mar 12 2:26
Trust you to come up with the GUDS, Laurie.

Well we had some strange "latency" issues with one of our 3.1 clusters and we eventually tied it down to one of the VXvM disks slow to write which in turn cause the volume on the other side of the mirror to pause/wait until that write was completed. Sun asked me to run GUDS (along with a small script to simulate the application writing to disk) which soon highlighted the issue

Crazy thing was that just removing and reseating that same disk was the eventual resolution (though we did replace the disk initially)

As I say GUDS may provide more than you were really looking for but you can always filter the results

Laurie.