Как отличить нехватку системного commit от working set VS Code, проверить расширения и собрать безопасные данные без случайного увеличения pagefile.
Working set и commit отвечают на разные вопросы
Зафиксируйте общий показатель Committed и его limit в Windows в момент ухудшения, а не только столбец Memory у VS Code. Microsoft поясняет, что стандартное отображение памяти в Task Manager относится к working set, тогда как Commit size показывает объём виртуальной памяти, зарезервированный процессом. Системное исчерпание commit может затронуть многие приложения одновременно, поэтому зависание редактора рядом по времени не доказывает, что он корневая причина. Запишите также свободное место на системном диске и событие нехватки виртуальной памяти, если оно есть. Не меняйте pagefile во время первого замера: это изменит предел и скроет исходную картину.
Матрица «система — процесс — расширение»
На системном уровне сравните текущий committed charge с limit и отметьте, растёт ли разрыв во времени. На уровне процессов добавьте Commit size для крупнейших потребителей, не полагаясь на working set. На уровне VS Code используйте штатные Process Explorer и code --status, которые рекомендует официальная wiki Performance Issues. Если выделяется extension host, только тогда переходите к запуску без расширений или Extension Bisect. Один снимок не показывает утечку: нужны несколько отметок при одинаковой задаче. Не публикуйте список проектов, аргументы командной строки и имена внутренних расширений; для отчёта достаточно ролей процессов и обезличенных величин.
Обратимый контроль до глубокого профилирования
Сохраните работу, перезапустите VS Code без расширений и повторите короткий нейтральный сценарий, который раньше сопровождался ростом commit. Не открывайте приватный монорепозиторий: используйте минимальную тестовую папку. Если давление исчезает, вернитесь к обычному режиму и применяйте Extension Bisect, меняя один набор за раз. Если общий commit снова растёт при чистом окне, не обвиняйте extension host и переходите к системной диагностике. Microsoft рекомендует VMMap или Windows Performance Recorder для более глубокого анализа, но такие сборы могут содержать чувствительные данные. Их следует делать лишь осознанно, локально и с последующей очисткой перед передачей.
Стоп-условия и доказательства
Немедленно прекратите нагрузочный тест, если committed charge приближается к limit, появляются массовые сбои приложений, Event ID 2004 или система перестаёт устойчиво сохранять данные. Не отключайте pagefile и не задавайте произвольный размер по совету из форума: конфигурация зависит от рабочей нагрузки и политики системы. Для поддержки соберите временную шкалу Committed, обезличенный список Commit size, вывод code --status без путей и результат режима без расширений. Укажите, воспроизводится ли проблема после перезапуска и в минимальном окне. Публичная ветка подтверждает только конкретное наблюдение давления на commit; она прямо не даёт достаточных оснований назначить единственный процесс-виновник.
Материал подготовлен редакцией VOne с применением ИИ для многоуровневой матрицы; определения и инструменты вручную сверены по официальным материалам Microsoft и VS Code.
Источники и проверка
- VS Code Wiki — Performance Issues проверено 2026-08-07
- Microsoft — Troubleshoot application memory leaks проверено 2026-08-07
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.