the second phase of data compaction does not reflect by _active_tasks

[vitaly-goot]

vgoot [2:20 PM]
Question about data compaction:
From my understanding of the code, it appears that data compaction has 2 phases (phase one -> sort; phase two -> merge).
It seems that _active_tasks reflect the progress of phase I only. For shards with a big amount of documents (e.g. 20M+) the 'merge part' time can be quite substantial.
Is it possible to add progress of phase II to _active_tasks ?

jan [12:18]
@vgoot best to open an issue on GitHub apache/couchdb

[kocolosk]

Hi @vitaly-goot yes I hear you on this one. I'll note that there is some major refactoring of compaction underway in #806 which should significantly reduce the amount of time spent in the merge phase (right @davisp / @nickva ?). But I'm guessing there's still an opportunity to add instrumentation after that PR lans.

[davisp]

Yeap, #806 is held up waiting for PSE to land. Also I'm pretty sure I had a PR somewhere that added progress reporting during the second phase but I'm not able to find it just now. But the plan is definitely to add that with the work on revamping the compactor.

[vitaly-goot]

Submitted my workaround for that issue (see #1006)
Testing it on older CouchDB-1.6 (which we are running). Looking good.
I rebased all relevant 1.6 changes with yours recent 2.1 code line (but never tested).

This change will not report the progress of the merge phase per se but it is useful enough for us since we want to learn about disk burn rate and disk overhead to get better capacity planning.

To get proper emsort progress reporting, it seems like emsort:get_state() needs to be changed to return additional information (other than Root). In fact, two counters could surface (added counter and merged counter). That state is saved on disk by couch_db_updater (via #comp_header.meta_state). It seems that format of that state can be changed safely since this is all temporary compacted files.

[vitaly-goot]

Adding merge phase reporting.

couch_emsort changes:
A new counter to keep track the number of merged paths (emsort.bb_chains). That counter is committed to compact meta file during sort phase. The format of compact.meta file changed (to keep that counter) but new code should be able to work with both disk representations. On merge phase, that counter is used to report a ratio of how many bb_chains were merged vs. added.

[janl]

@davisp does PSE resolve this?

[nickva]

This was implemented in 123bf82 by @davisp. Thanks @vitaly-goot for the initial idea and proof of concept

[vitaly-goot]

Cool, I am glad I was able to contribute something useful back to community. Thank you for letting me know! -Vitaly

…

On Thu, Nov 4, 2021 at 8:54 AM Nick Vatamaniuc ***@***.***> wrote: This was implemented in 123bf82 <123bf82> by @davisp <https://github.com/davisp>. Thanks @vitaly-goot <https://github.com/vitaly-goot> for the initial idea and proof of concept — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#980 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPBQ6L3BDBI6FTJGD7OBGLUKK3CRANCNFSM4EDH4U2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.