Чому потрібні періодичні перезавантаження, щоб мій екземпляр працював добре?

У нас є виробничий сервер БД на SQL 2005. Все працює нормально деякий час, але через пару тижнів ми спостерігаємо помітне падіння продуктивності. Тільки перезапуск SQL Server приводить продуктивність у норму.

Деякі відомості:

• Працює понад 1200 баз даних (переважно одиночний орендар, декілька орендарів). Перш ніж хтось читає лекції про переїзд лише до орендарів, є поважні причини збереження цієї структури ......
• Оперативна пам’ять - 16 ГБ. Після перезавантаження SQL Server не займе багато часу, щоб повернутися до 15 Гб.
• Активні підключення до БД - це близько 80 з'єднань - що, на нашу думку, є досить здоровим, враховуючи, що є один пул підключень на веб-сервері за процес - тому у нас не виникає проблем із витоком з'єднання.

Ми спробували кілька речей у не пікові часи: - Запустіть DBCC DROPCLEANBUFFERS (з CHECKPOINT), щоб очистити кеш даних. Це не має ефекту, а також не очищає використання оперативної пам'яті). - Запустіть FREEPROCCACHE та FREESYSTEMCACHE, щоб очистити плани запитів і збережений кеш-пам'ять. Без ефекту.

Очевидно, що перезапуск SQL Server не є ідеальним в активному виробничому середовищі. Нам щось не вистачає. Хтось ще пройде через це?

ОНОВЛЕННЯ: 28 квітня 2012 р. Досі вирішується ця проблема. Я знизив пам'ять для SQL Server до 10 Гб, щоб виключити суперечки з ОС. Я наближаюся до його звуження, але мені потрібна допомога в наступному кроці.

Ось що я виявив, після перезавантаження SQL Server файл сторінки коливається між 12,3 ГБ і 12,5 ГБ. Так буде залишатися цілими днями. Загальна кількість потоків серверів буде зависати між 850 і 930 - також стабільна і стабільна протягом днів (sqlserver постійно знаходиться між 55 і 85 з тих, що залежать від трафіку).

Потім, є "подія". Я поняття не маю, що це за подія, я не можу бачити це в журналах, і я не бачу нічого послідовного в день тижня або час, коли це трапиться, але весь пильний файл сторінки сторінки переходить на 14.1 або 14.2 GB, а нитки переходять до між 1750 і 1785 роками.

Перевіряючи perfom, коли це відбувається, понад 900 з цих потоків є sqlserver. Тож я переходжу до sp_who2, щоб побачити, звідки беруться ці потоки ... і є лише використані 80 або близько db-з'єднань.

Отже .... чи є у когось ідеї, як я можу знайти, де решта цих 900 потоків на SQL сервері, і що вони роблять?

ОНОВЛЕННЯ: червень-01-2012 Проблема все ще вирішується . Для тих, хто все ще читає це питання, проблема з перескакуванням ниток вирішена. Це було викликано автоматизованим програмним забезпеченням для резервного копіювання ComVault. Це створювало потік, намагаючись створити резервну копію баз даних, яких вже не було (вона підтримувала список попередніх баз даних), а не просто резервне копіювання поточних баз даних.

Але - питання все ще залишається, і нам доводиться перезапускати кожен тиждень, давати або займати кілька днів. Робота з командою Rackspace, щоб дізнатися, чи можуть вони пролити світло.

Ви кажете, що все нормально, то через пару тижнів продуктивність падає. (Зазвичай люди стверджують, що продуктивність падає швидко, або в певний час, або з наче випадкові проміжки часу. Це може означати погану продуктивність вводу / виводу, блокування штормів або запитів, що інтенсивно працюють на процесорах, у запущений час, або важку заплановану роботу або відсутність індексація або погана статистика, що спричиняє запити, що вимагають процесора чи читання диска. Або інші речі.) Тижні незвичні.

