On Mon, 23 Sep 2019, Koebbe, Brian wrote:
> Thanks Sage!
> ceph osd dump: https://pastebin.com/raw/zLPz9DQg
> 
> 
> ceph-monstore-tool /var/lib/ceph/mon/ceph-ufm03 dump-keys |grep osd_snap| cut 
> -c-29 |uniq -c
>       2 osd_snap / purged_snap_10_000
>       1 osd_snap / purged_snap_12_000
>      75 osd_snap / purged_snap_13_000
>       4 osd_snap / purged_snap_14_000
>  778106 osd_snap / purged_snap_15_000
>     861 osd_snap / purged_snap_1_0000
>     323 osd_snap / purged_snap_4_0000
>      88 osd_snap / purged_snap_5_0000
>       2 osd_snap / purged_snap_7_0000
>       2 osd_snap / purged_snap_8_0000
>       2 osd_snap / removed_epoch_10_0
>       1 osd_snap / removed_epoch_12_0
>      75 osd_snap / removed_epoch_13_0
>       4 osd_snap / removed_epoch_14_0
> 2316417 osd_snap / removed_epoch_15_0
>     970 osd_snap / removed_epoch_1_00
>     324 osd_snap / removed_epoch_4_00
>      89 osd_snap / removed_epoch_5_00
>       2 osd_snap / removed_epoch_7_00
>       2 osd_snap / removed_epoch_8_00
>       2 osd_snap / removed_snap_10_00
>       1 osd_snap / removed_snap_12_00
>      75 osd_snap / removed_snap_13_00
>       4 osd_snap / removed_snap_14_00
> 2720849 osd_snap / removed_snap_15_00
>    1161 osd_snap / removed_snap_1_000
>     379 osd_snap / removed_snap_4_000
>      89 osd_snap / removed_snap_5_000
>       2 osd_snap / removed_snap_7_000
>       2 osd_snap / removed_snap_8_000

Thanks!  I opened a ticket at https://tracker.ceph.com/issues/42012.  Can 
you do the aboe dump with the 'grep osd_snap' only and attach that to the 
bug?

This code has reworekd/improved in master, but I'm not sure the behavior 
of keeping a full record of past span deletions was changed, so we may 
need to make further improvements for octopus.

Thanks!
sage


> ________________________________
> From: Sage Weil <s...@newdream.net>
> Sent: Monday, September 23, 2019 9:41 AM
> To: Koebbe, Brian <koe...@wustl.edu>
> Cc: ceph-users@ceph.io <ceph-users@ceph.io>; d...@ceph.io <d...@ceph.io>
> Subject: Re: [ceph-users] Seemingly unbounded osd_snap keys in monstore. 
> Normal? Expected?
> 
> Hi,
> 
> On Mon, 23 Sep 2019, Koebbe, Brian wrote:
> > Our cluster has a little over 100 RBDs.  Each RBD is snapshotted with a 
> > typical "frequently", hourly, daily, monthly type of schedule.
> > A while back a 4th monitor was temporarily added to the cluster that took 
> > hours to synchronize with the other 3.
> > While trying to figure out why that addition took so long, we discovered 
> > that our monitors have what seems like a really large number of osd_snap 
> > keys:
> >
> > ​ceph-monstore-tool /var/lib/ceph/mon/xxxxxx dump-keys |awk '{print 
> > $1}'|uniq -c
> >     153 auth
> >       2 config
> >      10 health
> >    1441 logm
> >       3 mdsmap
> >     313 mgr
> >       1 mgr_command_descs
> >       3 mgr_metadata
> >     163 mgrstat
> >       1 mkfs
> >     323 mon_config_key
> >       1 mon_sync
> >       6 monitor
> >       1 monitor_store
> >      32 monmap
> >     120 osd_metadata
> >       1 osd_pg_creating
> > 5818618 osd_snap
> >   41338 osdmap
> >     754 paxos
> >
> > A few questions:
> >
> > Could this be the cause of the slow addition/synchronization?
> 
> Probably!
> 
> > Is what looks like an unbounded number of osd_snaps expected?
> 
> Maybe.  Can you send me the output of 'ceph osd dump'?  Also, if you don't
> mind doing the dump above and grepping out just the osd_snap keys, so I
> can see what they look like and if they match the osd map contents?
> 
> Thanks!
> sage
> 
> 
> > If trimming/compacting them would help, how would one do that?
> >
> > Thanks,
> > Brian
> >
> > ________________________________
> > The materials in this message are private and may contain Protected 
> > Healthcare Information or other information of a sensitive nature. If you 
> > are not the intended recipient, be advised that any unauthorized use, 
> > disclosure, copying or the taking of any action in reliance on the contents 
> > of this information is strictly prohibited. If you have received this email 
> > in error, please immediately notify the sender via telephone or return mail.
> >
> 
> ________________________________
> The materials in this message are private and may contain Protected 
> Healthcare Information or other information of a sensitive nature. If you are 
> not the intended recipient, be advised that any unauthorized use, disclosure, 
> copying or the taking of any action in reliance on the contents of this 
> information is strictly prohibited. If you have received this email in error, 
> please immediately notify the sender via telephone or return mail.
> 
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Reply via email to