What does a bug hunt have to do with and I/O Scheduler? Both were top content on the ScyllaDB blog in 2016. Before 2016 fades into the distant past, we’d like to share our most read and shared posts from last year.
1. Qualifying Filesystems for Seastar and ScyllaDB
Welcome to the asynchronous world
In the networking world, asynchronous processing is so common that it is practically taken for granted. An application sends a message to a remote server, and goes off to do something else. When the response arrives, it is picked up and the application continues from where it left off. There are many application frameworks and even languages that make this easy. In the storage world, the situation is different.
Read More
2. Designing a Userspace Disk I/O Scheduler for Modern Datastores: the ScyllaDB example (Part 1)
In a datastore like ScyllaDB, there are many actors competing for disk I/O. Examples of such actors are data writers (in ScyllaDB’s parlance they can be either memtable or commitlog writers), and a disk reader fetching the data to serve a cache miss. To illustrate the role that competition plays, if we are just issuing disk I/O without resorting to any fairness or balancing consideration, a reader, for instance, could find itself behind a storm of writes.
Read More
3. Reducing latency spikes by tuning the CPU scheduler
In this post we will walk through an investigation of latency spikes observed in the ScyllaDB 1.0.x version family, which are linked to the scylla-jmx service running alongside the ScyllaDB server on the same system. We will show how the scheduler can be tuned to reduce latency spikes. ScyllaDB 1.2, which is at the release candidate stage this week, will have all relevant fixes. Users of that version won’t have to do anything.
Read More
4. Big latencies? It’s open season for kernel bug-hunting!
ScyllaDB strives to offer its users predictable low latencies. However, in real life, things do not always go according to plan, and sometimes predictable low latencies become unpredictable big latencies. When that happens, it’s time to go into detective mode and go figure out what’s going on.
Read More
5. ScyllaDB Workload Conditioning part one: write request rate determination
What is the best request rate I should throw at my cluster? What disk bandwidth should I make available for compactions? How many reader or writer threads should I have? What are the best size for my memtables?
Everybody who has deployed a NoSQL solution has asked themselves these questions. At ScyllaDB, we don’t want to help you answer those questions — we want to get rid of the questions altogether.
Read More
What would you like to read on the ScyllaDB blog in 2017? Write to us at [email protected] or tweet us at @scylladb. We’d love to hear from you!
