Wow! That's a lot of cpu utilization (avg 70-75%) for not much work (ie, no heavy proc compilations, relatively low cache hit rates).
------------
Were these sp_sysmon's taken during a period of normal activity in the dataserver?
If so, you've got way too many engines configured on this dataserver, which in turn can lead to contention issues with internal structures ... and in some cases trigger known problems with MDA settings in high engine count environments (eg, I've seen a couple cases where a) low activity, b) high engine counts and b) active object lock wait timing caused excessive cpu utilization across all engines, disabling object lock wait timing eliminated the heavy cpu utilization).
Unless you've got a *LOT* more activity (eg, 3-4 magnitudes more than shown in these sp_sysmon outputs) during other parts of the day, I'd want to rethink the number of engines (ie, scale down quite a bit).
If you are using MDA/object lock wait timing, and disabling the setting doesn't reduce cpu utilization, I'd suggest opening a case with Sybase tech support to see if there are any other known issues that could be causing the high cpu utilization on your dataserver.
------------
The vast majority of your disk IOs (eg, 80K-330K non-APF reads, 30K-40K writes) are on the logdev4file (/u01/log/lodev4file.dat) device. And mirroring is showing a high contention rate on the mirroring semaphore.
Is logdev4file the log device for the database where the rollback is taking a long time to complete? And was a rollback occurring during the time of these particular sp_sysmon sessions?
Keep in mind that 15% of 32GB = 4.8GB (which is quite a bit of log space for a 'short' running txn that has to be rolled back. Your workdb_log (I'm assuming this is the cache your log is bound to) is 5GB in size and has 2 partitions.
From what I see here, and assuming a rollback was occurring during this time, it looks like one major delay for the rollback is the need to read old log pages from disk (high read counts on logdev4file).
A few suggestions going forward ...
1 - find out why the used log space is so large for a short-lived transaction (??); I see the 'Replication Agent' data has been removed from the sp_sysmon sessions ... why ??? If you have a repagent running in this database (where the long rollbacks are occurring), then I'd suggest checking to make sure there are no problems with the speed at which the repagent is able to process the log (eg, could the relatively large used log space size be due to a 'slow' repagent?).
2 - consider increasing the size of the workdb_log cache, and probably reduce the partition count to 1; the objective is to insure more of the log is maintained in cache so that you can greatly reduce, if not eliminate, the volume of reads against the log device during a rollback; how much larger you make the log will depend on how large the log can get when a rollback is triggered
3 - take a look at the service times on the logdev4file device (either via MDA monDeviceIO table, or at the OS level); your log device should be one of the fastest devices in the dataserver ... so make sure you're not suffering from excessively slow device IO rates
------------
The sp_sysmon/disk output shows you've got mirroring enabled. While this doesn't appear to be a major issue (eg, not a lot of disk IOs at the time of these sp_sysmon sessions), I'd want to eliminate the overhead required to maintain this setting.
If you're not actually using mirrored devices I'd suggest disabling disk mirroring (disable disk mirroring = 1; this requires a dataserver reboot). This should eliminate any performance issues you're having with the mirroring operations on the logdev4file device.
-----------
I'd still be interested in the details of the workdb_log cache (sp_cacheconfig, sp_helpcache). You've got a good bit of spinlock contention on this cache for not very much activity ... would be interesting to get more details.
Message was edited by: Mark A. Parsons