Often my first action in such circumstances is to run profiler interactively (locally if possible) to capture SQL with a CPU > zero. I tend to run it for 15-30 mins, or for 20,000-50,000 lines, whichever comes first.

Saving it to a development table for analysis thru SQL queries I've come across a query that did a table scan of a relative small table (eg. 10,000 rows). Although its individual CPU was too small to really stand out (eg. 25ms), the SQL analysis showed it had been called 13,000 times during the profiling period and accounted for 85% of the overall CPU. A quick index creation fixed the problem.

Of course, this may not be the problem in your case, but profiler is just an option to explore.