https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-15368 Lustre <p>We have noticed that monitoring changelog_size on MDS can significantly slow down changelogs operations and eventually even the MDS in general.</p> <p>We have a script that monitor changelog_size every minute to display the size per MDT with Grafana (we also have an alert via Grafana when a changelog_size grows too much). The script basically does the following:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[root@fir-md1-s3 ~]# lctl get_param mdd.*-MDT*.changelog_size mdd.fir-MDT0002.changelog_size=305538455808 </pre> </div></div> <p>Recently, a user launched massive jobs writing many small files at 30K+ create/s for hours, resulting in a backlog of changelogs on MDT0002: changelog_size increased dramatically and the monitoring script took longer and longer to get the value of changelog_size (more than 1 minute). This resulted in a slow down of changelogs commit seen from Robinhood and also eventually a general high load on the MDS and slow operations (up to 5s for a chownat).</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[root@fir-md1-s3 ~]# uptime 09:35:21 up 25 days, 23:30, 2 users, load average: 101.05, 97.57, 100.55 </pre> </div></div> <p>I even noticed one watchdog backtrace at some point:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Dec 13 08:49:02 fir-md1-s3 kernel: Pid: 24707, comm: mdt00_062 3.10.0-1160.45.1.el7_lustre.pl1.x86_64 #1 SMP Wed Nov 10 23:41:33 PST 2021 Dec 13 08:49:02 fir-md1-s3 kernel: Call Trace: Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffa7798387&gt;] call_rwsem_down_write_failed+0x17/0x30 Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0ecf68f&gt;] llog_cat_id2handle+0x7f/0x620 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0ed0778&gt;] llog_cat_cancel_records+0x128/0x3d0 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc1b01328&gt;] llog_changelog_cancel_cb+0x1d8/0x5b0 [mdd] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0eca5af&gt;] llog_process_thread+0x85f/0x1a70 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0ecb87c&gt;] llog_process_or_fork+0xbc/0x450 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0ed0c59&gt;] llog_cat_process_cb+0x239/0x250 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0eca5af&gt;] llog_process_thread+0x85f/0x1a70 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0ecb87c&gt;] llog_process_or_fork+0xbc/0x450 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0ecd5e1&gt;] llog_cat_process_or_fork+0x1e1/0x360 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc0ecd78e&gt;] llog_cat_process+0x2e/0x30 [obdclass] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc1affa34&gt;] llog_changelog_cancel.isra.16+0x54/0x1c0 [mdd] Dec 13 08:49:02 fir-md1-s3 kernel: [&lt;ffffffffc1b02110&gt;] mdd_changelog_llog_cancel+0xd0/0x270 [mdd] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffc1b05f33&gt;] mdd_changelog_clear+0x653/0x7d0 [mdd] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffc1b08153&gt;] mdd_iocontrol+0x163/0x540 [mdd] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffc198684c&gt;] mdt_iocontrol+0x5ec/0xb00 [mdt] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffc19871e4&gt;] mdt_set_info+0x484/0x490 [mdt] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffc125b89a&gt;] tgt_request_handle+0xada/0x1570 [ptlrpc] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffc120073b&gt;] ptlrpc_server_handle_request+0x24b/0xab0 [ptlrpc] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffc12040a4&gt;] ptlrpc_main+0xb34/0x1470 [ptlrpc] Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffa74c5e61&gt;] kthread+0xd1/0xe0 Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffa7b95ddd&gt;] ret_from_fork_nospec_begin+0x7/0x21 Dec 13 08:49:03 fir-md1-s3 kernel: [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff Dec 13 08:49:03 fir-md1-s3 kernel: LustreError: dumping log to /tmp/lustre-log.1639414143.24707 Dec 13 08:49:11 fir-md1-s3 kernel: LNet: Service thread pid 24707 completed after 369.43s. This indicates the system was overloaded (too many service threads, or there were not enough hardware resources). </pre> </div></div> <p>Just stopping the monitoring script (thus stopping checking the changelog_size from the MDS) resolved the issue: changelogs commit rates went immediately up and the load of the server down at a reasonable level.</p> <p>I wanted to raise this issue so it can be improved in the future. It's important for us that we can monitor the size of the changelogs stored on each MDT. It would be nice to have a more efficient way of doing so. Thanks!</p> CentOS 7.9 LU-15368

