Вопросы Теги

Просмотр Использования оперативной памяти кэша SQL?

Я имею честно говоря, это походит на неправильный способ работать это.

В первую очередь, нет никакого способа знать, будет ли удаленная машина поддерживать inotify.

Во-вторых, это походит на большое усилие объединить то, что является традиционно обобщенным решением двух частей в единственную часть определенное решение. Отслеживание и сообщение на удаленных машинах редко лучше всего выполняется с ssh. При необходимости в этом уровне информации об удаленном хосте Вы обычно хотите поместить программный агент на удаленный хост, который может сделать контроль, и затем работать, система контроля на другом поле, чтобы опросить агент (или иметь агент сообщают).

Если бы Вы хотите добавить эту способность к полю, не устанавливая дополнительный агент, SNMP был бы логическим выбором (многие/больше всего, хосты поддерживают SNMP из поля или имеют предоставленный пакет SNMP поставщика). Поочередно, большинство агентных систем контроля, таких как Nagios, BigBrother/Hobbit/BigSister, Munin, и т.д., предлагает способность определить Ваши собственные плагины. Не было бы настолько трудно создать находящийся в inotify плагин.

Если бы Вы не хотите использовать полноценную систему контроля для контроля удаленного поля, я использовал бы что-то как func, который служит лучшей основой для этого, чем ssh.

2
задан 23 February 2010 в 22:45
2 ответа

Perfmon.exe

Сначала посмотрите на тип объекта Процесса. Это имеет экземпляр для каждого процесса в системе и содержит метрики как Виртуальные Байты, Виртуальный Пик Байтов, Рабочий набор и Пик Рабочего набора. Экземпляр SQL Server назовут в честь имени процесса, 'sqlservr'. Рассмотрение всех экземпляров, которые можно быстро видеть, какой процесс вызывает большую часть потребления памяти.

Следующий взгляд на собственные счетчики SQL Server. В SQL менеджер по Server:Buffer возражает, что Вы найдете SQL Server собственными счетчиками. Необходимо посмотреть на счетчик Общего количества страниц, который считает всю память прослеженной SQL Server внутренне. Счетчик находится на страницах, таким образом, необходимо умножиться на 8 192 для получения байтов.

Там может быть большим несоответствие между Процессом Виртуальный счетчик Байтов и Общим количеством страниц own's SQL. Это может произойти, когда SQL использует AWE для отображения памяти, и SQL может использовать AWE на x64 платформах также.

Можно также отследить SQL Server moemory потребление с внутренней части, посмотреть на sys.dm_os_memory_clerks или выполнить DBCC MEMORYSTATUS.

Если Вы находите, что SQL Server использует память: закройте свой сеанс, установите руки с клавиатуры и уйдите. Это - нормальное, намеченное и желаемое поведение. Если Вы нуждаетесь в памяти для какого-либо другого процесса, отодвигаете тот процесс от того же хоста как SQL. Никогда не выполняйте ничто больше на том же хосте, Вы выполняете SQL Server (никакой IIS, никакой ASP, никакой обмен, никакой DC, никакой DNS/ветры, ничто).

4
ответ дан 3 December 2019 в 09:51
  • 1
    Спасибо за помощь. У нас есть один экземпляр sqlserver. Всего страниц постоянно находится в 1,664,000 = 13 ГБ. Сумма я просто установил его на. Мы также выполнили DBCC MEMORYSTATUS. Кажется, что SQL Server НЕ является преступником. Еще раз спасибо за Вашу справку! –  Django Reinhardt 23 February 2010 в 22:48
  • 2
    Рассмотрите, хотя это Общее количество страниц только отслеживает память, выделенную пулом буферов SQL Server. В процессе SQL существуют другой выделения памяти также. Некоторые видимы в DBCC MEMORYSTATUS, но некоторые - not' t (особенно память, выделенная загруженными библиотеками, как в proc COM серверы или некоторый xp_ расширенный procs), таким образом, Вы can' t знают наверняка. Счетчик перфекта Процесса будет дорожка они, таким образом, лучше проверят дважды. –  Remus Rusanu 24 February 2010 в 00:29
  • 3
    Хорошо, это кажется мной wasn' t смотрящий на точно правильные числа. В Perfmon я должен был смотреть SQL Server: Диспетчер памяти-> Общая Память сервера . И в SQL я могу просмотреть заблокированные страницы путем ввода: выберите * из sys.dm_os_process_memory. Этот блог объяснил все это: bit.ly/SQLRAMUsage –  Django Reinhardt 24 February 2010 в 13:51

Просто немного комментария: если можно свободно "сбросить сервер и спугнуть то, что использует его", затем можно также просто остановить сервис SQL Server.

Если Вы сделаете это, то Вы будете знать наверняка, если это будет на самом деле SQL Server, который израсходовал всю Вашу память.

1
ответ дан 3 December 2019 в 09:51
  • 1
    That' s очень положительная сторона. Мы can' t " freely" сделайте это, но you' право ре. Если we' ре вызвало для сброса, мы должны попробовать это сначала для проверки. –  Django Reinhardt 24 February 2010 в 12:57
  • 2
    SQL был по-видимому виноват! Большие взгляды, Спасибо! –  Django Reinhardt 24 February 2010 в 13:48

Теги

Похожие вопросы