Or is the best option, to create a kernel core dump and analysis accordingly?
Well top would be the traditional process viewer. Apparent there is a ktop for KDE which would be a graphical version. What features do you require from the tool and we may be able to choose a better solution.
Well on a linux system iotop will display which processes are generating io.
By "Identify CPU-intensive functions." I assume you mean which processes are using CPU and memory in which case top is probably the default answer.
It might be worth explaining the problem you are trying to solve rather than what tool is equivalent to a windows one :)
If you want to know more about a single process then examine /proc/PROCESSID/ eg /proc/14232
Solaris has a plethora of performance monitoring tools available including Dtrace which is very handy for program debugging also.
If your goal is to determine which processes makes the computer to consume more power, use 'powertop'. Here's an example of its output:
Top causes for wakeups: 23.0% (112.4) amarok : schedule_hrtimeout_range (hrtimer_wakeup) 15.6% ( 76.0) : pata_jmicron, uhci_hcd:usb3, nvidia 9.6% ( 46.8) : HDA Intel 7.1% ( 34.6) firefox : futex_wait (hrtimer_wakeup) 4.5% ( 21.8) : eth0 3.9% ( 19.2) : ehci_hcd:usb2, uhci_hcd:usb6 3.9% ( 19.2) USB device 6-2 : USB Receiver (Logitech) 3.5% ( 17.2) : Rescheduling interrupts 3.4% ( 16.4) kwin : schedule_hrtimeout_range (hrtimer_wakeup) 3.3% ( 16.0) : usb_hcd_poll_rh_status (rh_timer_func) 3.2% ( 15.6) skype : schedule_hrtimeout_range (hrtimer_wakeup) 2.6% ( 12.6) psi : schedule_hrtimeout_range (hrtimer_wakeup) 2.2% ( 10.6) : ahci 2.1% ( 10.4) ktorrent : schedule_hrtimeout_range (hrtimer_wakeup) 2.0% ( 10.0) skype : do_nanosleep (hrtimer_wakeup)
What you seem to want is a combination of vmstat, iotop, sysstat/sar, and powertop, just like mentioned above. However, you want to stay away from large utilities (htop, dstat), because they will skew the very data you're trying to observe. When you run top, what is usually the most busy process? TOP! That violates scientific principles of observation. You want your probes to be as lightweight as possible.
The most you can usually learn about where the process spends most time by running it through ltrace and strace. If most time goes to userland numbercrunching, you cant fix it unless you redo the algorithm. If most time is spent in system calls, you gotta see what and how you're using OS resources, maybe you're waiting on locking to get done, or you're forcing filesystem flushes too often. There are no hard rules for this stuff, just run all the usual utilities and see which one blinks something meaningful at you. Knowing your syscalls and error calls especially when reading strace reports can be extremely enlighting too.
