2016-08-25 142 views
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網站的信息,請詢問您需要什麼來幫助我,然後編輯我的問題提供必要的信息。

+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,它會告訴您剩餘多少空間。這應該是在增加。

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

+0

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

+0

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