<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:54:57 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-40433] Mongodump extremely slow on 4.0.8</title>
                <link>https://jira.mongodb.org/browse/SERVER-40433</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;Since upgrading to mongo 4.0.8 from 3.4.6 our mongodumps have become extremely slow.&lt;/p&gt;

&lt;p&gt;mongodump --archive=${DIR}.gz \&lt;br/&gt;
 -h ${MONGO_REPL_SET_NAME}/${MONGO_SET} \&lt;br/&gt;
 -u ${MONGO_USER} \&lt;br/&gt;
 -p ${MONGO_PWD} \&lt;br/&gt;
 --gzip \&lt;br/&gt;
 --readPreference secondaryPreferred \&lt;br/&gt;
 --ssl \&lt;br/&gt;
 --sslCAFile mongodb-ca.crt \&lt;br/&gt;
 --authenticationDatabase admin \&lt;br/&gt;
 --${DB_OR_OPLOG} \&lt;br/&gt;
 --forceTableScan&#160;&lt;/p&gt;

&lt;p&gt;is the command we run for backups. Since the upgrade we are seeing about 10x slower backups.&lt;br/&gt;
Tried moving to a new machine with more memory and didn&apos;t see any speed improvement. CPU has 1 core at 100% while the rest of the cores have little to no activity. iostat doesn&apos;t show disk to be anywhere near saturated. We have tried running mongodump with the 3.6 and 4.0 cli too without any improvement.&#160;&lt;/p&gt;</description>
                <environment></environment>
        <key id="727590">SERVER-40433</key>
            <summary>Mongodump extremely slow on 4.0.8</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="daniel.hatcher@mongodb.com">Danny Hatcher</assignee>
                                    <reporter username="paulblend">Paul Henderson</reporter>
                        <labels>
                    </labels>
                <created>Tue, 2 Apr 2019 00:54:36 +0000</created>
                <updated>Tue, 20 Aug 2019 14:34:00 +0000</updated>
                            <resolved>Tue, 20 Aug 2019 14:34:00 +0000</resolved>
                                    <version>4.0.8</version>
                                                                        <votes>1</votes>
                                    <watches>21</watches>
                                                                                                                <comments>
                            <comment id="2378955" author="daniel.hatcher" created="Tue, 20 Aug 2019 14:33:05 +0000"  >&lt;p&gt;Ah I apologize for the confusion! Thanks for letting us know and for your patience while we fixed the problem. &lt;/p&gt;</comment>
                            <comment id="2378116" author="devony" created="Mon, 19 Aug 2019 22:13:17 +0000"  >&lt;p&gt;Sorry if it wasn&apos;t clear, I can confirm the issue is resolved for us in 4.0.12 on behalf of Paul.&lt;/p&gt;</comment>
                            <comment id="2377609" author="daniel.hatcher" created="Mon, 19 Aug 2019 18:00:51 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=paulblend&quot; class=&quot;user-hover&quot; rel=&quot;paulblend&quot;&gt;paulblend&lt;/a&gt;, as Devon mentioned, we implemented the fix we were waiting for in 4.0.12. Could you please try upgrading a Secondary and see if performance is improved? &lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=devony&quot; class=&quot;user-hover&quot; rel=&quot;devony&quot;&gt;devony&lt;/a&gt;, I can&apos;t speak to &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-40773&quot; title=&quot;Slow queries every 80s under moderate load&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-40773&quot;&gt;&lt;del&gt;SERVER-40773&lt;/del&gt;&lt;/a&gt; as I haven&apos;t reviewed that case in-depth. However, we do see value in removing idle cursors by default especially since they have to be idle for 28 hours before we attempt to clean them up. It is possible that a different setting would be better for your specific use-case but we would have to investigate which is outside the scope of this particular ticket.&lt;/p&gt;</comment>
                            <comment id="2377590" author="devony" created="Mon, 19 Aug 2019 17:46:48 +0000"  >&lt;p&gt;Just wanted to let you know this is resolved in 4.0.12.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;I have a question related to eviction that maybe can be answered quickly here. Is there a reason that the WT file_manager&#160;close_idle_time is still set to 100000 despite&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/WT-1930&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/WT-1930&lt;/a&gt;&#160;having merged to support a 0 value. (&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-18286&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/SERVER-18286&lt;/a&gt;). In&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-40773&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/SERVER-40773&lt;/a&gt;&#160;we were seeing large dhandle sweeps at this timeout which we think might be mitigated if the 0 setting is safe to use.&lt;/p&gt;</comment>
                            <comment id="2298791" author="daniel.hatcher" created="Wed, 26 Jun 2019 19:21:11 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=paulblend&quot; class=&quot;user-hover&quot; rel=&quot;paulblend&quot;&gt;paulblend&lt;/a&gt;, I apologize for the confusion surrounding the status of this ticket. The workload that you&apos;ve shown is concerning and I&apos;d like to ensure that we&apos;ve taken concrete steps to address it before closing this ticket. We&apos;ve recently made some changes to the WiredTiger storage engine that may help alleviate the problem. I&apos;m following up internally to see about getting those changes backported to a 4.0 build so that you can see if they help your issue.&lt;/p&gt;</comment>
                            <comment id="2294259" author="haribabu.kommi" created="Mon, 24 Jun 2019 00:51:03 +0000"  >&lt;p&gt;The problem is&#160;happening both before&#160;&lt;b&gt;and&lt;/b&gt;&#160;after the&#160;&lt;tt&gt;mongodump&lt;/tt&gt;. Due to the read heavy load, the cache eviction server is not able to clean the cache, and it leads to stalling.&#160;&lt;/p&gt;</comment>
                            <comment id="2291726" author="paulblend" created="Thu, 20 Jun 2019 17:48:58 +0000"  >&lt;p&gt;The mongo dataase has 271 dbs in it, all of which are hurt by the issue. I took db.stats() from 2 larger ones and 2 smaller ones.&lt;/p&gt;</comment>
                            <comment id="2291089" author="dmitry.agranat" created="Thu, 20 Jun 2019 11:03:18 +0000"  >&lt;p&gt;Hi &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=devony&quot; class=&quot;user-hover&quot; rel=&quot;devony&quot;&gt;devony&lt;/a&gt;,&lt;/p&gt;

