Connection issues during a drop in CPU usage I have a challenging issue that I am facing and would like to lean on this community for advice and possibly answers to this issue.

We are running a dedicated server: Windows 2008 R2 64bit OS, 32 GB of RAM.
Our SQL Server version:  MS SQL Server 2012  (11.0.3000).

Intermittently our server will drop to 0-5% CPU usage, during that time our applications have a hard time (or just cannot) connect to the SQL Server.  Further, within the database logs I am reading this:


  FlushCache: cleaned up 12007 bufs with 100094 writes in 130307 ms (ovoided 667 new dirty bufs) for db 7:0
  last target outstanding: 4, avgWriteLatency 44
  average throughput: 0.41 MB/sec, I/O saturation: 12161, context switches 25796


The above logs are written several times per day, however a few of these instances occur when our CPU drops to an extremely low rate.  Our CPU for this server normally runs around 30-60% during business hours and I have never seen it drop to this level. 

The only major changes have been an update in RAM from 16 GB to 32 GB.  There were some updates to the maintenance backups, but those fire at 12AM (PST).

I am available to add any further logs or information and am extremely grateful for any help concerning this issue.
It sounds somewhat like you are hitting a bit of memory pressure. Dirty Buffers are pages in memory that have changes in them that have not been written to disk yet. Normally they would stay in memory until one of the various processes clean them up and/or write them to disk.

There are some things you will want to look into but with only the information you have given here I have to ask, "How much ram have you reserved for the OS?"

You are running a 64 bit version of Windows. Now, the 32 bit kernel will use 4 GB of RAM. However, we have found (the hard way) that 64 bit versions of the OS will use 8 - 12 GB of RAM dependent on how busy the Sql server is. By that I mean are you doing a lot of reading and writing to disk. If the OS can't allocate the memory it needs for this (because the Sql server has sucked it all up) you will see the CPU being consumed for the additional context switching it needs to do to write those buffers out to disk. When you added the additional RAM to the server did you reset the Sql Server Max Memory setting? When you only had 16 GB of RAM your Sql server was constrained as much as the windows kernel was and so you were likely using virtual disk (hard drive space) quite a bit. When you added more RAM you opened things up a bit and now the Sql server is attempting to keep more of the database(s) in memory.