interesting question. Please try to define the bottleneck of your current application first. From your description and some practical knowledge, I would guess that you have four possible bottlenecks:
- nic
- ram
- hd throughput
- cpu (speed)
- cpu (cores)
Now ram would not be an issue, because, since you db is only 2G, you could buffer not only all keys and indizes, but actually the entire db in ram having 2G, if you size (MyISAM-) key_buffer and/or innodb_buffer_pool_cache accordingly! You would probably be fine even with ram < dbsize, because usually not all parts of a db are used at the same time (ymmv).
Of course ram is also used for memory tables, sorting and ordering and some join operations, so you should look at the complexity of queries your database does, and whether it returns very large resultsets. I do not know, but I believe neither wordpress nor mediawiki do really complex operations there. So just get a moderate amount of ram.
HD is the usual bottleneck for any large database, but yours can be cached in ram anyway, and you say that you have mostly read operations, so I'd say: for a normal large database, the rule of thumb would be: hd throughput is a main bottleneck, so: 1. buy hds, and 2. do not necessarily buy the fastest ones, but buy many of them. In you case, I'd say: its all cached anyway.
As for cores:
MySQL can indeed take advantage of many cores, but it mainly needs them for complex calculations, procedural programs and sort and merge operations. Siple queries like "Select * from table" or even select * from table where..." will not benefit much from more cores. Many connections will gain minor benefit. My guess is you should prefer a faster processor over many cores.
I believe you should check for the nic as the main bottleneck, and think about a second (Third, fourth...) nic, depending on the amount of traffic on your primary interface.
So, to sum it all up, I'd spend my money on (in that order):
- more than one nic (if that is indeed a bottleneck)
- a fast processor
- 2 - 4 cores
- 2-4G ram with the option to plug in 8G later (cheaper than cores, anyway)
- best posible disk subsystem (you do not need much now, but it will help you expand later)
Cheers, Nik.
The limit in SQL Server 2008 Standard for processors is per socket, not per core. For more info, check out the SQL Server 2008 page at Microsoft.com. Specifically, the "SQL Server 2008 R2 Editions Overview" PDF document. From the document:
With increasing hardware innovations, Microsoft continues to be the
only major database vendor who does not price per core for multi-core
processors
Yes, SQL Server 2008 Standard will use all 8 cores. It could use a hundred cores on a single-socket license if such a CPU existed.
Best Answer
There are two factors you want to look at:
Total aggregate performance: This is the measure of the total computing power of all the cores on the box. You can estimate this value by looking at the Passmark CPU rating for the CPU and multiplying by the number of physical CPUs in the system.
Single-thread performance: This is the measure of how much computing power the CPU can give to a single thread. You can estimate this value by looking at the Passmark CPU rating for the CPU and dividing by the number of cores in the CPU. (For hyper-threaded CPUs, divide by 1.25 times the number of physical cores.)
If one machine wins on both of these measures, it's probably your best choice. If it's split on the two measures, then it comes down to how effectively your software can take advantage of multiple cores.
Note that memory performance can be important too. More memory channels typically means faster memory access. Also, of course, the total amount of memory is important. Different CPUs often mean different motherboards, which can mean different memory performance.