Author
Alex Reece
Performance Engineer
Engineering
New Release of dbbench Streamlines Database Workload Testing
Our performance engineering team is committed to delivering high quality tools. Since we released `dbbench` 7 months ago, it has been widely adopted across our engineering and sales teams as the definitive tool for testing database workloads. Today we are announcing availability of a new version of `dbbench`, as well as a package of high level tools to enhance it.
In this latest release, we enhanced both the flexibility and ease of use of the tool. We augmented capabilities of `dbbench` and added a tutorial to help new sales engineers get started. In addition to these enhancements, we released a package of internal tools specifically designed to support high level workflows that use `dbbench`. These changes improve our technical proof-of-concept (POC) process for our customers and open up `dbbench` for new workloads and use cases. This version of `dbbench` not only increases the performance and power of this benchmark testing tool, but also makes it easily accessible to anyone interested in using it.
dbbench in Action
One of the new features of `dbbench` is the ability to display latency histograms during the final analysis to easily detect and understand outliers. In the example below, we can see that most of the queries executed between 0.2 and 0.5 ms, but there were outliers as high as 30ms:
Read Post
Engineering
dbbench: Bringing Active Benchmarking to Databases
In my last blog post, I investigated a Linux performance issue affecting a specific customer workload. In this post, I will introduce the tool I created to drive that investigation.
Read Post
Engineering
Investigating Linux Performance with Off-CPU Flame Graphs
The Setup
As a performance engineer at SingleStore, one of my primary responsibilities is to ensure that customer Proof of Concepts (POCs) run smoothly. I was recently asked to assist with a big POC, where I was surprised to encounter an uncommon Linux performance issue. I was running a synthetic workload of 16 threads (one for each CPU core). Each one simultaneously executed a very simple query (`select count(*) from t where i > 5`) against a columnstore table.
In theory, this ought to be a CPU bound operation since it would be reading from a file that was already in disk buffer cache. In practice, our cores were spending about 50% of their time idle:
Read Post
