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 message[1. and not the corresponding blaming message Digest mismatch, buffer modified by upper layers during write, see eg. here] 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 load[1. and, therefore, restricting throughtput] 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.

4 replies
  1. Flip
    Flip says:

    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 😉

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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