&lt;p&gt;Could you please provide the output of dbStats() for the relevant database? This will provide us some more information of how much data the &lt;tt&gt;mongodump&lt;/tt&gt; is trying to access.&lt;/p&gt;

&lt;p&gt;Thank you,&lt;br/&gt;
Dima&lt;/p&gt;</comment>
                            <comment id="2264886" author="dmitry.agranat" created="Thu, 30 May 2019 10:40:50 +0000"  >&lt;p&gt;Hi &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=devony&quot; class=&quot;user-hover&quot; rel=&quot;devony&quot;&gt;devony&lt;/a&gt;, thank you for uploading new data, we will analyze it and report back with next steps.&lt;/p&gt;

&lt;p&gt;In the meantime, regarding your latest question:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;I want to also double check that there are no known side-effects to running a primary and replica as a 4.0.9 while there is also secondary on 3.6.6. Obviously we will not set compatibility mode to 4.0 until this is resolved.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;As long as this not a sharded cluster and compatibility mode was not set to 4.0, there should not be any side effect with having one node on 3.6 version until we sort this out.&lt;/p&gt;

&lt;p&gt;Thank you,&lt;br/&gt;
Dima &lt;/p&gt;
</comment>
                            <comment id="2264787" author="devony" created="Thu, 30 May 2019 07:52:57 +0000"  >&lt;p&gt;Hi @Dima,&lt;/p&gt;

&lt;p&gt;I&apos;ve uploaded the relevant diagnostics files through the secure portal. The data from the affected timeframe should be in&#160;metrics.2019-05-29T18-55-39Z-00000&lt;/p&gt;

&lt;p&gt;I want to also double check that there are no known side-effects to running a primary and replica as a 4.0.9 while there is also secondary on 3.6.6. Obviously we will not set compatibility mode to 4.0 until this is resolved.&lt;/p&gt;</comment>
                            <comment id="2264767" author="dmitry.agranat" created="Thu, 30 May 2019 06:46:36 +0000"  >&lt;p&gt;Hi &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=paulblend&quot; class=&quot;user-hover&quot; rel=&quot;paulblend&quot;&gt;paulblend&lt;/a&gt;,&lt;/p&gt;

