One system property you should check at may consider adjusting is glide.db.archiving.max_consumer_workers, which sets how many threads run for the archiving process in parallel.
If you don't see this in system properties, it is at the default value which is 4. If you see the property and it is set lower, chances are there was a replication lag issue at one point and this property was set lower to resolve the issue. In conjunction with discussion and monitoring with your platform team, it may now be fine to reset to 4. View this KB for more information:
Customized glide.db.archiving.max_consumer_workers property
You may consider upping the workers to 5 or 6, but again please work closely with your platform team to monitor any performance impacts across the instance.
More properties that affect how archiving processes records can be found in docs here:
Archive rule and destroy properties
