Databases Reference
In-Depth Information
Retaining Performance Logs
Anytime you take performance logs, keep them for future reference. You never know when the next
problem may occur, and having historic log data available will enable you to make comparisons around
factors that have changed, either since the last problem or since the last baseline was acquired while the
server was operating normally.
Additionally, you could load the data from System Monitor logs into a database that will allow you to
query and report on the data for capacity planning. System Monitor provides the ability to log directly
to a database. However, the overhead associated with this is dependent on the target database server
being available and responsive. Often, recording performance data to a flat file and then importing into
a database is a more reliable approach that requires less overhead.
Patterns and Trends
Look to the future. Analyze the data you're collecting to establish any patterns or trends, and establish
a high-water mark and normal operations mark for each service on your servers with respect to the key
components. Once you know roughly what performance on your servers looks like, you can see how
performance is changing and attempt to estimate when you might need to upgrade.
Servers Suffering Very Poor Performance
If you're working on a server which is really suffering seriously poor performance, don't attempt to
run System Monitor locally. In this situation, run System Monitor from a remote server to reduce the
overhead on the target server. Additionally, reduce the sampling interval to every 10 seconds; even
every 30 seconds wouldn't be unreasonable in some situations.
If you can't monitor remotely (there could be security or network constraints), try to keep the number
of counters monitored to a minimum; this will restrict the impact of monitoring. You should also log
data to a file, instead of monitoring in graph or report view, as this can help reduce overhead. Remember
when you log to a file, this will likely increase disk activity. If you do decide to log to a file, try to find
an appropriate drive to log to. Try to avoid disks hosting the page file or the database or transaction
log files.
Tuning Performance
Take action based on your findings. Evaluate the server workload, tune your applications, and review
your hardware configuration and design to get the most from your investment. Once you've made
changes, re-run System Monitor to review the impact of the changes. Always retain your log files, and
keep a record of the date and environment setup (hardware configuration, relevant software levels, and
so on) when the logs were taken.
Being Proactive
Don't wait for users to call you. Configure Alerts to have servers notify you when they're running low
on resources. You'll need to define meaningful alert thresholds. For example, how busy does the CPU
have to be before it impacts user experience? Or how low on memory does the server become before
Search WWH ::
Custom Search