DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Decoding Database Speed: Essential Server Resources and Their Impact
  • 7 Invaluable Advantages of Using Amazon RDS
  • Building a High-Throughput Distributed Sequence Generator Using the Hi-Lo Algorithm
  • When Snowflake Lies to You: Understanding False Failures in dbt Pipelines

Trending

  • Skills, Java 17, and Theme Accents
  • Why DDoS Protection Is an Architectural Decision for Developers
  • Why Your Test Automation Is Always Behind the Code And the Architecture That Fixes It
  • Architecting Zero-Trust AI Agents: How to Handle Data Safely
  1. DZone
  2. Data Engineering
  3. Databases
  4. Why IOPS Matters for the Database

Why IOPS Matters for the Database

As it turns out, if you use all your IOPS burst capacity, you end up having to get your I/O through a straw.

By 
Oren Eini user avatar
Oren Eini
·
Feb. 08, 18 · Opinion
Likes (3)
Comment
Save
Tweet
Share
12.5K Views

Join the DZone community and get the full member experience.

Join For Free

You knew that this article had to come. After talking about memory and CPU so often, we need to talk about actual I/O.

Did I mention that the cluster was set up by a drunk monkey? That term was raised in the office today, and we had a bunch of people fighting over who the monkey was. So to clarify things, here is the monkey:

image

If you have any issues with this being a drunk monkey, you are likely drunk, as well. How about you set up a cluster that we can test things on?

At any rate, after setting things up and pushing the cluster, we started seeing some odd behaviors. It looked like the cluster was… acting funny.

One of the things we build into RavenDB is the ability to inspect its state easily. You can see it in the image below. In particular, you can see that we have a journal write taking 12 seconds to run.

Image title

It is writing 76Kb to disk at a rate of about 6KB per second. To compare, a 1984 modem would actually be faster. What is going on? As it turns out, the IOPS on the system was left in their default state, and we had less than 200 IOPS for the disk.

Did I mention that we are throwing production traffic and some of the biggest stuff we have on this thing? As it turns out, if you use all your IOPS burst capacity, you end up having to get your I/O through a straw.

This is excellent since it exposed a convoy situation in some cases and also gave us a really valuable lesson about things we should look at when we are investigating issues (the whole point of doing this “set up by a monkey” exercise).

For the record, here is what this looks like when you do things properly:

image

Why does this matter, by the way?

A journal write is how RavenDB writes to the transaction journal. This is absolutely critical to ensuring that the transaction ACID properties are kept.

It also means that when we write, we must wait for the disk to OK the write before we consider it completed. And that means that there were requests somewhere that were sitting there waiting for 12 seconds for a reply because the IOPS run out.

IOPS Database

Published at DZone with permission of Oren Eini. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Decoding Database Speed: Essential Server Resources and Their Impact
  • 7 Invaluable Advantages of Using Amazon RDS
  • Building a High-Throughput Distributed Sequence Generator Using the Hi-Lo Algorithm
  • When Snowflake Lies to You: Understanding False Failures in dbt Pipelines

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook