VS Code: языковые серверы и расширения — что съедает память

Прямой ответ

«Лёгкий» VS Code тяжелеет из-за трёх вещей: языковых серверов (отдельные процессы на каждый язык), расширений (каждое живёт в общем extension host-процессе) и файлового наблюдателя на больших проектах. Сам редактор занимает 200–400 МБ; когда в диспетчере задач 3–6 ГБ — виноваты конкретные процессы, и их можно найти и обезвредить за 10 минут.

Архитектура процессов: что искать в диспетчере

VS Code — многопроцессное приложение. В Диспетчере задач Windows вы увидите несколько процессов с одним именем; правильный способ диагностики — встроенный Process Explorer (Help → Open Process Explorer):

Процесс	За что отвечает	Типичный «раздув»
`window` (renderer)	интерфейс, вкладки	десятки тяжёлых вебвью
`extensionHost`	все расширения	«прожорливое» расширение тормозит всех
`tsserver`	TypeScript/JavaScript IntelliSense	1–3 ГБ на больших TS-проектах
`pylance`/`pyright`	Python-анализ	0,5–2 ГБ на крупных кодовых базах
`fileWatcher`	слежение за изменениями	CPU и память на `node_modules`
`ptyHost`	терминалы	запущенные в терминалах дев-серверы

Шаг 1. Найти виновника

Откройте Process Explorer и отсортируйте по памяти — язык-сервер или расширение видно сразу.
Расширения проверяются так: Developer: Show Running Extensions — показывает время активации каждого; команда Developer: Startup Performance — полный профиль запуска.
Если тормозит именно редактор целиком — Help → Process Explorer + перезапуск окон (Developer: Reload Window) для сравнения «до/после» отключения подозрительного расширения.

Шаг 2. Укротить языковые серверы

TypeScript/JavaScript (tsserver):

Исключите из проекта всё сгенерированное: node_modules исключён по умолчанию, но dist, coverage, вендорские бандлы — нет.
В больших монорепо используйте workspace-версию TypeScript и отключите автозагрузку типов: настройка typescript.tsserver.maxTsServerMemory ограничивает heap сервера (значение в МБ).
javascript.disableAutomaticTypeAcquisition: true убирает фоновую докачку @types.

Python (Pylance):

Явно укажите интерпретатор и исключите тяжёлые каталоги через python.analysis.exclude (например, **/migrations, **/data).
Для очень больших репозиториев переведите python.analysis.indexing на нужный минимум и отключите лишние diagnostics-категории — анализ дешевле.

Общее правило: один открытый проект = один активный языковой стек. Мультиязыковые монорепо с 4–5 серверами одновременно умножают расход памяти.

Шаг 3. File watcher и поиск

На проектах с большим node_modules, .venv, кэшами сборок watcher генерирует тысячи событий. В settings.json:

{
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/.venv/**": true,
    "**/dist/**": true,
    "**/.git/objects/**": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true
  }
}

Это снижает и память, и CPU, и нагрев ноутбука — заметно на машинах без активного охлаждения.

Шаг 4. Расширения: гигиена

Отключайте расширения per-workspace, а не глобально: в панели Extensions → Disable (Workspace).
Тяжёлые категории: AI-ассистенты (локальные модели держат память!), Docker GUI, удалённые подключения, Jupyter. Каждое активное ядро (kernel) Jupyter — это отдельный Python-процесс с вашими данными в памяти.
Раз в квартал — чистка: Show Running Extensions покажет, чем вы реально пользуетесь.

Когда память тратят не расширения

Открытые терминалы с дев-серверами, npm run dev, контейнерными CLI — это ваши процессы, а не вина VS Code; считайте их в общий бюджет ОЗУ вместе с Docker (см. WSL2/Docker и ОЗУ).
Большие файлы: редактор держит открытые многомегабайтные JSON/логи в памяти — используйте внешние утилиты просмотра.
Вебвью-панели (браузеры, markdown-preview, дашборды расширений) — каждое это полноценный рендер-процесс.

Пошаговый план диагностики на 15 минут

Снимите показания покоя. Закройте проект, оставьте пустое окно VS Code, посмотрите сумму процессов в Process Explorer. Это базовая стоимость редактора (обычно 300–500 МБ).
Откройте рабочий проект, подождите 2 минуты (прогрев индексов) и снова снимите показания. Разница — стоимость вашего проекта.
Отсортируйте процессы по памяти. Один процесс явно больше остальных — это и есть узкое место: tsserver, pylance, extensionHost или fileWatcher.
Изолируйте расширения. Команда Developer: Reload Window With Extensions Disabled перезагрузит окно без расширений: если память упала в разы — виновник среди них, включайте по одному.
Проверьте гипотезу на чистой копии. Иногда раздувается конкретная рабочая область: откройте подпапку проекта отдельно и сравните.
Зафиксируйте результат в виде «до/после» — так вы отличите разовый сбой от системной проблемы и сможете оценить, нужен ли апгрейд ОЗУ.

Отдельный случай — утечки в долго работающих окнах: если VS Code открыт неделями, потребление медленно растёт. Профилактика проста — периодический Reload Window; если рост лавинообразный, обновите VS Code и подозреваемое расширение: утечки обычно исправляют в релизах.

Специфика удалённой разработки (Remote/WSL/SSH)

При работе через Remote-WSL или Remote-SSH языковые серверы запускаются на удалённой стороне — память расходуется внутри WSL-дистрибутива или на сервере, а не в Windows. Это меняет диагностику: рост vmmem после открытия проекта — нормально, сервер живёт там. Лимиты для такого сценария настраиваются в .wslconfig — см. статью про WSL2 и Docker. Плюс локального окна при этом почти не меняется, поэтому Remote-разработка — рабочий способ разгрузить слабый ноутбук, если есть мощный сервер.

Если после оптимизации всё равно тесно

Если проект объективно большой (монорепо, сотни тысяч файлов), а ноутбук с 8–16 ГБ — упирается не редактор, а сумма нагрузок. Порядок решений: оптимизации выше → меньше параллельных задач → апгрейд ОЗУ. Как оценить нужду в апгрейде по пиковому потреблению — в статье IDE и оперативная память 8/16/32 ГБ.

FAQ

Почему после перезагрузки VS Code снова «раздувается» до 2–3 ГБ? Это кэши и индексы языковых серверов после прогрева — нормальное поведение. Тревога — когда рост продолжается бесконечно (утечка конкретного расширения: обновите/отключите его).

Помогает ли отключение мини-карты и анимаций? Для памяти — почти нет, это про CPU/GPU. Память экономят только процессы: серверы, расширения, вебвью.

Стоит ли переходить на Cursor/VSCodium ради экономии? VSCodium — тот же код без телеметрии, экономия незначительна. Форки с AI-функциями чаще добавляют расход, а не экономят.

Как ограничить память расширений принудительно? Прямого лимита на процесс расширения нет; помогает отключение виновника и лимиты языка-серверов (например, maxTsServerMemory).

Источники: официальная документация VS Code и wiki проекта по производительности (ссылки в шапке).

Языковые серверы VS Code: почему редактор занимает гигабайты и как это исправить