This should not spike your CPU:

SELECT count(*) FROM sys.dm_tran_locks WITH(NOLOCK)

Run it on both machines and compare the numbers. Almost idle system is a very different situation than a busy server.

SQL server will have much more locks to wait for, much more memory allocated by connections (and thus memory will be probably spread across several NUMA nodes that additionally slows down the CPU when it wants to access that memory), different execution plans, different IO pressure, memory pressure, basically everything is different if the load is different.

Other thoughts:

If you only have 20 active connections for 12 000 opened connections - that is overwhelming number of idle connections and you have to reduce that number. You can do that by adjusting connection strings to open less connections initially, and all the clients should use one (or very few) connection strings. Because each connection string that is different by other connection strings even by one letter or one space - will start a new connection pool with initially opened connections that are idle.

Here are the connection string parameters for System.Data.SqlClient namespace, SqlConnection class's ConnectionString property: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx

CXPACKET wait means you have parallelism involved, and one thread has finished before others and waits for others to finish. It can be controlled at system level by max degree of parallelism parametar, or on query level with MAXDOP hint. In DWH it makes sense that maxdop is 0 (auto) or more than 1, but in OLTP you probably want set that parameter to 1!

Can you describe that CPU spike little more? Is it really a "sipke" (a very short, sub-second period of time with very high activity)?

By "90% CPU" you mean:

a) one CPU usage climbed to 90% for a very short period of time

b) all 80 CPU's climbed to 90% (for a very short period of time)

c) 72 CPU's climbed to 100% and 8 CPUs were idle (which gives total cpu 90%)