Моя гіпотеза полягає в тому, що інша програма на вашому сервері просочується пам'яттю. Я бачив це з програмним забезпеченням для вірусів (улюблений злодій кожного сервера DBA) та програмним забезпеченням для моніторингу сторонніх виробників. Я б ще раз перевірив використання пам’яті SQL Server із часом, і я також захоплю все використання пам’яті для всіх інших програм у вікні. Якщо для використання пам’яті SQL Server встановлено жорсткі обмеження, і він налаштований таким чином, щоб не дозволяти пейджингові повідомлення, можливо, інші програми виходять з режиму виходу на екран і втрачають потужність вводу / виводу.

Не важко шукати. Якщо ви вже не зберігаєте показники на сервері, я б просто запустив Perfmon і змусив би його взяти зразок кожні 30 або 60 хвилин. Через кілька днів, можливо, ви побачите інше використання пам’яті програм, що повзе вгору.

Чи існують повідомлення про помилки в журналі журналу SQL Server, в якому зазначається, що "значні частини сервера sql були викладені на сторінку"? Це також було б великою підказкою.

Дозвольте привітати вас за те, що ви змогли запустити 1200 БД на одному екземплярі SQL-сервера лише з 16 ГБ оперативної пам’яті та матимете лише такі проблеми після пару тижнів безперебійного запуску. Приємна історія, яку можна розповісти в місцевому розділі PASS.

Тепер для усунення несправностей: Ваша оперативна пам’ять становить 16 ГБ як для SQL, так і для ОС. Я припускаю, що ваш максимальний об'єм пам'яті становить 15 Гб або макс. Це може призвести до того, що буферний пул використовує всю пам'ять і заглушує ОС. Ви говорите, що очищення пулу буферів і кеш-пам'яток не відрізняється, плюс ваш PLE вище 300. Це свідчить про шиї пляшок пам'яті. Яким чином CPU та IO на сервері (специфікації / статистика)?

Запустіть select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidі які вмісти ресурсів ви бачите (wait_type, wait_time, last_wait_type, wait_resource).

1200 баз даних, ОС та, можливо, інші речі? Так, я думаю, що самому серверу для функціонування потрібно більше 1 Гб оперативної пам’яті, особливо зважаючи на те, що якщо ви встановите 15 Гб як максимальну пам'ять SQL Server, йому все одно потрібна додаткова пам'ять поза цим 15 Гб для потоків.

Я б зіткнувся з SQL Server до 14 Гб, щоб дати сервера трохи більше місця для дихання.

Також приклад, наведений у "Професійних внутрішніх справах та усунення несправностей SQL Server 2008" для резервів пам'яті в системі SQL Server 2008 x64 із утилітою резервного копіювання третьої частини з 16 Гб оперативної пам’яті:

• 2 Гб для Windows
• 1 Гб для робочих ниток
• 1 Гб для MPA і т.д.
• 1 Гб для програми резервного копіювання
• 11 Гб для SQL Server

У книзі показано, як визначити максимальну кількість потоків, які ви можете мати, і як обчислити, скільки пам’яті вони займуть. Запустіть це (змініть тип сервера, щоб він відповідав вашому серверу), щоб зрозуміти, скільки пам'яті знадобиться вашим потокам.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Якщо пам’ять бази даних рівномірно розподіляється по всіх базах даних, у вас є лише 12,8 мег для кожної бази даних (15 * 1024) /1200=12,8. Вам потрібно більше пам’яті.

Вам потрібно вивчити, чому продуктивність сповільнюється. Ви бачите блокування, блокування тощо? Як виглядає статистика очікування?

Команди DBCC збираються лише очистити буфери пам'яті, вони не збираються повернути пам'ять в ОС.

Чи знаєте ви, що SQL Server фактично споживає пам'ять? Я б запропонував поглянути на налаштування сеансу Perfmon або почати збирати інформацію DMV після перезавантаження, щоб дізнатися, що робить і працює над SQL Server. Також зверніть увагу, якщо користувачі виконують більше роботи, ніж зазвичай, під час вашого збору (наприклад, обробка в кінці місяця тощо). Чи використовуєте SSRS, SSIS або SSAS на одному сервері?

У вас 1200 баз даних у системі, який у вас найбільший розмір БД?