PGCon2009 - Final Release
PGCon 2009
The PostgreSQL Conference
| Speakers | |
|---|---|
|
Greg Smith |
| Schedule | |
|---|---|
| Day | Talks - first day - 2009-05-21 |
| Room | DMS 1110 |
| Start time | 13:30 |
| Duration | 01:00 |
| Info | |
| ID | 152 |
| Event type | Lecture |
| Track | Performance |
| Language used for presentation | English |
Database Hardware Benchmarking
How big is the elephant in your room?
PostgreSQL DBAs and hardware vendors seem like they're speaking different languages some days. Doing your own low-level hardware benchmarking can provide the secret decoder ring needed to translate all the way from database transactions to disk commits.
You're a DBA, used to talking in terms of query runtime and transactions per second. Your server vendor babbles to you about cores and GHz. Your storage vendor, RPM and IOPS, and don't forget that all your problems would go away if only you had a SAN, right? Meanwhile, your boss wants an ROI on a server upgrade, and you're not even sure what the bottleneck on your existing one is. This is where benchmarking should help out, but who can you trust?
Nobody but yourself, that's who. It's about time you learned how to translate MIPS and IOPS into terms that make sense to you, so that you can convert between the language of your application and that of the hardware world. "Database Hardware Benchmarking" is all about how to measure the system you've got, compare against the system you might have, and confirm your shiny new system does what it's promised to do. All using easy to replicate hardware benchmarks, so that if you don't get what you expect, you can easily show your vendors what's wrong. Forget about SPEC and the TPC; it's simple tools like memtest86, dd, and bonnie++ that give you a real handle on what your hardware is doing, and you can tie that to PostgreSQL performance using generate_series and pgbench.