Monitoring changelog_size is slowing down changelogs operations

Bug Major Open Unresolved Peter Jones Stephane Thiell Mon, 13 Dec 2021 20:18:15 +0000 Thu, 16 Dec 2021 15:30:35 +0000 Lustre 2.12.7 0 7 <p>Taking a quick look at the patch <a href="http://review.whamcloud.com/16416" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16416</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-7156" title="Provide size of changelogs" class="issue-link" data-issue-key="LU-7156"><del>LU-7156</del></a> mdd: add changelog_size to procfs</tt>" that added the <tt>changelog_size</tt> parameter, it looks like this is reprocessing each logfile to see if it can be cleaned up. However, if there are a large number of log records, and the <tt>changelog_size</tt> file is accessed frequently, this extra scanning overhead may be substantial. </p> <p>It would make sense to put some limit on the amount of re-scanning done (e.g. do it once when the parameter is first accessed after a remount, or at most once per hour, or similar), so that repeated access to this parameter does not hurt MDS performance. Without that, the checking of the sizes of the llog files should be very fast (stat of a few thousand llog files should be milliseconds on a flash MDT, maybe 10s on an HDD MDT).</p> <blockquote><p>do it once when the parameter is first accessed after a remount, or at most once per hour, or similar</p></blockquote> <p>So that means the readed changelog might be an async value that gathered a hour ago or so?</p> <p>I think there might be two different cases when reading the changelog size. One is for estimation which does not need a precise number, which indeed can be fit well into this "async" mechanism.</p> <p>The other is when a precise number is wanted when for example, need to check whether changelog is shrinking.</p> <p>To support the second use case properly, I think it makes to add write opertaion to mdd_changelog_size, i.e. </p> <p>1) if reading from this proc entry, it will return the cached/async value of change log size.<br/> 2) If writing to this entry, it will rescan the change log and refresh the value.</p> <p>I'm not suggesting to cache the Changelog <b>size</b> for such a long time, only to prevent processing and trying to clean up the Changelog files every time. Even with an out-of-control Changelog producer, there should be at most a few thousand llog files to stat, so this shouldn't take minutes to finish.</p> <p>What <em>might</em> be useful is to prevent multiple readers of <tt>changelog_size</tt> from processing the catalogs/llogs at the same time (e.g. if polling happens every 60s, but it takes 90s to process all of the logs for some reason). There should be a high-level mutex taken once llog traversal starts, and any reader arriving afterward should either block on the mutex, and then return the same size calculated by the first thread, or potentially return the <em>previous</em> size that was computed.</p> <p>A further possible optimization would be to incrementally update a cached size (after the first read from the file traverses all of the logs). This could be a percpu variable that is updated by the llog process for each record, or only incremented on a whole-file basis (e.g. add the size of whole llogs when they are finished, subtract the size of whole llogs when they are destroyed).</p> <p>Hello,</p> <p>For the CEA, the changelog_size is used to monitor how well we keep up to de-queue changelog with Robinhood. And I don't know if this is the same for Stephane Thiell.<br/> For this purpose the CEA use also the difference between current changelog id and the first changelog id for user (changelog_users) to monitor the delay between Robinhood and the MDT and trigger an alert.</p> <p>This is necessary for the following reason:</p> <ul> <li>Robinhood stop to process record: Robinhood bug or client lag</li> <li>Robinhood stop to process record because of Lustre bug: <a href="https://jira.whamcloud.com/browse/LU-14158" title="lfs changelog do not display old changelog after changelog_catalog wrapped arround" class="issue-link" data-issue-key="LU-14158"><del>LU-14158</del></a>, <a href="https://jira.whamcloud.com/browse/LU-15280" title="&quot;lfs changelog --follow&quot; does not support wrapped catalog" class="issue-link" data-issue-key="LU-15280"><del>LU-15280</del></a></li> <li>Unable to clear changelog efficiently (to much changelogs): <a href="https://jira.whamcloud.com/browse/LU-14688" title="Changelog cancel improvement" class="issue-link" data-issue-key="LU-14688"><del>LU-14688</del></a>, <a href="https://jira.whamcloud.com/browse/LU-14606" title="llog_changelog_cancel_cb returns ENOENT(-2)" class="issue-link" data-issue-key="LU-14606"><del>LU-14606</del></a></li> <li>Jobs create to much changelogs, can't keep up.</li> </ul> <p>So we need to monitor changelog usage before reaching the maximum number of changelog_catalog indexes (64767).<br/> Also, without the changelog option "follow" is not used with several cl users, more the difference between cl_users is important more the changelog processing is slow down. But we can't use the "follow" option because of the <a href="https://jira.whamcloud.com/browse/LU-15280" title="&quot;lfs changelog --follow&quot; does not support wrapped catalog" class="issue-link" data-issue-key="LU-15280"><del>LU-15280</del></a>.</p> <p>So we don't really need to have the exact "changelog_size" for this purpose but more a kind of "changelog_usage".<br/> This usage can be easily found by retrieving the "llh_count" inside the changelog_catalog header (percent_usage = 100 * llh_count / LLOG_HDR_BITMAP_SIZE(llh)). A upper approximation of changelog_size can be computed with: 11M * llh_count (actually llog plain size could be limited to 2.1M if the MDT space is low).<br/> For now I use debugfs to dump changelog_catalog and llog_reader to retrieve the llh_count.</p> <p>What do you think about adding a "changelog_usage" procfs?</p> <p>For the changelog_size performance issue, I think the <a href="https://review.whamcloud.com/#/c/43264/5/lustre/mdd/mdd_device.c" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/43264/5/lustre/mdd/mdd_device.c</a> ("<a href="https://jira.whamcloud.com/browse/LU-14606" title="llog_changelog_cancel_cb returns ENOENT(-2)" class="issue-link" data-issue-key="LU-14606"><del>LU-14606</del></a> llog: hide ENOENT for cancelling record") might help.<br/> This patch replace "llog_cat_cancel_records" with "RETURN(LLOG_DEL_RECORD);" in llog_changelog_cancel_cb.<br/> The problem with llog_cat_cancel_records in llog_cat_cancel_records is that it calls llog_cat_id2handle for each llog plain record.<br/> llog_cat_id2handle have to read a lot of cathandle-&gt;u.chd.chd_head entries (llog_handle cache) with llog_handle lock if there is lot of changelogs entries. This consume a lot of CPU time and conflict directly with llog_cat_size_cb.</p> <p>Thanks for the feedback! We are indeed using changelog_size for monitoring the de-queue process of changelogs per MDT with Robinhood (and also lauditd in some case, we have multiple readers).</p> <p>We use SSDs on MDTs and they are not IO bound when this happen. Actually when this happens, sar shows a drop in IOPS. It's more like a lock contention to me. At some point when this happens, a single core is at 100%, so I believe Etienne's last comment is spot on. I will add the patch from <a href="https://jira.whamcloud.com/browse/LU-14606" title="llog_changelog_cancel_cb returns ENOENT(-2)" class="issue-link" data-issue-key="LU-14606"><del>LU-14606</del></a> to our 2.12.7 when I get a chance (thanks Etienne for backporting it to b2_12). Note that this probably won't be before early January 2022 as we're trying to minimize changes on our systems before winter closure.</p> <p>I'm not a super fan of a different changelog_usage proc entry, which could add some confusion. Best would be to make the current proc entry efficient enough, and from what I hear in this ticket from you, it looks like it should be doable.</p> <p>In theory it should also be possible to monitor the changelog usage just by the difference in current vs. last used changelog ID? That should be a good proxy for the changelog size (about 160 bytes per record), and would not slow down because of the scanning the size.</p> Development Rank 1|i02cev: Rank (Obsolete) 9223372036854775807 Severity