上傳到 GCP Apt 工件注冊表的時間非常慢

Question

我有一個 CI/CD 系統，可以將大量大型 deb 上傳到 Apt 包的 Google Cloud Artifact Registry 中。 平均 package 的正常上傳時間大約為 10 秒。昨天，所有上傳到該工件注冊表的命令都開始掛起，直到它們被外部觸發器或超時（超過 30 分鍾）終止。 任何試圖從注冊表中刪除包的嘗試都會超時，而不會刪除 package。我一直用來上傳的命令是：

gcloud artifacts apt upload ${ARTIFACT_REPOSITORY} --location=${ARTIFACT_LOCATION} --project ${ARTIFACT_PROJECT} --source=${debPackageName} --verbosity=debug

我首先將所有 Gcloud 版本更新到最新版本

Google Cloud SDK 409.0.0
alpha 2022.11.04
beta 2022.11.04
bq 2.0.81
bundled-python3-unix 3.9.12
core 2022.11.04
gcloud-crc32c 1.0.0
gsutil 5.16

我嘗試刪除軟件包，認為使用此命令可能工件注冊表變得臃腫：

gcloud artifacts packages delete --location={LOCATION} --project {PROJECT} --repository={REPOSITORY} {PACKAGE} --verbosity=debug

但我一直得到：

 "message": "Deadline expired before operation could complete."

來自原始命令的 debug output 和 delete 命令都是垃圾郵件這種消息：

DEBUG: https://artifactregistry.googleapis.com:443 "GET /v1/projects/{PROJECT}/locations/{LOCATION}/operations/f9885192-e1aa-4273-9b61-7b0cacdd5023?alt=json HTTP/1.1" 200 None

• 當我創建一個新的存儲庫時，我可以上傳到它而不會出現超時問題。

Answer 1

我是 Artifact Registry 的負責人。 首先，對於您在 Apt 存儲庫的更新操作中看到這種延遲，我們深表歉意。 它們可能是由為回購重新生成索引引起的。 回購協議越大，所需的時間就越長。

如果您執行大量單獨的上傳/刪除，這會導致索引生成排隊，並且您會超時。 我們最近確實圍繞此更改了一些鎖定行為，因此我們可能無意中將一個性能問題換成了另一個。

我們計划停止在與文件修改相同的事務中生成索引。 相反，我們將異步生成它，並將研究批處理或重復數據刪除，以便為大量單獨更新完成更少的工作。 這意味着索引在上傳調用完成時不是最新的，但最終會保持一致。

我們現在正在優先處理此問題，但您可能需要幾周時間才能看到性能變化。 唯一真正的解決方法是減少更新頻率或保持存儲庫較小。

再次抱歉，我們絕對想讓它以高效的方式工作。