It's rather hard to find a CPU benchmark that is more representative of database performance more useful than just using a database to do something processor-intensive. You can easily build some quick, PostgreSQL-oriented CPU tests using the database psql client and its \timing feature, which shows you how long each statement takes to run. Here's an example that just exercises the CPU and memory, by adding the first million integers together with the always handy generate_series set returning function:

\timing
SELECT sum(generate_series) FROM generate_series(1,1000000);

Here's another more complicated example that may use some disk accesses too, in addition to stressing CPU/memory; depends on the amount of RAM in your server:

\timing
CREATE TABLE test (id INTEGER PRIMARY KEY);
INSERT INTO test VALUES (generate series(1,100000));
EXPLAIN ANALYZE SELECT COUNT(*) FROM test;

Both the insertion time and how long it takes to count each value are interesting numbers. The latter also includes some CPU/memory-intensive work related to updating the hint bit values PostgreSQL uses to track transaction visibility information; see Chapter 7, Routine Maintenance for more information about it.

Remember, the point of your CPU testing is not to map out a comprehensive view of its performance in every regard. What you should focus on is making sure performance matches similar hardware. And if this is an upgrade, that it exceeds the expectations you have from older systems.

A more useful look at CPU capacity from a PostgreSQL perspective will be provided in Chapter 8, Database Benchmarking. Running a SELECT-only test using pgbench and more clients than your system has cores, when all the data fits in RAM, is a very good way to see if your CPUs are delivering expected performance. That's my preferred way to see how fast a new CPU I'm evaluating will work for real CPU and memory limited workloads. Just note that the pgbench in PostgreSQL versions before 9.0 can easily act as the bottleneck on results; more on this topic in that later chapter.

If your memory doesn't look to be as fast as it should be, or your CPU results look suspicious, there are a few common things to look for to figure out why.

Most memory is now designed to work in a dual-channel configuration, with pairs of memory put only into specific slots. If that's not done correctly, you'll halve memory speed by running in a single-channel setup. memtest86+ can note when this is happening, and your BIOS may realize it if you look for the information.

Poor quality RAM can introduce a surprisingly large drop in system performance. And just because you have fast memory in your server, that doesn't mean the motherboard is taking advantage of it. The defaults on some systems are quite conservative. Nowadays, your system should be looking up Serial Presence Detect (SPD) information provided by your RAM, to determine how fast it should run. But that doesn't always default to optimal performance, and manual tweaking of the memory timing can be required.

Recent high-performance PC RAM aimed at desktop systems uses a newer standard for the same purpose, the Extreme Memory Profile (XMP) protocol, to communicate the speed it's capable of running at to the system BIOS when you boot. But if your BIOS doesn't default to checking and using XMP, which some don't, your RAM will run at notably non-"extreme" speeds. You should be able to find out how fast your RAM is expected to run as a series of timing values. The Intel i7 860 system mentioned before using DDR3-1600 has timing values of 8-8-8-24 for example. The motherboard did not run the RAM at those speeds until I'd adjusted several settings in it. And just because your hardware vendor should be taking care of all this for you doesn't mean it's safe to ignore this whole issue. It's easy for anyone to miss a step and ship a system with degraded performance.

Another problem that you can run into is using memory that doesn't work well with the clock speed of the processor you're using. Processors are often "locked" to certain multiplier possibilities that are relative to the speed the main system bus runs at. The motherboard ends up doing a complicated negotiation game between the processor and the RAM to find a common denominator speed to run everything at. For example, one of my older systems supported either DDR2-667 or DDR-800 RAM, running at a memory clock of 333 or 400 MHz. The system processor ran at 2.4 GHz, and only supported limited multiplier combinations. It turned out that if I used DDR2-667, the common frequency the motherboard settled on was running the memory bus at 300 MHz, with the CPU using a 8X multiplier. So the RAM was essentially 10% under-clocked relative to its capabilities. Upgrading to DDR2-800 instead used a 400MHz clock and a 6X CPU multiplier. That's a 33% jump in memory speed just from using a better grade of RAM, to better match the CPU clock possibilities, and overall system performance improved proportionately.

In addition to getting the memory and multiplier details right, processor power management is an increasing source of issues when benchmarking hardware. Many operating systems now default to having modest or aggressive processor power management active by default. This is a surprisingly common issue on Linux for example. The normal warning sign is that the processor is only shown as running at 1 GHz in /proc/cpuinfo, with correspondingly slow results on some benchmarks. Normally you will need to adjust the Linux CPU governor setup to optimize for performance, rather than lower power use, at least for the duration of the benchmark. Exact details for how to adjust the governor vary by Linux distribution. You may want to return to optimizing for lower energy use at the expense of some performance afterwards, once you've confirmed performance can be good when needed.