[ovirt-devel] VDSM changes Linux memory dirty ratios - why?

Yaniv Kaul ykaul at redhat.com
Sun Dec 4 11:18:59 UTC 2016


On Nov 30, 2016 4:48 PM, "Ben England" <bengland at redhat.com> wrote:

I uploaded the article to:

https://s3.amazonaws.com/ben.england/rhev-vm-rsptime.pdf

I had just gone to work for Red Hat back in 2011 so I made the mistake of
including a company-internal URL in a public-facing document.    We can
update the bz with the above link if you want.  This article is ANCIENT
(2011), so while the basic approach should still be relevant, some of the
specifics may have changed.  This was a RHEV-on-NFS configuration.

As for why dirty ratio lowering is not part of a tuned profile, there is a
debate in the performance team about dirty ratio, with some advocating for
higher dirty ratios that help some application workloads (example: writing
/tmp files).   I'd stand by this article for the particular configuration
that was being studied though, and I think the basic approach of
controlling latency and improving fairness by managing queue depths is very
relevant today.

cc'ed Sanjay Rao, who continues to be a RHEV expert in the perf team (I no
longer am working on it).


Ben, any idea why, at the time, you have added a workload from the host,
that was competing with the VMs?
Usually the only IO load from the hosts are the logs... Nothing serious
really.
Y.


-ben


----- Original Message -----
> From: "Martin Polednik" <mpolednik at redhat.com>
> To: "Sven Kieske" <s.kieske at mittwald.de>
> Cc: devel at ovirt.org, "Ben" <bengland at redhat.com>
> Sent: Wednesday, November 30, 2016 7:22:05 AM
> Subject: Re: VDSM changes Linux memory dirty ratios - why?
>
> On 30/11/16 13:10 +0100, Sven Kieske wrote:
> >On 30/11/16 08:48, Martin Polednik wrote:
> >> It's not really irrelevant, the host still uses disk cache. Anyway,
> >> there is BZ[1] with a presentation[2] that (imho reasonably) states:
> >>
> >> "Reduce dirty page limits in KVM host to allow
> >> direct I/O writer VMs to compete successfully
> >> with buffered writer processes for storage
> >> access"
> >>
> >> I wonder why virtual-host tuned profile doesn't contain these values:
> >>
> >> $ grep vm.dirty /usr/lib/tuned/virtual-host/tuned.conf
> >> vm.dirty_background_ratio = 5
> >>
> >> [1]https://bugzilla.redhat.com/show_bug.cgi?id=740887
> >> [2]http://perf1.lab.bos.redhat.com/bengland/laptop/
rhev/rhev-vm-rsptime.pdf
> >
> >Could you share [2] with the wider community? This would be awesome!
>
> Sorry, I've totally missed the fact it's internal link (unfortunately
> publicly visible on the BZ). I believe it's slightly outdated, but
> let's ask the author.
>
> Ben, is the document[2] somehow still valid and could it be made publicly
> available?
>
> Re-referencing for completeness:
> [2]http://perf1.lab.bos.redhat.com/bengland/laptop/
rhev/rhev-vm-rsptime.pdf
>
> >--
> >Mit freundlichen Grüßen / Regards
> >
> >Sven Kieske
> >
> >Systemadministrator
> >Mittwald CM Service GmbH & Co. KG
> >Königsberger Straße 6
> >32339 Espelkamp
> >T: +495772 293100
> >F: +495772 293333
> >https://www.mittwald.de
> >Geschäftsführer: Robert Meyer
> >St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad
Oeynhausen
> >Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
Oeynhausen
> >
>
>
>
>
> >_______________________________________________
> >Devel mailing list
> >Devel at ovirt.org
> >http://lists.ovirt.org/mailman/listinfo/devel
>
>
_______________________________________________
Devel mailing list
Devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161204/e7297d23/attachment-0001.html>


More information about the Devel mailing list