|
GaryaSQL-сервер - это серверное ПО, и оно должно по возможности наиболее эффективно использовать ресурсы сервера. Поэтому если оно захапало себе всю память, оно просто-напросто пытается максимально эффективно использовать имеющиеся у сервера ресурсы, и это нормально. Чем больше размер всех кешей (который определяется динамически), тем больше сожрано оперативной памяти и тем меньше среднее время ответной реакции сервера на SQL-запрос.
это понятно )
GaryaОткрытые сессии, по идее, должны оставаться открытыми, если с этими сессиями кто-то работает. Если убить работающий процесс с помощью kill, то иногда это может привести к рассогласованию данных в БД, если разработчик не догадался взаимосвязанные изменения данных по множеству счетов, регистров, справочников, документов, обернуть в транзакцию. Если пользователь завершил сеанс, то сессия должна закрываться. Если она почему-то не закрывается, нужно работать конкретно над этой проблемой, и вопрос стоит совершенно иначе.
это тоже понимаемо и понятно. я не предлагал рубить сессии пользователей MS SQL. этот вопрос касался 1с-ных сессий. я понимаю, что сервер предприятия 1С сам должен корректно заканчивать сессии иначе это неизбежно приведёт к проблемам.
GaryaУвеличение размера Tempdb тоже не столь трагично. Если размер этой БД увеличивается, значит ей это нужно. Значит большое количество пользователей запускает транзакции, в которых активно используются временные таблицы. Если размер Tempdb большой, значит его не нужно увеличивать, когда его размера не хватает. Необходимо помнить о том, что операции, связанные с изменением размера кешей, баз данных, занимаемой памяти, сами по себе ресурсоемки и вызывают задержки в отклике SQL-сервера. Поэтому не нужно возвращать сервер в то состояние, в котором он опять вынужден будет перестраиваться и приводить к подобным задержкам. Дайте ему возможность выйти в рабочий режим и лишний раз не трогайте.
об этом я тоже не спрашивал в контексте SQL - то, что темпдб забивается - я даже знаю чем. программисты работают и пытаются оптимизировать свои алгоритмы, мне же надо оптимизировать работу сервера SQL. с ТемпДБ как раз всё даже не так уж плохо. до меня вообще темпдб не делилась на файловые группы, и была на одном винте вместе с логом транзакций. сейчас 20 файлов tempdb на разных дисках, дисковая очередь сократилась, сложные отчеты активно использующие временные таблицы стали отрабатывать шустрее.
GaryaИ, наконец, попытайтесь ответить на вопрос, зачем Вам нужна та память, которая не используется SQL-сервером. На сервере что, еще какое-то ПО запущено, которому эта память нужна? Если это так, то проблема как раз в этом. Не нужно на одном сервере запускать несколько разных программ, которые конкурируют между собой за ресурсы этого сервера. Потому что постоянный пересмотр, у кого отнять память и кому ее отдать, опять-таки вызывает "замирания" в работе всего ПО, которое на этом сервере используется. В принципе, SQL-сервер сам способен освобождать память, если ОС его об этом попросит. Если ОС его не просит, значит ей эта память, как бы без особой надобности.
мне не память его нужна как таковая (на этом сервере кроме сиквела ничего больше нет, сервер предприятия 1С на отдельном физическом сервере). Я просто вижу, что если завершить сессии 1С (регламентная перезагрузка 1С и SQL серверов) - то до утра память сервера не "сьедается" даже на 50%, т.е. "уснувшие/висящие/спящие и пр." сессии отжирают память зря. вот с этим и хотел бороться.
GaryaНу и напоследок, Вы можете ограничить размер памяти, используемый SQL-сервером, если в этом действительно есть необходимость.
нет. нету ) понятно, что он (сиквел) не просто так память ест. и кроме него на этом сервере память больше никому не нужна.
|
