As TomTom said this is almost certainly an indication that your system is IO bound not CPU bound. The root cause might just be the increased load DB behind your CMS or it might be something else but in any case PerfMon has some useful counters to look at that can tell you for definite if the disk subsystem is the cause.
\LogicalDisk\Avg. Disk Sec/Read and \LogicalDisk\Avg. Disk Sec/Write
These are your basic latency numbers for read and write IO operations, the lower the better. Anytime these numbers exceed around 15ms the performance of the server will be noticeably poor.
\LogicalDisk\Disk Bytes/Sec and \LogicalDisk\Disk Reads/Sec and
This will tell you overall disk throughput. These rates may be saturating the maximum capacity of the disk subsystem either due to throughput alone or because you've hit an IOPs limit for your read\write pattern. It can be hard to deduce anything significant from these unless you are 100% confident that you have a predictable IO pattern though. Thhere's no really useful way to give any specific number to watch for here but if you are seeing 50-100MBytes/sec or more off a single SATA disk that would be about as good as you could expect to see. Faster server disks (10k, 15K, SSD) can exceed that and SAN attached storage can deliver pretty much whatever you want provided you pay enough. With small random IO (typical of DB operations) this number will always be low and doesn't tell you much.
\LogicalDisk\Disk Writes/Sec, \LogicalDisk\Disk Reads/Sec and \LogicalDisk\Disk Transfers/sec
These will tell you the number of discrete IO operation per second and the Read\Write ratio. Spinning disks are fairly limited in this regard - 7.2K SATA disks can sustain around 70-80 IO per second, 10K disks push that up into the 100-150 range, 15K will be 200+. SSD's will be an order of magnitude or two higher. RAID groups increase this fairly linearly for reads but Writes will incur a penalty of between 2 and 5. A 3 drive RAID 5 pack (with a write penalty of 4) supports about 25% fewer write IO's than a single drive for example.
If this number tends to increase while latency is increasing into dangerous territory (ie > 15ms) it is a strong indication that your disks are hitting an IOPs limit, regardless of the specific numbers reported.
\LogicalDisk\Split IO/sec
This will tell you how many IO requests result in multiple operations and will give you a sense of how much fragmentation is impacting IO activity.
PhysicalDisk : Current Disk Queue Length and PhysicalDisk : Avg. Disk Queue Length.
This tells you how many outstanding IO's are waiting to be completed at the physical disk level. If this is 2 or higher on a single disk, or exceeds the number of disks in the RAID group that the disk is built from then you may be pushing more IO's into the disk than it can complete in a timely fashion. There are scenarios where this doesn't matter too much but it will be a real killer for systems that require low latency disk IO (databases where memory caching can't cover the weakness of the disks). The first is an instantaneous reading so only worry about it if it is consistently high or changes in line with the %disk time counter. If the Avg. Disk Queue Length is too high then you definitely have a problem.
PhysicalDisk : % Disk Time
% Disk time tells you how busy the disk is. As it approaches 100% you are going to struggle to get the system to do anything else that depends on that disk as all additional IO will tend to be queued. Even numbers significantly below 100% can indicate an issue and if this is high, or rising, and Current Disk Queue length is high that is a clear indication of an IO load that exceeds the capacity of the disks. This number is actually calculated in a weird way and as a result might not be all that useful in analysing RAID performance.
This Technet Blog Article goes into a lot more depth on some of these counters and some scenarios where you can use these to identify the problem and establish how to fix it.