Daily CPU and memory statistics on Windows server

table_cache is the most useful configuration directive to change. Each time MySQL accesses a table, it loads the table into cache. If you've got a high number of tables, it's faster to have them cached.

Take a look at your server variables by running:

show status;

and have a look for the variable open_tables. If this is the same as your table_cache value, and opened_tables keeps going up, then you need to increase the table_cache value in your configuration file. You'll find a balance by experimenting with these variables during peak times. You want to configure it so that at peak times, there are a low amount of opened_tables even after the server has been up for a long time.

key_buffer_size is also a good variable to experiment with. This variable affects the index buffer size, and making this variable bigger increases MySQL's index handling speed. You can look at the variables with the show variables; command again, and compare key_read_requests to key_reads. Ideally, you want the ratio between these two variables to be as low as possible, and you can do this by increasing the size of the key_buffer_size. If you set this variable higher, you will have less writes and reads directly to and from the disk, which was your main concern.

I don't have a specific tool recommendation for what you want, but at least as a quick-and-dirty you can probably cobble something together with a couple of the Sysinternals tools. You might be able to run this non-interactively (scheduled), but it definitely wouldn't be a service.

1. Use Procdump to monitor CPU usage of processes with the appropriate process name (based on the executable). When a process hits the configured levels, generate a dump. Possibly start this from a looping .cmd file with a slight wait so each instance of procdump will only dump a single time, or possibly use the -n option to specify a very large number of dumps before it exits.
2. Monitor your dump output directory for new files. Parse out PIDs as required, then kill the files or not - it doesn't sound like you're going to be debugging and fixing the app.
3. Use PsKill to kill the relevant process.

As with anything cobbled together, this may or may not work well or be stable in the long run, but if the preferred option (fix the problem app) isn't viable then you're reduced to the second string anyway.

The Sysinternals tools are now available from Microsoft at http://technet.microsoft.com/en-us/sysinternals/default