&lt;p&gt;Thank you for the update. Could you please upload the diagnostic data covering the latest test you did after upgrading your node to 3.6.10? This information would help us to determine the next steps.&lt;/p&gt;

&lt;p&gt;Leaving one node on 3.6 until we&apos;ll sort this out should not be an issue.&lt;/p&gt;

&lt;p&gt;Thank you,&lt;br/&gt;
Dima&lt;/p&gt;</comment>
                            <comment id="2264471" author="paulblend" created="Wed, 29 May 2019 21:40:29 +0000"  >&lt;p&gt;Would there be any problems upgrading 2 nodes to 4.0.x but leaving one as 3.6.x while the backup issue is sorted out?&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;As for the above, I went with option 1 kind of. I upgraded our 3.6.6 machine to 3.6.10. The backup problem came back. I downgraded the server back to 3.6.6. and the problem went away again.&lt;/p&gt;</comment>
                            <comment id="2261494" author="dmitry.agranat" created="Tue, 28 May 2019 06:49:34 +0000"  >&lt;p&gt;Hi &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=paulblend&quot; class=&quot;user-hover&quot; rel=&quot;paulblend&quot;&gt;paulblend&lt;/a&gt;,&lt;/p&gt;

&lt;p&gt;We are still investigating this issue. Currently, one of the suspects is &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-40925&quot; title=&quot;Investigate if checkpoints, sweep and populating of session&amp;#39;s dhandle cache can compete for dhandle list lock&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-40925&quot;&gt;SERVER-40925&lt;/a&gt; or/and the change that was made in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-38779&quot; title=&quot;Build a mechanism to periodically cleanup old WT sessions from session cache&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-38779&quot;&gt;&lt;del&gt;SERVER-38779&lt;/del&gt;&lt;/a&gt;. In order to confirm this is indeed the case, or rule this out, there are two options we can try:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Option 1: Downgrade from 3.6.12 to 3.6.10 (since &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-38779&quot; title=&quot;Build a mechanism to periodically cleanup old WT sessions from session cache&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-38779&quot;&gt;&lt;del&gt;SERVER-38779&lt;/del&gt;&lt;/a&gt; was introduced in 3.6.11) or&lt;/li&gt;
	&lt;li&gt;Option 2: Setting the &lt;tt&gt;wiredTigerSessionCloseIdleTimeSecs&lt;/tt&gt; parameter to 0 on your current version, 3.6.12. The default for the parameter is 300 seconds (5 mins)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Please chose one of the above options, whichever is more convenient for you. &lt;/p&gt;

&lt;p&gt;Once you have repeated the same workload after the proposed change, please upload the new set of requested data into the secure upload portal.&lt;/p&gt;

&lt;p&gt;Thank you,&lt;br/&gt;
Dima&lt;/p&gt;</comment>
                            <comment id="2249305" author="paulblend" created="Thu, 16 May 2019 18:29:07 +0000"  >&lt;p&gt;sent&lt;/p&gt;</comment>
                            <comment id="2249288" author="daniel.hatcher" created="Thu, 16 May 2019 18:19:11 +0000"  >&lt;p&gt;Just 4.0.9 should be sufficient.&lt;/p&gt;</comment>
                            <comment id="2249191" author="paulblend" created="Thu, 16 May 2019 17:39:44 +0000"  >&lt;p&gt;Havn&apos;t had a chance, will get to it today. Do you need the 3.6.12 versions again just the 4.0.9 ones?&lt;/p&gt;</comment>
                            <comment id="2248894" author="daniel.hatcher" created="Thu, 16 May 2019 14:56:02 +0000"  >&lt;p&gt;Hello Paul,&lt;/p&gt;

