2013-03-12 9 views
11

Używam aktualizacji 1 TFS 2012 w systemie Windows Server 2008 R2. Mamy budowę TFS działającą pod kontem TFSUser. Na drugi dzień zabrakło nam miejsca na naszej maszynie do budowania. Po przeprowadzeniu dochodzenia odkryłem, że folder C: \ Users \ TFSUser \ AppData \ Local \ Temp zawiera ponad 50 GB plików, niektóre z nich sięgają października 2012 r. Żaden z plików nie jest zbyt duży, ale nie Wydaje się, że kiedykolwiek się uprzątnięto.Duży katalog TFSUser AppData Local Temp Directory na komputerze kompilacji

Dochodzenie dzisiaj pokazuje, że folder jest zapisywany na wiele podczas automatycznej kompilacji. Dlaczego te pliki nie są oczyszczane i co mogę zrobić, aby upewnić się, że na tym komputerze nie ma już wolnego miejsca?

Aktualizacja 2013-03-13
stworzyłem mały skrypt powershell, który działa nocny usunąć zawartość katalogu Temp. Tutaj jest skrypt powłoki:

Stop-Service TFSBuildServiceHost.2012 
Remove-Item Drive:\Path\To\TFSUser\AppData\Local\Temp\* -recurse -exclude Build* 
Start-Service TFSBuildServiceHost.2012 

Mam zadanie uruchamiane z podwyższonymi uprawnieniami co noc jako konto TFSUser. Podwyższone uprawnienia są potrzebne, ponieważ musimy uruchomić i zatrzymać usługi.

Odpowiedz

8

To jest problem z TFS2010, który, jak sądzę, nie został jeszcze rozwiązany w 2012 roku. System kompilacji tworzy pliki tymczasowe i nigdy ich nie usuwa, prowadząc ostatecznie do awarii, ponieważ dysk jest pełny lub ponieważ używają ograniczonej liczby cyfr dla unikalnych identyfikatorów i wyczerpania nowych identyfikatorów, które mogą być użyte (IIRC, to przewraca się na 65536 plików, które zwykle trafiają na długo przed uruchomieniem miejsca na dysku)

Rozwiązaniem jest okresowe usuwanie plików tymczasowych. Po prostu robię to ręcznie około 2-4 razy w roku. Najbezpieczniejszym podejściem jest prawdopodobnie wyłączenie agentów kompilacji, a następnie wyczyszczenie folderu tymczasowego, a następnie ponowne włączenie agentów (i może nie być złym pomysłem ponowne uruchomienie serwera w tym samym czasie, jeśli działało przez wiele miesięcy).

Alternatywą może być ustawienie małego zaplanowanego zadania codziennie/co tydzień, które usuwa wszystkie pliki tymczasowe starsze niż kilka dni i uruchamianie go w środku nocy, gdy nie wiesz nic więcej (np. Kompilacje nocne) będzie działać.

W każdym razie, jeśli serwer zostanie zrestartowany kilka razy w roku, skrypt startowy, który czyści folder tymczasowy przed uruchomieniem agentów kompilacji, może być czystym rozwiązaniem porządkowym &.

Wszystko zależy od tego, jak szybko twój dysk się zapełni - prawdopodobnie okaże się, że jest to wiele miesięcy nagromadzonego cruftu, a nie coś, co uderza cię po krótkim czasie, w którym to przypadku nie potrzebujesz bardzo agresywnego podejścia aby wszystko działało sprawnie.

+0

Dzięki Jason. Zajrzę do małego skryptu, który zostanie uruchomiony, ponieważ jestem dość zapominalski (stąd programowanie). :-) –

+1

Okazuje się, że jestem też dość zapominalski :-) ... Właśnie sprawdziłem nasz serwer dziś rano i zaplanowałem zaplanowane zadanie, które odbywa się w każdą sobotnią noc o 23:30 i uruchamia 2-liniową skrypt wsadowy: 'del/F/S/Q" C: \ Documents and Settings \ TFSSERVICE \ Ustawienia lokalne \ Temp \ *. * "' 'del/F/S/Q" C: \ WINDOWS \ Temp \ *. * " –

+0

Ten problem pojawił się, gdy projekty instalacji vdproj zaczęły działać nieprawidłowo na serwerze budowania TFS 2010. Devenv próbuje utworzyć pliki tymczasowe podczas tworzenia MSI. Tylko ten szum został znaleziony przez uruchomienie VS i utworzenie nowego projektu MSI/vdproj (na serwerze budowania), a jednocześnie za pomocą ProcMon, a następnie zauważył ogromną masę * COLLISION * NAME wyniki operacji CreateFile w AppData usługi budowania Folder \ Local \ Temp. Czyszczenie tego teraz ... –

Powiązane problemy