In T368098#9918849, @xcollazo wrote:

Coming back to:

In T368098#9916796, @Joe wrote:

I think actually @Ladsgroup's proposal seems like the easier solution on the short term. @xcollazo do you see any complication with reducing parallelism of the enwiki dumps?

After perusing code, the only existing mechanism to reduce parallelism in the current dumps infrastructure seems to be slots mechanism. For each snapshot server, we can control how many concurrent jobs are allowed by modifying this variable. The current maxslots is set to 28 slots per host in the profile::dumps::generation::worker::dumper::maxjobs puppet config.

However, this config is global, meaning all jobs from the dumps will be affected. Dumping already takes around ~18 days to finish a full dump, and around ~8 days to finish a partial dump, which leaves us with just a couple more days in the month to do reruns or restarts when needed.

I want to offer a solution though, in next comment.

If we can modify the puppet config to accept a lower amount of slots for snapshot1012, which runs enwiki dumps, we may be able to reduce load on the databases and avoid issues such as T368098#10038621 and T368098#10111093.