Re: Identify laggy PGs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The current ceph recommendation is to use between 100-200 PGs/OSD. Therefore, a large PG is a PG that has more data than 0.5-1% of the disk capacity and you should split PGs for the relevant pool.

A huge PG is a PG for which deep-scrub takes much longer than 20min on HDD and 4-5min on SSD.

Average deep-scrub times (time it takes to deep-scrub) are actually a very good way of judging if PGs are too large. These times roughly correlate with the time it takes to copy a PG.

On SSDs we aim for 200+PGs/OSD and for HDDs for 150PGs/OSD. For very large HDD disks (>=16TB) we consider raising this to 300PGs/OSD due to excessively long deep-scrub times per PG.

Best regards,
=================
Frank Schilder
AIT Risø Campus
Bygning 109, rum S14

________________________________________
From: Szabo, Istvan (Agoda) <Istvan.Szabo@xxxxxxxxx>
Sent: Wednesday, August 14, 2024 12:00 PM
To: Eugen Block; ceph-users@xxxxxxx
Subject:  Re: Identify laggy PGs

Just curiously I've checked my pg size which is like 150GB, when are we talking about big pgs?
________________________________
From: Eugen Block <eblock@xxxxxx>
Sent: Wednesday, August 14, 2024 2:23 PM
To: ceph-users@xxxxxxx <ceph-users@xxxxxxx>
Subject:  Re: Identify laggy PGs

Email received from the internet. If in doubt, don't click any link nor open any attachment !
________________________________

Hi,

how big are those PGs? If they're huge and are deep-scrubbed, for
example, that can cause significant delays. I usually look at 'ceph pg
ls-by-pool {pool}' and the "BYTES" column.

Zitat von Boris <bb@xxxxxxxxx>:

> Hi,
>
> currently we encouter laggy PGs and I would like to find out what is
> causing it.
> I suspect it might be one or more failing OSDs. We had flapping OSDs and I
> synced one out, which helped with the flapping, but it doesn't help with
> the laggy ones.
>
> Any tooling to identify or count PG performance and map that to OSDs?
>
>
> --
> Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im
> groüen Saal.
> _______________________________________________
> ceph-users mailing list -- ceph-users@xxxxxxx
> To unsubscribe send an email to ceph-users-leave@xxxxxxx


_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx

________________________________
This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux