Короткий ответ

SQL Server по умолчанию забирает почти всю RAM под buffer pool — это штатно, пока вы не поставили max server memory. На SQL01 оставьте гигабайты ОС (и другим ролям, если они там есть). Если на том же хосте крутятся rphost/ragent (SRV-1C совмещён) — память делят явно, иначе Windows режет working set и 1С «тормозит непонятно». Не reboot SQL каждую ночь «чтобы освободить память»: вы выкидываете кэш и удлиняете утро.

Экземпляр MSSQLSERVER, база Accounting.

Симптомы и как отличить

Типичная картина:

  • Task Manager: sqlservr.exe ≈ вся RAM;
  • сервер «тупит» в консоли, SQL при этом «нормальный»;
  • на совмещённом хосте rphost в page file, 1С тормозит, waits PAGEIOLATCH или наоборот OS freeze.

Отличия:

НаблюдениеНе «SQL жрёт баг»
Высокая RAM, низкий PAGEIOLATCH, 1С летаетнормальный кэш, нужен только cap
RAM 99%, OS freezeнет max server memory
RAM 99%, 1С на том же хостеконфликт с rphost
Рост без нагрузки, leak сторонних SPотдельно, не buffer pool

Возможные причины

  1. max server memory = default (огромный).
  2. Совмещение ролей 1С+SQL без квоты.
  3. min server memory слишком высокий, не отдаёт.
  4. Lock pages in memory без учёта ОС.
  5. Много экземпляров на одном хосте.
  6. SSAS/SSRS рядом, о них забыли.

Диагностика

SELECT name, value_in_use
FROM sys.configurations
WHERE name IN (N'max server memory (MB)', N'min server memory (MB)', N'max degree of parallelism');

SELECT physical_memory_kb / 1024 AS physical_mb,
       committed_kb / 1024 AS committed_mb,
       committed_target_kb / 1024 AS target_mb
FROM sys.dm_os_sys_info;

SELECT type, pages_kb / 1024 AS mb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC;

На хосте:

Get-CimInstance Win32_OperatingSystem |
  Select-Object TotalVisibleMemorySize, FreePhysicalMemory
Get-Process sqlservr, rphost, ragent, rmngr -ErrorAction SilentlyContinue |
  Format-Table Name, Id, @{n='MB';e={[int]($_.WorkingSet64/1MB)}}

Если rphost нет на SQL01 — память только SQL+ОС. Если есть — конфликт.

Решение

Сценарий A. Только SQL на SQL01, 64 ГБ RAM

Оставьте 6–8 ГБ ОС (больше, если много агентов, антивирус, backup). Пример: max 56000 МБ. Подставьте своё.

EXEC sys.sp_configure N'show advanced options', 1;
RECONFIGURE;
EXEC sys.sp_configure N'max server memory (MB)', 56000;
RECONFIGURE;

Действует без рестарта службы; SQL будет снижать target. Смотрите, что OS Free вырос, 1С не стала хуже (если 1С на другом хосте — PAGEIOLATCH не должен взлететь катастрофически; если взлетел — мало RAM под буфер, добавьте память хосту, не снимайте cap в 0).

Сценарий B. Совмещение с SRV-1C на одной VM

Либо разъехаться, либо: посчитать пик rphost (часто несколько процессов × лимит кластера) + ОС + SQL. Пример: 64 ГБ, пик 1С 20 ГБ, ОС 8 ГБ → SQL max ≈ 32–36 ГБ. Лимиты памяти рабочих процессов задайте и в кластере 1С, иначе rphost раздует обратно.

Сценарий C. Lock pages in memory

Если включено: тем важнее адекватный max server memory, иначе ОС не выгрузит SQL и умрёт. Не включайте LPIM «для скорости 1С» без понимания.

Сценарий D. Несколько экземпляров

Каждому свой max, сумма < RAM − ОС.

Контур совмещения ролей: как посчитать cap

На отдельном SQL01 с 64 ГБ ориентир «ОС 8 ГБ + SQL остальное» часто работает. На совмещённом хосте возьмите фактический пик:

  1. В кластере 1С посмотрите число рабочих процессов и лимит памяти на процесс.
  2. Умножьте на пик (не на «сейчас ночь»).
  3. Добавьте агент, RAS, антивирус, backup agent (Veeam может съесть десятки гигабайт на снапшоте).
  4. Остаток — max server memory, с запасом 2–4 ГБ.

Если после cap PAGEIOLATCH на Accounting вырос и проведение замедлилось — вам не «нужно unlimited SQL», вам не хватает физической RAM или диск медленный. Добавьте память VM и поднимите cap, сохранив запас ОС. Не возвращайте значение 2147483647.

На SQL 2019/2022 смотрите memory_utilization_percentage в sys.dm_os_process_memory и physical_memory_in_use_kb. Если sqlservr держит память, но clerks показывают не buffer pool, а что-то вроде stack/reserved — это другой разбор (linked servers, CLR, много сессий). Для 1С обычно всё же buffer pool.

Не ставьте 1С-кластер и SQL на хост с 16 ГБ «как в филиале файловой базы». Клиент-сервер так не живёт: Windows начнёт page file, и симптомы будут «1С зависает», хотя это RAM.

После изменения cap подождите 10–15 минут: target снижается не мгновенно. Не делайте вывод по Task Manager на 30-й секунде.

Как проверить, что проблема устранена

  • Free RAM на SQL01 стабильно не ноль.
  • RDP/консоль живые.
  • Замер проведения документа 1С не хуже (или лучше, если раньше был paging rphost).
  • committed_target ≈ ваш cap.

Повторите замер производительности в час пик.

Если не помогло

  • После cap 1С стала сильно медленнее — мало buffer pool: добавьте RAM или уберите чужие роли, не возвращайте unlimited.
  • sqlservr всё ещё гигантский, но ниже cap — норма.
  • Другой процесс ест RAM (backup, сканер) — не вините только SQL.

Профилактика

  • max server memory в чеклисте ввода SQL в прод.
  • Не ставить кластер 1С на SQL «на недельку» навсегда.
  • Мониторинг available Mbytes и paging.
  • После добавления RAM — поднять cap осознанно, не забыв ОС.

FAQ

Почему SQL сразу забирает память обратно после cap?

До target. Это кэш. Главное — не выше max и живая ОС.

Нужно ли min server memory?

Обычно 0 или умеренный пол. Высокий min мешает отдать память. Не копируйте min = max.

SQL 2022 иначе считает память?

Buffer pool по-прежнему главный. Есть доп. потребители; смотрите clerks, не только «в Диспетчере 80 ГБ».

Помогает ли /3GB в boot.ini?

Нет, это археология 32-bit. Не трогайте.

Стоит ли выключать Lock pages?

Если без LPIM и с нормальным max сервер стабилен — не обязательно включать. Если OS trim бьёт SQL — разбор с осторожным LPIM + строгий cap.