&lt;p&gt;Have you had a chance to send clean logs? Having the comparison would be extremely helpful.&lt;/p&gt;</comment>
                            <comment id="2240663" author="paulblend" created="Thu, 9 May 2019 21:34:59 +0000"  >&lt;p&gt;Actually disregard and delete those files if possible. I&apos;ll resend new logs in a bit.&#160;&lt;/p&gt;</comment>
                            <comment id="2240582" author="paulblend" created="Thu, 9 May 2019 20:49:29 +0000"  >&lt;p&gt;Timestamps for when the backups were run against 4.0.9 were 10:45am-noon PST 5/9&lt;/p&gt;</comment>
                            <comment id="2240409" author="paulblend" created="Thu, 9 May 2019 19:18:18 +0000"  >&lt;p&gt;I uploaded backup logs and diagnostic data from 4.0.9 and reuploaded the 3.6.6. and 3.6.12&#160;&lt;/p&gt;</comment>
                            <comment id="2239018" author="paulblend" created="Wed, 8 May 2019 19:56:27 +0000"  >&lt;p&gt;I&apos;ll get around to that sometime in the next day or so and upload the files.&#160;&lt;/p&gt;</comment>
                            <comment id="2238850" author="daniel.hatcher" created="Wed, 8 May 2019 17:57:33 +0000"  >&lt;p&gt;Paul,&lt;/p&gt;

&lt;p&gt;That would be a big help!&lt;/p&gt;

&lt;p&gt;Danny&lt;/p&gt;</comment>
                            <comment id="2238827" author="paulblend" created="Wed, 8 May 2019 17:43:33 +0000"  >&lt;p&gt;Do you need me to reupgrade a node to 4.0 to test the backups there and get the logs/diagnostics data again?&lt;/p&gt;</comment>
                            <comment id="2236497" author="sulabh.mahajan" created="Tue, 7 May 2019 03:14:30 +0000"  >&lt;p&gt; &lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;img src=&quot;https://jira.mongodb.org/secure/attachment/216082/216082_server-40433-3.6.png&quot; width=&quot;100%&quot; style=&quot;border: 0px solid black&quot; /&gt;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;I had a quick look at the FTDC data from 3.6.12-bad. Here are my observations:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;From B - C, everything seems to be completely stalled (all the query metrics are 0, R/W global locks are blocked, eviction server is not finding any page to evict and WiredTiger sees no activities at all)&lt;/li&gt;
	&lt;li&gt;The activity starts again, coinciding with obtaining table lock and schema lock inside WiredTiger.&lt;/li&gt;
	&lt;li&gt;Possibly the eviction server is blocked on these locks and could not walk dhandles to find eviction candidates.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Further investigation is needed to figure out what operation caused this 10-second stall. I could not locate FTDC from 4.0, it will be worth looking at that to make sure 4.0 suffered from the same issue.&lt;/p&gt;</comment>
                            <comment id="2229891" author="daniel.hatcher" created="Tue, 30 Apr 2019 20:36:02 +0000"  >&lt;p&gt;Hello Paul,&lt;/p&gt;

&lt;p&gt;It does appear that this is an issue with eviction but I&apos;m not sure yet why one node is worse. The info you&apos;ve provided should be sufficient for me to dig into for now.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;/p&gt;

&lt;p&gt;Danny&lt;/p&gt;</comment>
                            <comment id="2225063" author="paulblend" created="Thu, 25 Apr 2019 18:42:34 +0000"  >&lt;p&gt;Having issues getting exact logs. The bad runs happened between 12:30-13:30 PST yesterday, the good runs happened post 13:30 PST. Having problems finding better time stamps. If you need them I can resend files from today, this time with a mongo log failing to provide better timestamps.&#160;&lt;/p&gt;</comment>
                            <comment id="2225028" author="daniel.hatcher" created="Thu, 25 Apr 2019 18:19:04 +0000"  >&lt;p&gt;Hello Paul,&lt;/p&gt;

&lt;p&gt;Thanks for the logs. Do you have timestamps for your runs that I can use to match with the logs and diagnostics? The output you provided in the &lt;tt&gt;server40433*&lt;/tt&gt; files was very helpful before and would be great to have the equivalent here.&lt;/p&gt;

