Добрый день всем!
На сервере 512 ОЗУ, настроил в соответствии с рекомендациями 1С: минимум 280, максимум 420. Так же настроил tempdb: 4 файла по 16 Гб.

Подскажите, пожалуйста:
1. Почему при старте MS SQL сразу не забирает под себя 280 Гб ОЗУ?
2. Почему файлы tempdb разрастаются? Может MS SQL их увеличивает исходя из объема ОЗУ? Просто я выдели под tempdb  диск 100Гб, а свободно в нем всего 9 Мб...

Благодарю за ответы.

А базы небось в десяток терабайт?

(0) Ты же сам разрешил, скуль он такой.. дюже прожорливый. Как хохол, "что не зъим, то понадкусаю"

(1) Нет, большая база по сути одна 250 Гб, но пользователей около 120.
(2) Я разрешил ОЗУ, но почему растет tempdb?

(0)ты не поверишь, но tempdb  тоже можно ограничить, и при таком озу, проще хранить его там

(4) Да, я знаю, что можно ограничить. Но сначала хочу понять, почему растет? А то ограничу и это приведет к тормозам.
А что эффективнее? tempdb на 64 Гб в ОЗУ запихнуть, или пусть эти 64Гб себе сквел заберет?

(5) эффективнее, не допускать роста темп дб, нагружая транзакциями и невъэбенными неоптимизированными запросами с кучкой временных таблиц

Ну и..сетевые протоколы то хоть какие в скуле ?

Какое приращение стоит в темпдб и в самой базе ? Поди 10%, да ?
:)

(6) КА типовая без каких-то доработок. Так что это вопрос к 1С :)
(7) Общая память и tcp/ip
(8) по 512Мб приращение, без ограничений.

(9) Без ограничений, то есть пока весь диск занят не будет. Всё просто.

(1) я это понимаю, но почему растет tempdb? Вопрос то в этом? ОЗУ с

(11) потому, что если нет ограничений - серверу дешевле выделить новое место, чем переипользовать освобожденное. (посмотри свободное место в темпдб - его там наверняка будет процентов 95-98)
Если работа не 24/7, то самое тупое решение - периодически (допустим, раз в неделю) рестартовать сиквел. менее тупое - поставить в план обслуживание скрипт по сжатию.

(12) то есть так: у меня 100 Гб выделено под tempdb, сиквел сам расширил файлы tempdb так, чтобы все 100Гб поглотить, не смотря на то, что из 512 ОЗУ использовано только 130.

Забить и расслабиться, или выделить под tempdb ещё 100Гб? Есть в этом смысл? Место не проблема. Просто хочу понять на сколько это оправдано.

А почему на ИТС рекомендуют создать 3-4 файла tempdb?

(13) " из 512 ОЗУ использовано только 130" - а SQL какой версии? Стандарт? Он только 128Гб ОЗУ съесть может.

(14) Нет интерпрайз, все норм. При загрузке ИБ он съел 290+ просто видимо при работе нагрузка пока не такая большая. При закрытии видимо доест оставшееся :)

(14) этот лимит в стандарт только на buffer pool, а так занимает сколько выделить

(15) Где все деньги находят на покупку ентерпрайз?  :)

(0) плюсов от установки большого минимуму на tempdb нет, он растет сам. Минусы работа TRIM на SSD, что может сказаться на производительности, так нужной для tempdb.

(13) использование и размер tempdb не зависит от количества ОЗУ, оно для другого. Если для и внутри tempdb реально закончится место, то база выйдет в критичную ошибку out of disk space.

4 шт для лучшей параллельной работы, это рекомендация Microsoft

Что ж, получается надо ещё 100Гб накинуть на диск с tempdb. Но все равно не понятно с чего так растет... что влияет на это. Может количество одновременных подключений?

(20) Например, реструктуризация таблицы на 50Гб приведет к одномоментному росту тембдб на эти 50гб.

(20) Всё что захапано скулем, он без принудительных действий не отдаст. Просто при необходимости будет использоваться. А будет или нет та самая необходимость не особо понятно. Потому и "жмут" эти таблицы что при неипических размерах на самом деле занято с гулькин хрен.

(19) в 2019-й версии сделали возможность заменять темпдб на данные в памяти. Там размер памяти буде твлиять на рост темпов. а пока - лучше запихать в регламент шринк темпов.
ТС, кстати, так и не ответил, сколько у него в тех темпах свободного места.

(23) Сорри, упусти. Выделено 99891Гб, доступно... 99476Гб...

В общем понятно, можно думаю расслабиться. Ибо если выделю 200Гб, tempdb и их сожрет :)

Благодарю всех за подсказки!