From: David Teigland <teigland@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: "zdenek.kabelac@gmail.com" <zdenek.kabelac@gmail.com>,
"linux-lvm@redhat.com" <linux-lvm@redhat.com>,
Heming Zhao <heming.zhao@suse.com>
Subject: Re: [linux-lvm] lvmpolld causes high cpu load issue
Date: Wed, 17 Aug 2022 10:11:58 -0500 [thread overview]
Message-ID: <20220817151158.GA27556@redhat.com> (raw)
In-Reply-To: <4e0551e18a28ff602fae6e419dc746145e5962d3.camel@suse.com>
On Wed, Aug 17, 2022 at 01:41:17PM +0000, Martin Wilck wrote:
> I like the general idea of the udev watch. It is the magic that causes
> newly created partitions to magically appear in the system, which is
> very convenient for users and wouldn't work otherwise. I can see that
> it might be inappropriate for LVM PVs. We can discuss changing the
> rules such that the watch is disabled for LVM devices (both PV and LV).
> I don't claim to overlook all possible side effects, but it might be
> worth a try. It would mean that newly created LVs, LV size changes etc.
> would not be visible in the system immediately. I suppose you could
> work around that in the LVM tools by triggering change events after
> operations like lvcreate.
I think it's worth looking into at least. udev causes most of our major
problems, and causes things to fall apart everywhere at scale.
> Note: We were observing that watch events were triggered every 30s, for
> every PV, simultaneously.
Can you see what parts of the VG metadata are changing each time? If it's
just metadata related to pvmove progress, then things are probably working
as designed, and we'd just be looking for optimizations (perhaps by some
code changes, or by reducing copies of metadata as suggested by Zdenek.)
Dave
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
next prev parent reply other threads:[~2022-08-17 15:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 9:28 [linux-lvm] lvmpolld causes IO performance issue Heming Zhao
2022-08-16 9:38 ` Zdenek Kabelac
2022-08-16 10:08 ` [linux-lvm] lvmpolld causes high cpu load issue Heming Zhao
2022-08-16 10:26 ` Zdenek Kabelac
2022-08-17 2:03 ` Heming Zhao
2022-08-17 8:06 ` Zdenek Kabelac
2022-08-17 8:43 ` Heming Zhao
2022-08-17 9:46 ` Zdenek Kabelac
2022-08-17 10:47 ` Heming Zhao
2022-08-17 11:13 ` Zdenek Kabelac
2022-08-17 12:39 ` Martin Wilck
2022-08-17 12:54 ` Zdenek Kabelac
2022-08-17 13:41 ` Martin Wilck
2022-08-17 15:11 ` David Teigland [this message]
2022-08-18 8:06 ` Martin Wilck
2022-08-17 15:26 ` Zdenek Kabelac
2022-08-17 15:58 ` Demi Marie Obenour
2022-08-18 7:37 ` Martin Wilck
2022-08-17 17:35 ` Gionatan Danti
2022-08-17 18:54 ` Zdenek Kabelac
2022-08-17 18:54 ` Zdenek Kabelac
2022-08-17 19:13 ` Gionatan Danti
2022-08-18 21:13 ` Martin Wilck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220817151158.GA27556@redhat.com \
--to=teigland@redhat.com \
--cc=heming.zhao@suse.com \
--cc=linux-lvm@redhat.com \
--cc=martin.wilck@suse.com \
--cc=zdenek.kabelac@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).