[email protected] said:
> You can use the attached dtrace script to see what the interrupt CPU is
> doing.
>
> While the problem is present, run like this:
>
> #./kp1cpu cpuid > tmp.out <<<<< where the cpuid is the id of the CPU where
> mpt interrupt is registered or whichever you are interested in. #./inclexcl
> tmp.out > ie.out
>
> then you can check the text file ie.out to see which function consume most of
> the cpu cycles.
Thanks for those scripts. I had a look today while the system was busy
running relatively heavy I/O during an Oracle data load operation. Here's
the top of the "ie.out" list:
Inclusive Exclusive
Function nsamples pct nsamples pct
intr_thread 10286 98.44% 2 0.02%
px_msiq_intr 10256 98.15% 3 0.03%
mpt_intr 10249 98.09% 14 0.13%
mpt_send_pending_event_ack 10161 97.24% 10161 97.24%
mpt_doneq_empty 6524 62.44% 2 0.02%
mpt_deliver_doneq_thread 3589 34.35% 0 0.00%
thread_start 119 1.14% 0 0.00%
current_thread 100 0.96% 0 0.00%
mpt_process_intr 90 0.86% 12 0.11%
zio_execute 58 0.56% 0 0.00%
taskq_thread 54 0.52% 0 0.00%
mpt_doneq_add 29 0.28% 1 0.01%
fsflush 29 0.28% 7 0.07%
sdintr 28 0.27% 5 0.05%
cbe_level10 26 0.25% 0 0.00%
syscall_trap 25 0.24% 0 0.00%
cyclic_softint 25 0.24% 1 0.01%
zfs_write 24 0.23% 0 0.00%
pwrite 24 0.23% 0 0.00%
fop_write 24 0.23% 0 0.00%
clock 24 0.23% 2 0.02%
sd_return_command 23 0.22% 1 0.01%
fsflush_do_pages 22 0.21% 13 0.12%
zio_done 16 0.15% 1 0.01%
txg_sync_thread 16 0.15% 0 0.00%
spa_sync 16 0.15% 0 0.00%
. . .
I think equally as interesting as the number of CPU cycles would be the
amount of wall-clock time (latency) spent per call. Suggestions on
how one might accomplish that would be welcome.
> One thing should be pointed out is the firmware version on the hba has to be
> higher than LSI1.26.00, otherwise, the new feature will no yield higher IOPs
> than the original one.
We're at 1.26.3.0, the most recent I was able to find as of a few weeks ago.
> The new feature(interrupt fanout) + new firmware version can get maxmium IOPs
> from 70k to ~120k.
Yeah, if you have (fast) enough CPU's....
Thanks and regards,
Marion
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
