On Tue, Jun 16, 2015 at 11:53 AM, Jan Schermer <jan@xxxxxxxxxxx> wrote: > Well, I see mons dropping out when deleting large amount of snapshots, and it leats a _lot_ of CPU to delete them Well, you're getting past my expertise on the subject, but deleting snapshots can sometimes be expensive, yes. If monitors are dropping out that probably means they're getting swamped by the OSDs sending in updates; you might want to adjust your reporting config options (osd_mon_report_interval_max, osd_mon_report_interval_min, and osd_pg_stat_report_interval_max). > , I also had to manually schedule “compact” for the leveldb on mons as it stopped compacting itself. But that doesn’t impact IO as far as I know (or does the mon speed actually impact IO?). It own't impact IO generally, unless it's blocking cluster updates. > I can see lots of layers on the snapshotted volumes as well as extremely large overhead with snapshots (2.5TB volume that actually occupies 7TB(*3) of space until even the HEAD is deleted), but that’s a different story I guess… It's possible that you've just got enough snapshots the OSDs haven't ever caught up with deleting them...not sure. :/ What version of Ceph are you currently running? > > Jan > >> On 16 Jun 2015, at 12:32, Gregory Farnum <greg@xxxxxxxxxxx> wrote: >> >> On Tue, Jun 16, 2015 at 3:30 AM, Jan Schermer <jan@xxxxxxxxxxx> wrote: >>> Thanks for the answer. >>> So it doesn’t hurt performance if it grows to ridiculous size - e.g. no lookup table overhead, stat()ing additional files etc.? >> >> Nope, definitely nothing like that. If it gets sufficiently fragmented >> it can expand the size of the OSDMap, which might cause issues. But >> they'll be things like increasing memory consumption and slow map >> propagation and won't impact your regular object access. > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |