Azure網站部署非常緩慢

3

我有一個Azure網站，它由我們的GitLab服務器自動部署。與我們使用相同腳本部署的其他項目相比，這個部署需要很長時間（15-20分鐘）。其他項目通常在1-2分鐘內部署。（給定大致相同的修改量。）Azure網站部署非常緩慢

大部分時間需要的步驟是Handling Basic Web Site deployment。所有其他步驟都在幾秒鐘內完成。

git push天青看起來像這樣（由我添加的SCM網站時間戳）後的日誌：

[2016-08-25T07:42:15.6465159Z] remote: Updating branch 'master'. 
[2016-08-25T07:42:18.2159075Z] remote: Updating submodules. 
[2016-08-25T07:42:18.2783580Z] remote: Preparing deployment for commit id '2a71d1ddd3'. 
[2016-08-25T07:42:18.6221285Z] remote: Generating deployment script. 
[2016-08-25T07:42:18.7658033Z] remote: Running deployment command... 
[2016-08-25T07:42:19.8283917Z] remote: Handling Basic Web Site deployment. 
[       ] remote: ..... [1051 dots here] 
[2016-08-25T08:00:12.4710682Z] remote: KuduSync.NET from: 'D:\home\site\repository' to: 'D:\home\site\wwwroot' 
[2016-08-25T08:00:12.5492017Z] remote: Copying file: '[first file]' 
[2016-08-25T08:00:12.7054553Z] remote: Copying file: '[last file]' 
[2016-08-25T08:00:12.7210814Z] remote: Finished successfully. 
[2016-08-25T08:00:12.8492401Z] remote: Running post deployment command(s)... 
[2016-08-25T08:00:13.0805168Z] remote: Deployment successful.

我不知道是什麼原因造成這種巨大的延誤。而且，延遲從不相同，它會變化幾分鐘。

因爲我不知道哪些信息是重要的，所以我不能在此發佈全部有關我們的項目或Azure網站的信息，請詢問您需要什麼來幫助我，然後編輯我的問題提供必要的信息。

來源

2016-08-25 fero

+0

它有非常大量的文件嗎？ –

+0

@DavidEbbo不，我要推送的存儲庫共有335個文件（12個已修改）。只需2分鐘即可部署的項目之一就是580個文件。 – fero

+0

這很奇怪。它會一直髮生在那一個上？你可以分享你的網絡應用程序名稱，直接或間接地（https://github.com/projectkudu/kudu/wiki/Reporting-your-site-name-without-posting-it-publicly）？這將有助於我們進行調查。謝謝！ –

2

問題的根源在於您的D:\home\site\wwwroot\app_data文件夾下有大量文件。看起來像幾十萬！

它們被命名爲error-2015-02-22235701Z-2ab04577-57f6-43cb-b09a-cc71e354e2f2.xml。許多人很老了，要回2014年

因爲你可能根本就不需要這些文件，請嘗試以下操作：

在捻控制檯中，轉到D:\home\site\wwwroot。不要試圖進入App_Data，因爲文件數量會導致它掛起。
運行del App_Data\error*.xml

預計需要很長的時間！檢查進展情況的一種方法是打開另一個Kudu控制檯實例（在另一個選項卡中），請轉至D:\home，然後運行dir，它會告訴您剩餘多少空間。這應該是在增加。

很明顯，您需要查看是什麼導致這些文件首先被創建，所以它不會繼續發生。

來源

2016-08-29 19:47:39

+0

我確實不需要（所有）這些文件。感謝您的調查！我目前正在刪除這些文件。這似乎是[elmah]的錯誤配置（https://www.nuget.org/packages/elmah/）。應將錯誤記錄到數據庫而不是XML文件（清理過程發生的地方）。當然，我必須檢查爲什麼有這麼多人。 – fero

+0

在暫存和生產中刪除了大約8 GB的不必要的日誌文件後，我部署了一個臨時版本，花費不到一分鐘。我想我的問題解決了。謝謝！順便說一下，我認爲這些錯誤是由於「始終在線」功能出現的，因爲它使用默認的主機名來保持網站的活躍，但我們的應用程序不喜歡'.azurewebsites.net'這個名字。（儘管如此，不應該產生這麼多的輸出。） – fero

Azure網站部署非常緩慢

回答

相關問題