私は pg_upgrade を使用して Postgres のアップグレードに取り組んでいますが、プロセスの核心は、データベースのデータファイル (変更なし) を古いクラスター ディレクトリから新しいクラスター ディレクトリにコピーすることです。データ ボリュームが膨張しないように、インスタンスに 2 番目の EBS ボリュームを接続しました。また、アップグレードを迅速に完了するために、スループットを最大値 (1000MiB/s) に設定し、両方のボリュームの IOPS をデフォルト (4000) のままにして、ボリュームが「最適化」が完了したことを報告するのを待っています。
ただし、アップグレード プロセス中に、操作で大きな連続ファイルをコピーしているにもかかわらず、スループットも IOPS も構成された制限に近づかないことに気付きました。以下は、プロセスの 2 つの異なる実行を示すボリュームの監視のスナップショットです。
OS は Rocky Linux 8.5、インスタンスは Rocky によって構築された AMI を使用して新しく作成された m5a.2xlarge インスタンスで、ボリュームは ext4 としてフォーマットされています。同じ期間のインスタンスの CPU 使用率は次のとおりです。ただし、OS 統計ではかなりの量の IOwait が表示されています。
これらのボリューム、インスタンス、または私が見逃している OS 構成に関して、調整する必要があるパラメーターはありますか? それとも、これは EBS バッキング ストアがビジー状態すぎて実際にニーズに対応できないことの症状なのでしょうか?