Commit: 53f2c67d8c8c9a78f488db9f62e188f33d29c340 Tree: 3677ab064c999ab5972334fb9be2b0de7ca4d3ed Parent: 1d24df4c9f8daaff008821863205cb18a2e09420 Author: Karl Rister Thu, 13 Nov 2008 20:07:59 -0600 Committer: Karl Rister Thu, 13 Nov 2008 20:07:59 -0600 Add an experimental new profiling infrastructure. This new profiling harness enables several key enhancements beyond the current implementation. Features such as key=value parameter passing, the ability to run multiple invocations of a single profiler simultaneously, and the ability to elevate the scheduling priority of a profiler are now possible. There are plans for additional features that are not yet implemented as well. The key=value parameter passing is an important feature to enable options to easily be passed through to a profiler script. The current method of using global variables is cumbersome and in some instances (such as foreign-profiler) does not work. Multiple invocations allows for a profiler to be targeted at a specific piece of data (such as the I/O performance of a database log device using iostat) while still maintaining a high level profiler that gives a system wide view. Elevated scheduling priority can be used to raise the priority level at which a profiler runs in order to ensure that the profiler does not experience starvation on a loaded system which can lead to lost data samples. This experimental commit enables these features for two profilers initially which are iostat and mpstat. More will follow but these profilers are fairly simple which makes implementing these advanced features easier. The new profilers are controlled using two new management scripts named 'activateprofiler' and 'deactivateprofiler'. An example of how to use this in a dat file is: activateprofiler profiler=iostat activateprofiler profiler=iostat interval=1 id=1 devices=/dev/sdb activateprofiler profiler=iostat id=logger devices=/dev/sdc ... deactivateprofiler profiler=iostat id=2 In this example three invocations of the iostat profiler would be used. The first invocation defaults to using an id of 0 and will generate data in $LOGDIR/analysis/iostat.0.$RUN_NUMBER using the default interval (5 seconds) and for the default set of disk devices (which is all). The second invocation will use an interval of 1 second and only record data for the /dev/sdb device and uses an id of 1 meaning its data will be logged into $LOGDIR/analysis/iostat.1.$RUN_NUMBER. The third invocation uses the default interval but only profiles the /dev/sdc disk device. This invocation also makes use of the ability to use arbitrary identifiers for the id paramter. This allows the data to be logged into $LOGDIR/analysis/iostat.logger.$RUN_NUMBER. Further down the dat file the third invocation is disabled using the deactivateprofiler command. The only caveat to the use of an arbitrary invocation identifier is that if no identifier is specified or the identifier is specified as '0' the default invocation will be overridden. In the current implementation, the $RUN_NUMBER defaults to 001 and will not support anything else. This is due to the nature in which paramter passing is being changed. This will eventually be resolved. Author: Karl Rister