&lt;p&gt;Danny&lt;/p&gt;</comment>
                            <comment id="2222507" author="paulblend" created="Tue, 23 Apr 2019 20:49:31 +0000"  >&lt;p&gt;I&apos;ll rerun later today or tomorrow, right now 1 is on 3.6.12 and the other is on 3.6.6&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="2222502" author="daniel.hatcher" created="Tue, 23 Apr 2019 20:47:45 +0000"  >&lt;p&gt;Hello Paul,&lt;/p&gt;

&lt;p&gt;Actually, if both of your secondaries are the same size that is an ideal comparison. What versions are they at this point? If one is pre-3.6.12 and one is after, could you run the tests again?&lt;/p&gt;

&lt;p&gt;Danny&lt;/p&gt;</comment>
                            <comment id="2222410" author="paulblend" created="Tue, 23 Apr 2019 20:00:51 +0000"  >&lt;p&gt;Thanks for looking. We have had a couple wrinkles come up.&lt;/p&gt;

&lt;p&gt;The only reason we have a secondary that is so much larger is because the issue was occurring when all the machines were the same size. Increasing the secondary size was a kinda hail mary which I guess might have made things worse. We have since then moved the large machine to be primary and have 2 same sized small machines as a secondary. I can decrease the wiredTigerCacheSize on the primary to test but more likely we will take a few days to upgrade the small machines to all be the same size as the larger one so all caches will be the same large value.&lt;/p&gt;


&lt;p&gt;It turns out we also have this same issue when upgrading from 3.6.6. to 3.6.12, our backups run fine on 3.6.6 but have the same slowness issue on 3.6.12 that we were seeing on 4.0.8.&lt;/p&gt;</comment>
                            <comment id="2221029" author="daniel.hatcher" created="Mon, 22 Apr 2019 19:43:27 +0000"  >&lt;p&gt;Hello Paul,&lt;/p&gt;

&lt;p&gt;Apologies for the delay. Looking into the situation for your 4.0 test, I can see that within 3 minutes of the &lt;tt&gt;mongodump&lt;/tt&gt; starting your WiredTiger cache reached 95% capacity. When the cache takes up that much space, it starts to use application threads that would otherwise be servicing queries to help evict. It dramatically slows down your server which is why the 4.0 &lt;tt&gt;mongodump&lt;/tt&gt; takes so long.&lt;/p&gt;

&lt;p&gt;The question is why did your cache rise from 80% (normal) to 95% (very high) so quickly on 4.0 but not on 3.6. I see that your 4.0 server is configured with twice the amount of RAM as compared to your 3.6 server thus twice the WiredTiger cache size. We have seen in the past issues with eviction when the available cache for a node is very high. &lt;/p&gt;

&lt;p&gt;Would it be possible for you to set the &lt;a href=&quot;https://docs.mongodb.com/manual/reference/configuration-options/#storage.wiredTiger.engineConfig.cacheSizeGB&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;wiredTigerCacheSize&lt;/a&gt; parameter for the larger secondary down to match the default value (61GB) of the other secondary? This may negatively impact the performance of your cluster if you are running a large amount of secondary reads so you should do this during a maintenance period or one of low load.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;/p&gt;

&lt;p&gt;Danny&lt;/p&gt;</comment>
                            <comment id="2217270" author="paulblend" created="Wed, 17 Apr 2019 22:58:26 +0000"  >&lt;p&gt;Any updates?&lt;/p&gt;</comment>
                            <comment id="2202836" author="paulblend" created="Fri, 5 Apr 2019 00:20:31 +0000"  >&lt;p&gt;Let me know if there is anything else I can provide that would be helpful in debugging.&#160;&lt;/p&gt;</comment>
                            <comment id="2199950" author="paulblend" created="Tue, 2 Apr 2019 22:36:42 +0000"  >&lt;p&gt;Thanks for looking. I uploaded the metrics files from diagnostic.data and logs for mongodb3 and mongodb4. I prefixed the files with server40433.&lt;/p&gt;</comment>
                            <comment id="2199820" author="daniel.hatcher" created="Tue, 2 Apr 2019 21:05:14 +0000"  >&lt;p&gt;Hello Paul,&lt;/p&gt;

