2016-08-25 3 views
3

GitLab 서버에서 자동으로 배포되는 Azure 웹 사이트가 있습니다. 동일한 스크립트를 사용하여 배포하는 다른 프로젝트와 비교하여 배포 시간이 오래 걸립니다 (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 Console 인스턴스를 열고, D:\home으로 이동하여 얼마만큼의 공간이 남아 있는지를 알려주는 dir을 실행하는 것입니다. 그렇게 될 것입니다.

분명히, 이러한 파일이 처음부터 만들어지는 원인을 조사해야하므로 계속 발생하지 않습니다.

+0

필자는 실제로이 파일들을 (모든) 필요로하지 않습니다. 조사 해줘서 고마워! 현재 파일을 제거하고 있습니다. [elmah] (https://www.nuget.org/packages/elmah/)의 구성이 잘못되었습니다. 오류는 XML 파일 대신 데이터베이스에 기록되어야합니다 (정리 프로세스가 수행되는 곳). 그리고 왜 그렇게 많은 사람들이 있는지를 확인해야합니다. – fero

+0

스테이징 및 프로덕션에서 약 8GB의 불필요한 로그 파일을 삭제 한 후 스테이징 빌드를 배포했으며 1 분도 채 걸리지 않았습니다. 내 문제가 해결 된 것 같아. 고맙습니다! 그런데 웹 사이트를 유지하기 위해 기본 호스트 이름을 사용하기 때문에 "always on"기능으로 인해 오류가 발생했다고 생각합니다. 그러나 우리 앱은'.azurewebsites.net '이름을 좋아하지 않습니다. (비록이 많은 산출물을 생산해서는 안됩니다.) – fero