I'm currently working on a project with a fairly impressive (some might say I'm using the wrong word here, that "ludicrous" might be more appropriate) track count.  I essentially use Sonar X3 as an unlimited multitrack recorder (no soft synths at all), but there are a few plugins on some tracks.  I am currently at 97 tracks, and it's likely that this project will exceed 150 tracks by the time we're finished with it (we are trying to achieve a pretty dense sound).  I am a firm believer in reamping, so every guitar track on this project (and there are LOTS of guitar tracks) has a corresponding direct track so that if the band decides they want a different sound later on, we can simply reamp without having to re-record.  Probably half the tracks are scratch tracks, and all those tracks have been archived, along with all the direct tracks.  Yesterday, Sonar started halting on one particularly dense section of the song, and I noticed that the Disk I/O icon had gone red.  I monitored the disk I/O, and it was hovering between 60% and 88% most of the song, but upon attempting to play that section, went to 100%, and Sonar would just give up.
 
I've been poking around here on the forums this morning, and found a couple of posts about I/O buffers, which were set to 256 for both recording and playback.  I doubled the recording buffers (512) and quadrupled the playback buffers (1024) and disk I/O dropped pretty dramatically.  I then doubled each of those values (1024 recording, 2048 playback) and the disk I/O dropped even more (now around 25-30%).
 
Prior to reading on the forums, I was prepared to buy a faster hard disk (the disk I'm currently recording on is a 1TB 7200rpm SATA drive, and yes, I have the scratch disk on C: and the track disk set to D:) to alleviate the problem.  Now, with the improved I/O numbers, I'm thinking that isn't necessary.  But I read that increasing the buffers can lead to other issues.  What might some of those issues be? Did I raise the buffers correctly?  Should the recording buffer be higher than the playback buffer, since I'm trying to play all zillion tracks while recording two new ones?
 
Thanks to anyone who can lend insight to this issue and these questions....and thanks for reading....
 
Paul
 
PS...this is my first project with this band, and the leader of the band is a well-know artist in my area.  He used to run one of the more popular and successful studios in the area, and I'm trying to convince him he should continue to work with me (this is a hobby, we're both a million years old, neither of us is gonna make any money off this project), and once we're finished with the project, I'd like to maybe find some other clients to work with, so this project's success is very important to me.  I'm working with people who have 30-40 years of professional musicianship under their belts.  On a side note, they are all blown away with what we've recorded so far...several people have commented that they are surprised that something of this quality came from a "home studio".  So far, Sonar has impressed a LOT of people, most of whom are Mac users using ProTools.
 
Specs:  Sonar X3e Producer on home-built dual Xeon quadcore server motherboard, 8GB RAM, Mackie 1640i audio interface.

It's quite normal to have 2 different buffer settings - low for recording and higher for mixing/playback.
 
Another option when recording is to simply bypass all your Fx (hit 'e'), especially if you use any plugins which rely on lookahead or cpu intensive plugins like convolution reverbs

Also you can freeze tracks you are not going to adjust (except for say volume / panning) - you can quickly unfreeze if you need to work on the track again
Nigel
 

I believe the OP is asking about disk I/O buffer settings which at least for me do not get changed based on the project activity like the ASIO buffers and while freezing can reduce RAM and CPU load has the potential to increase disk I/O.
 
In my case disk I/O buffers settings are set and forget. Don't have any experience with extreme settings and do not recall reading any recent experiments with large values.

Whilst this may sound a little silly some recent research I did revealed that XEON CPU's and Motherboards are not really suited to music production.  Most music software is not optimised to take advantage of the XEON functions and they may in effect be missing some of the advantages of the i7, i5 and even i3 processors.

I would second Bristol_Jonesey's and Baja Blue's comments to reduce CPU load.

You just need to keep the Read/Write i/o buffers high enough to avoid dropouts. I generally keep mine at 512 (for both) and can slog through what I need to. I'd say you are going to extremes unnecessarily. Try going back to 1024 if you are that concerned but 512 on a decent system with fast drives (7200rpm is recommended for HDD's... SSD's don't spin so it doesn't matter).
 
There are lots of tricks though to avoid having to futz with i/o buffers.
 
One is "Freezing" any tracks you don't need to adjust effects on (or for softsynths it removes them from the system resources). Once you are done tracking and want to adjust effects again/edit your MIDI tracks just "un-Freeze" the tracks.
 
However maybe an "Export" and "Archive" procedure would work better for you. Essentially get a mix that your performer likes and that they can play/sing over, do a stereo mixdown of it and put it in a special "Mixdown" track. Label the take lane you put it in so you know who it's for (like "Vocal Backer" or "Guitar Backer"). You can make these exports for every artist in the band as you work.
 
Then use the "Archive" button on all the other tracks which not only removes all the synths and effects from the system resources it takes all the audio clips out of system resources as well (which is what ACTUALLY hurts your disk drives far mre than effects and synths AFAIK... this is particularly true if you have a lot of comping/edits in each track).
 
So now your project is playing back ONE track from ONE clip while you record your live parts instead of dozens. It will completely ease up on the system.
 
Once the tracking is done just "un-Archive" the original tracks for mixing or creating new mixdowns for the band to track to.
 
You could also use that method but instead of making a single stereo mixing do Bus "stem" exports that have all your bass on one export, all your drums on one export, all your rhythm guitars on one export, etc. Archive all other tracks like I said before leaving just those bus exports active.
 
That way instead of dozens of tracks all with effects going you have maybe 5 or 6 track with NO effects... BUT you can still adjust volume levels for the performers on the fly.
 
These techniques are almost like the old "Ping Ponging" we used to have to do with 4-8 track tape based multitrackers.... well almost but not quite.
 
Hope that helps.
 
Cheers.

Spinning hard disks are good (fast) with small numbers of large files but struggle with large numbers of small files.
 
While the disk spins fast and sequential data can be read fast, the speed of the head moving is very slow (by comparison) so every time the read head moves to a new area of the disk to read a different file (different guitar track) time is wasted.
 
Increasing the I/o buffer size makes Sonar load more from each file on each read, so the disk spends more time reading data and less time moving the read head around.
 
The issue is avoided by using SSD not HDD.

Thanks for everyone who responded.  I've bumped both back down to 1024 and will stand with that setting for a bit.  Again, not CPU bound, so turning off effects and plugins hasn't mattered (tried it, with buffers set to original values, and playing the tune failed at the exact same spot).  Hadn't considered mixing all existing tracks to a "scratch" track while recording...might be worth investigating...this is probably the only time I'll ever have anywhere close to this many tracks in a tune (all previous tunes have peaked at around 50).  And maybe freezing all the multi-take tracks will get the unused takes out of the equation.
 
Again, thanks for the responses!
 
Paul

Don't discount the power of degrag.  With that much audio, I wouldn't be surprised if a defrag improved things for a bit.

+1 for defrag, especially an "optimized defrag" which consolidates data. Files (and worse fragments) "all over the disk" can lead to very noticeable read times.

Unfortunately, disks tend to write in the first location available for speed purposes, so defragging HDDs is a good practice.