&lt;p&gt;Thanks for your report. In order for us to diagnose, please attempt the &lt;tt&gt;mongodump&lt;/tt&gt; against both the 4.0 and the 3.6 instances and provide the resulting &lt;tt&gt;mongod&lt;/tt&gt; logs plus &quot;diagnostic.data&quot; folders under the {{$dbpath}}s. You can upload the files to our &lt;a href=&quot;https://10gen-httpsupload.s3.amazonaws.com/upload_forms/5b40bccf-e29e-4adf-ae0d-4a85ccac767b.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Secure Upload Portal&lt;/a&gt;. Please rest assured that only MongoDB engineers will be able to see the files and they will delete automatically after 90 days.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;/p&gt;

&lt;p&gt;Danny&lt;/p&gt;</comment>
                            <comment id="2198596" author="paulblend" created="Tue, 2 Apr 2019 00:59:22 +0000"  >&lt;p&gt;Another note, only one of our mongo instances is on 4.0 whereas the others are on 3.6. When we point the backups to instance on 4.0 they run slow, repointing them to a secondary on 3.6 and they speed back up.&#160;&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10520">
                    <name>Problem/Incident</name>
                                                                <inwardlinks description="is caused by">
                                        <issuelink>
            <issuekey id="575422">WT-4194</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="802411">WT-4869</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="758574">WT-4758</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="808870">WT-4878</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="218572" name="40433.png" size="694139" author="dmitry.agranat@mongodb.com" created="Thu, 30 May 2019 17:27:04 +0000"/>
                            <attachment id="221899" name="SERVER-40433-3.6.6-vs-4.0.9-eviction.png" size="308675" author="haribabu.kommi@mongodb.com" created="Tue, 25 Jun 2019 06:34:05 +0000"/>
                            <attachment id="217421" name="Screen Shot 2019-05-21 at 11.44.02 AM.png" size="517524" author="daniel.hatcher@mongodb.com" created="Tue, 21 May 2019 15:51:20 +0000"/>
                            <attachment id="217420" name="Screen Shot 2019-05-21 at 11.44.10 AM.png" size="557896" author="daniel.hatcher@mongodb.com" created="Tue, 21 May 2019 15:51:05 +0000"/>
                            <attachment id="217585" name="comparison.png" size="401558" author="bruce.lucas@mongodb.com" created="Tue, 21 May 2019 20:18:25 +0000"/>
                            <attachment id="221377" name="image-2019-06-20-17-14-07-249.png" size="31204" author="haribabu.kommi@mongodb.com" created="Thu, 20 Jun 2019 07:14:10 +0000"/>
                            <attachment id="216082" name="server-40433-3.6.png" size="201855" author="sulabh.mahajan@mongodb.com" created="Tue, 7 May 2019 03:01:30 +0000"/>
                            <attachment id="221378" name="server-40433-4.09-metrics.png" size="31204" author="haribabu.kommi@mongodb.com" created="Thu, 20 Jun 2019 07:15:22 +0000"/>
                            <attachment id="218086" name="server-40433-lock-issue.png" size="175560" author="sulabh.mahajan@mongodb.com" created="Tue, 28 May 2019 01:00:27 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>36.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Tue, 2 Apr 2019 21:05:14 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        4 years, 25 weeks, 1 day ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>daniel.hatcher@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            4 years, 25 weeks, 1 day ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>daniel.hatcher@mongodb.com</customfieldvalue>
            <customfieldvalue>devony</customfieldvalue>
            <customfieldvalue>dmitry.agranat@mongodb.com</customfieldvalue>
            <customfieldvalue>haribabu.kommi@mongodb.com</customfieldvalue>
            <customfieldvalue>paulblend</customfieldvalue>
            <customfieldvalue>sulabh.mahajan@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|husnf3:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hui79z:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="3058">Storage Engines 2019-07-01</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10555" key="com.atlassian.jira.plugin.system.customfieldtypes:float">
                        <customfieldname>Story Points</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>3.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                    <customfieldvalue><![CDATA[dmitry.agranat@mongodb.com]]></customfieldvalue>
    

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hus9of:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>