Слишком много памяти использовало во время TFS автоматизированную сборку
Мои навыки Perl являются основами, но фильтровать реальную Вершину по имени, сохранить этот код в файл, названный topn.pl:
#!/usr/bin/perl
shift @ARGV;
$name = shift @ARGV;
@pids = `/bin/ps -eo pid,user,args | /bin/grep $name | /bin/grep -v grep | /usr/bin/tr -s " " `;
$arg = "";
foreach (@pids) {
$_ =~ /^\s([0-9]+)\s/;
$pid = $1;
$arg .= " p $pid " if $pid != "";
}
exec("/usr/bin/top $arg @ARGV");
Использование: topn.pl -n FOO c 2 где НЕЧТО является именем процесса, чтобы быть быть grep. Остальная часть args передается вершине.
Вершина принимает в макс. 20 PID как аргументы.
Я в конечном счете нашел причину, почему память использовалась так быстро во время автоматизированной сборки. Путем создания дампа QTAgent.exe мы смогли исследовать его содержание для нахождения то, что находится на "куче".NET. Оказывается, что мы помещали большое количество объектов в объект кэша, и так как жизни объекта кэша для всего процесса, все эти объекты переживали сборку "мусора".
Логика программы в наших тестах генерирует некоторые случайные данные и затем проверяет, чтобы видеть, уникальны ли те данные. По большей части это должно быть, но иногда существует коллизия. Если существует коллизия, мы заканчиваем тем, что кэшировали предыдущие данные. Это не должно быть проблемой, потому что наши тесты очищают свои данные после того, как они сделаны и таким образом, риск коллизии должен быть относительно низким.
Путем исследования, что мы имеем в кэше, мы нашли, что, должно быть, сталкивались с большим количеством коллизий, и оказывается, что наша логика уборки перестала работать только в автоматизированной сборке/тестовой среде из-за некоторых неправильно настроенных зависимостей. Это означает, что каждый раз мы запустили наши тесты, мы генерировали больше данных, которые не очищались, и последующие выполнения рискнут загружать те данные в кэш на время тестового прогона.
Я распознаю, что наличие тестов, которые не полностью изолируются, было частью нашей проблемы, но я хотел бы вызвать несколько других извлеченных уроков:
- Это не верно, что Тестовый Агент будет содержать на результаты тестов способом, которые заставили бы память выходить из-под контроля, когда того же самого не происходит при вызове MSTest из Visual Studio.
- Полезно смочь использовать инструменты как WinDbg и анализ дампа для наблюдения то, что находится в памяти в процессе.
Едва ли проблема вызывается Тестовым Агентом, держащимся результаты всех тестов, таким образом, это может обновить журнал в конце. Моя рекомендация состояла бы в том, чтобы переместить путь от тестов Visual Studio до другого тестового агента (как NUnit).
Это заставит Вас некоторые головные боли быть отодвинутыми, но необходимо закончить с более чистым решением.