I have an application server which runs pervasive SQL and app using it. Last weeks the users are complaining about poor performace of the app and I suspect disk I/O problems because CPU and RAM usages are just fine.
Here are my resource monitor graphs and if you could please tell me how to properlly read them and if I have problems with disk I/O.
- Disk C: - system disk
- Disk E: - application with all its data
Disk queue length is usually the first place to look at. If it is just SQL on the disk (assuming it partitioned correctly) then a queue over 1+ is problem time unless you are doing massive disk based queries.
In the resource monitor that you have open, you can also expand down the section on the left and order by queue to see which application is hogging the disk.
If it is only SQL that is slow, perhaps you might be better looking at any slow queries on the server throughout the time period. SQL is also CPU bound in most applications I've worked with.
I doubt your graphs could be useful for the troubleshooting as they show throughput only.Also you did not indicate what is your storage setup.
Run perfmon with basic counters during problem period.Use PAL http://pal.codeplex.com/releases/view/51623 to analyze resulting logs, it should give you some graphs and warn you if you have performance problems.
To understand details, I suggest reading following articles: http://www.grumpyolddba.co.uk/monitoring/monitoring.htm ( section about counters) http://www.brentozar.com/sql/sql-server-performance-tuning/ http://www.sqlservercentral.com/blogs/sqlmanofmystery/2009/09/14/the-fundamentals-of-storage-systems-introduction/
If you want to check your disk I/O performance, you could install bonnie++ from EPEL repo. After installation just run bonnie as an unprivileged user. Bonnie will create and read a file on your disk to measure disk performance. This file will be considerably large, a few GBs actually. Bonnie will provide you information about latency, create time, read time etc both for sequential as well as random data.