DRBD causes too much CPU-load

The TL;DR version: don’t use data-integrity-alg in a production setup.

The users guide (8.3 version) describes the data-integrity-alg as

DRBD can ensure the data integrity of the user’s data on the network by comparing hash values. [...]

Too many people think this is a must-have setting – but are sadly wrong.

During initial installation and testing it does make sense to use this – it’s an easy way to find out whether the hardware (CPU, memory, network card, etc.) work as they should – if you get the famous Digest integrity check FAILED message1 you can be worried (but not too much, since you found that during testing (;).

But in production this should not be set – apart from causing a lot of CPU load2 it might cause frequent connection abort – and that means a short bit of time (re-sync) during which the secondary is inconsistent.

So: don’t use this in production.

  1. and not the corresponding blaming message Digest mismatch, buffer modified by upper layers during write, see eg. here
  2. and, therefore, restricting throughtput

4 thoughts on “DRBD causes too much CPU-load

  1. We do say that in the manual page:

    We suggest to use the data-integrity-alg only during
    a pre-production phase due to its CPU costs.

    But either people don’t read that, or just forget to remove the setting … well, this post is mostly to have another link to send them ;)

  2. But verify-alg is still OK? Funny thing that I always get some data out of sync after verify.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

What is 12, multiplied by 1 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)