Sql-server – Windows Server 2008 R2 running at a snail’s pace

First off, a 2.6GHz processor is not a 2.6GHz processor if they're from different generations. You're correct in thinking twice about that. This has been true for a long time now (at least since the 486 / Pentium days), and so it's important to point out to your engineer just how wrong the Megahertz Myth is. Especially given the massive performance improvements i7 based chips offer over Core / Core2 based ones at the same clock speed.

That being said, that's not my first concern with this plan. My first concern is that used servers will have a significantly reduced operational life that a new server, since you don't know how it was previously used, under what conditions, or what'll happen to it in transit on the way to you. Generally speaking, for production systems, reliability should always take precedence to performance, since it'll cost you way more to fix a dead production server than to upgrade a server that's too slow.

My feeling is that the price difference would have to be very, very substantial to even want to look at doing this, and that if you're buying used, you'll want to redundantly cluster them just to be safe.

Perfmon.exe

First look at the Process object type. This has an instance for every single process on the system, and contains metrics like Virtual Bytes, Virtual Bytes Peak, Working Set and Working Set Peak. The SQL Server's instance will be named after the process name, 'sqlservr'. Looking at all instances you can quickly see which process causes the most memory consumption.

Next look at SQL Server's own counters. In the SQL Server:Buffer Manager object you'll find SQL Server own counters. You need to look at the Total Pages counter that counts all memory tracked by SQL Server internally. The counter is in pages, so you need to multiply by 8192 to get bytes.

There may be big a discrepancy between the Process Virtual Bytes counter and SQL own's Total Pages. This can happen when SQL uses AWE to map memory, and SQL may use AWE on x64 platforms too.

You can also track SQL Server moemory consumption from isnide, look at the sys.dm_os_memory_clerks or run DBCC MEMORYSTATUS.

If you find that SQL Server uses the memory: close your session, lay down your hands from the keyboard, and walk away. This is the normal, intended and desired behavior. If you need memory for any other process, move that process away from the same host as SQL. Never run anything else on the same host you run SQL Server (no IIS, no ASP, no exhange, no DC, no DNS/Winds, nothing).