SQLServerCentral Editorial

Sizing New Servers

,

I ran across a post this week from Joe Chang on server sizing. It's short and talks about some of the issues that you might consider when looking at a single socket v multi-socket systems. What first caught my eye, however, was the opening sentence: "Standardizing on 2 and 4 sockets systems for servers has been an established practice going back to 1996".

I think that's been my experience overall. For most of my early career, we often did purchase 2 or 4 socket systems. A few times I had 8 sockets, but hardware costs and licensing were high. When VMs became the preferred method of building servers, we tended to just ask for 2 or 4 vCPUs. If the system ran slow, we just doubled the vCPUs.

Time has moved one and hardware has advanced at incredible rates. These days licensing by core has really changed the way that I look at hardware. I couldn't tell you how many sockets servers have, as I'd likely just ask for a VM with x CPUs (and lots of RAM) allocated. Whether the system was 1, 2, 4, 8, or more sockets wouldn't be a consideration. In fact, I've somewhat given up on trying to track which CPUs have what cores and what the best choice is. I take the simplistic view of a core is a core and the hardware geeks will figure out how to get those into my VM.

I wonder how many of you actually worry about the hardware in your system beyond gross layout? Do you dig into tracking which CPUs need to be inside a physical box, the type of RAM layout, the drives (beyond size and count)? Or are you like me. Your system is JBOC (just a bunch of cores), JBOR (just a bunch of RAM), and JBOD. If things run slow, after fixing code, I usually JWM (just want more of something).

Certainly there is a need for someone to pay attention to hardware details, perhaps if for no other reason than to ensure that price/performance is being considered and there are spare parts available. For me, as a data professional, I've tended to just look at the performance needed from a system and ask for that. Even in my last position as a DBA, my concern was the SQL Server process and how it worked, limiting my hardware concerns to knowing the CPU count, RAM size, and number of disks. I've abstracted away hardware for the most part, focusing on a higher level of the system.

For those times when I do care about hardware, such as when laptop shopping, a simple query of a few colleagues or a tweet nets me enough information to make a choice. After all, that's what friends are for.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating