This happens some weeks ago in a project where the solution partner needs to import 2.1 million products to setup the Magento 2 Commerce instance. Struggling with the default Magento 2 Import/Export functionality, they'll end up with M2IF. So far so good.
The 2.1 million products are separated in bunches with 100k SKUs. Start importing the files one after another, NOT using the bunch functionality, after several files of 100k items per file, the speed slows down from ~2.000/min to 250/min. Now running the previous files again Pacemaker is still performing at 250/min (see image above).
After contacting us on our Slack Support Channel, our first assumption was something like a memory problem. After checking all the basic stuff and have some discussions with our DevOps, we came to the conclusion that the problem has to be originated in the AWS infrastructure. During the day Brent, one of the solution partners DEVs, and his collegues figured out that the problem was the EBS Volume Type of the DB node, whereas the web node was a t3.large with unlimited enabled and the DB server a r5a.2xlarge instance, also with unlimited enabled.
In the Amazon AWS EC2 User Guide we found the following chapter that explains the problem.
Each volume receives an initial I/O credit balance of 5.4 million I/O credits, which is enough to sustain the maximum burst performance of 3,000 IOPS for 30 minutes. This initial credit balance is designed to provide a fast initial boot cycle for boot volumes and to provide a good bootstrapping experience for other applications. Volumes earn I/O credits at the baseline performance rate of 3 IOPS per GiB of volume size. For example, a 100 GiB gp2 volume has a baseline performance of 300 IOPS.