Назад | Перейти на главную страницу

Очистка TFS 2015 CodeSense

Недавно я унаследовал ответственность за администрирование экземпляра TFS, но у меня нет предыдущего опыта. База данных для командного проекта, кажется, ненормально выросла за последние 6 месяцев, и чтение всего, что я могу найти, помогло мне (я думаю) определить виновника, но я не знаю, что делать. Любая помощь будет оценена.

Я выполнил запросы, которые широко доступны, например этот:

SELECT TOP 3 o.name, 
SUM(reserved_page_count) * 8.0 / 1024 SizeInMB,
SUM(CASE 
WHEN p.index_id <= 1 THEN p.row_count
ELSE 0
END) Row_Count
FROM sys.dm_db_partition_stats p
JOIN sys.objects o
ON p.object_id = o.object_id
GROUP BY o.name
ORDER BY SUM(reserved_page_count) DESC

Чтобы найти это:

name             SizeInMB       Row_Count
tbl_Content      313489.765625  10090278
tbl_Version      33400.828125   27518951
tbl_AggregateMap 10638.539062   32955145

И этот другой запрос тоже:

SELECT Owner = 
CASE
WHEN OwnerId = 0 THEN 'Generic' 
WHEN OwnerId = 1 THEN 'VersionControl'
WHEN OwnerId = 2 THEN 'WorkItemTracking'
WHEN OwnerId = 3 THEN 'TeamBuild'
WHEN OwnerId = 4 THEN 'TeamTest'
WHEN OwnerId = 5 THEN 'Servicing'
WHEN OwnerId = 6 THEN 'UnitTest'
WHEN OwnerId = 7 THEN 'WebAccess'
WHEN OwnerId = 8 THEN 'ProcessTemplate'
WHEN OwnerId = 9 THEN 'StrongBox'
WHEN OwnerId = 10 THEN 'FileContainer'
WHEN OwnerId = 11 THEN 'CodeSense'
WHEN OwnerId = 12 THEN 'Profile'
WHEN OwnerId = 13 THEN 'Aad'
WHEN OwnerId = 14 THEN 'Gallery'
WHEN OwnerId = 15 THEN 'BlobStore'
WHEN OwnerId = 255 THEN 'PendingDeletion'
END,
SUM(CompressedLength) / 1024.0 / 1024.0 AS BlobSizeInMB
FROM tbl_FileReference AS r
JOIN tbl_FileMetadata AS m
ON r.ResourceId = m.ResourceId
AND r.PartitionId = m.PartitionId
WHERE r.PartitionId = 1
GROUP BY OwnerId
ORDER BY 2 DESC

Найти

Owner           BlobSizeInMB
CodeSense       264426.749071121093
VersionControl  8728.462930678710
TeamTest        477.505887984375
ProcessTemplate 2.953623771484
FileContainer   0.024445533203

И хотя VersionControl = 8GB кажется совершенно нормальным, учитывая наш код, CodeSense безумно большой. Я нигде не нашел информации об этой функции или о том, как ее отключить. Пожалуйста помоги!

PS: Если это связано с функцией CodeLens в VS, мы ее тоже не используем.

team-foundation-server

Эта функция называется CodeIndex, поэтому я не мог ее найти раньше.

Вот вся информация, необходимая для его настройки: https://docs.microsoft.com/en-us/visualstudio/ide/codeindex-command?view=vs-2015

Я выключил его и сейчас пытаюсь уничтожить индекс, но он выдает ошибку

TF246018: Операция с базой данных превысила лимит тайм-аута и была отменена. Убедитесь, что параметры операции верны.

Но это уже другая проблема ...

РЕДАКТИРОВАТЬ: Вот что случилось. Я проверил средство просмотра событий на уровне приложения и обнаружил, что истекло время ожидания:

EXEC CodeSense.prc_DeleteAggregates @partitionId=1

Я проверил SP, и он сделал 3 вещи

Вызов prc_iPrepareExecution который ничего не делает: RETURN 0
Удалить из [CodeSense].[tbl_AggregatorInputQueue] где @partitionId равно 1. Таблица была пуста, поэтому делать там нечего.
Удалить из [CodeSense].[tbl_AggregateMap] где @partitionId равно 1. Я запросил БД и обнаружил, что не было строк с другими идентификаторами разделов. Кроме того, SELECT COUNT(*) на завершение уходило более 5 минут, поэтому я отменил его, и тут меня осенило: Я мог бы просто усечь таблицу, потому что единственный partitionId в моем случае равен 1. Это спасло меня от засорения диска кучей бесполезных журналов транзакций и удаления данных партиями.

Конечно, я обрезал его, но из неумеренности я перезапустил TFSConfig CodeIndex /destroyCodeIndex в моей коллекции, и на этот раз это сработало.

Однако, когда я вернулся на уровень db, чтобы восстановить свое, предположительно, пустое пространство: оно еще не было бесплатным.

Я вернулся в журнал событий и обнаружил EXEC CodeSense.prc_DeleteOrphanedFiles @partitionId=1,@createdBefore=03/17/2019 21:05:28 на этот раз тайм-аут!

Этот SP создает в памяти таблицу вещей, которые нужно удалить, а затем удаляет их. Я создал копию этого SP с TOP 100000 , чтобы ограничить количество строк, удаляемых за раз, и запускал его несколько раз, пока не избавился от 2M + строк.

Однако в какой-то момент за очистку таблиц должно отвечать что-то еще. tbl_FileReference, tbl_FileMetadata и особенно tbl_Content.

Я нашел Сообщение блога это предложило бежать EXEC prc_CleanupDeletedFileContent 1 один раз, а затем EXEC prc_DeleteUnusedFiles 1, 0, 100000 несколько раз.

Через 25 минут большой двоичный объект CodeSense полностью исчез.

Owner           BlobSizeInMB
VersionControl  8728.347916602539
TeamTest        477.505887984375
ProcessTemplate 2.953623771484
FileContainer   0.024445533203

Тем не мение, tbl_Content все еще огромен, и запрос все еще выполняется

Я собираюсь подождать день или около того, чтобы увидеть, улучшится ли положение или мне придется продолжать копать.

РЕДАКТИРОВАТЬ 2: Прошло более 24 часов, а запрос все еще выполняется. Выполнение диагностического запроса говорит мне, что tbl_Content действительно сжимается, и когда я использую опцию «Сжать файлы» в SQL Management Studio, файлы данных начинают иметь намного больше свободного места, поэтому он работает!

Поскольку файлы журнала базы данных не растут и все выглядит стабильно, я думаю, я просто подожду, пока запрос завершит свою работу, перезапущу его для хорошей меры, а затем приступлю к восстановлению неиспользуемого пространства на уровне базы данных.

Удачи, если вы оказались в такой же ситуации.