Управління оперативною пам'яттю

Келен Ділану

Чи може файл readme надати додаткову оперативну пам'ять?



При роботі з версіями SQL Server, які передували SQL Server 7.0, системний адміністратор (sa) був змушений виділяти фіксований обсяг оперативної пам'яті для потреб самого SQL Server. Цей обсяг не можна було змінити, не зупиняючи роботу SQL Server. Якщо виділити занадто мало оперативної пам'яті, продуктивність могла помітно знизитися, тому що у SQL Server не вистачить пам'яті для зберігання часто використовуваних даних. З іншого боку, якщо виділити занадто багато оперативної пам'яті (наприклад, більше, ніж є в розпорядженні операційної системи), то SQL Server не зможе навіть запуститися. А якщо SQL Server не можна запустити, то не можна запустити і процедуру, яка зменшила б обсяг виділеної пам'яті, зробивши реконфігурацію. При роботі з більш ранніми версіями SQL Server системний адміністратор повинен був володіти високим рівнем майстерності, щоб забезпечити ефективне використання ресурсів.


Крім цього ранні версії SQL Server не тільки вимагали виділення фіксованого обсягу оперативної пам'яті для всього SQL Server, але також розподіляли виділений обсяг пам'яті за секціями для виконання визначених цілей. Одна з таких секцій, процедурний кеш, призначалася тільки для зберігання планів виконання запитів і збережених процедур. Розмір процедурного кешу фіксувався при старті служби SQL Server і, подібно загального обсягу виділеної пам'яті, розмір цього кешу не можна було змінити при перезапуску SQL Server.


Починаючи з версії SQL Server 7.0, вся картина управління пам'яттю корінним чином змінилася. У системних адміністраторів не тільки з'явилася можливість динамічно змінювати загальний обсяг виділеної для SQL Server пам'яті, але й перерозподіляти у разі необхідності пам'ять усередині SQL Server між різними системними ресурсами. Якщо SQL Server потрібно більше пам'яті для планів виконання запитів, можна звільнити кілька сторінок, що містять дані, і заповнити їх планами виконання запитів. Або ж навпаки, якщо потрібно більше пам'яті для даних, що прочитуються з жорсткого диска, то можна видалити з оперативної пам'яті плани рідко виконуваних запитів.


Оскільки я знаю, що в SQL Server реалізована стратегія динамічного використання оперативної пам'яті, мене дуже здивувало питання про роботу процедурного кешу, який мені поставив слухач на одному з семінарів. Він десь читав про новий перемикачі, який можна використовувати при запуску SQL Server 7.0, щоб обмежити обсяг використовуваної процедурних кешем оперативної пам'яті. Хоча я нічого не знала про це перемикачі, я вірила, що слухач не вигадав цю можливість. Проте в SQL Server 7.0 немає нічого, що називалося б процедурних кешем, тому після семінару я зайнялася вивченням ситуації. У файлі readme_txt, який супроводжує пакет з виправленнями Service Pack 2 (SP2) для SQL Server 7.0, я виявила те, про що говорив мій колега. Але перш ніж я розповім про це перемикачі, звернемося до основ управління оперативною пам'яттю в SQL Server 2000 і SQL Server 7.0.


Адресний простір SQL Server


У будь-якій операційній системі виробництва корпорації Microsoft загальний обсяг віртуальної пам'яті, доступний деякого додатком, називається адресним простором цього додатка. Для SQL Server максимальний розмір віртуальної пам'яті складає 2 Гбайт, якщо тільки не використовується спеціальний режим. У файлі boot.ini операційної системи Windows NT Enterprise Edition або Windows 2000 Advanced Server можна скористатися перемикачем / 3GB для збільшення розміру адресного простору до 3 Гбайт.


У кожного екземпляра SQL Server є адресний простір, що складається з двох основних компонентів. Один основний компонент являє собою буферний пул, який виділяє оперативну пам'ять порціями (Або буферами) по 8 Кбайт. Як SQL Server 2000, так і SQL Server 7.0 використовують цей простір для зберігання сторінок даних та індексів, які SQL Server зчитує з жорсткого диска; кешу журналу транзакцій; планів виконання запитів і збережених процедур; системних конструкцій, таких як таблиця блокувань; а також для інформації користувача процесів. Дещо з перерахованого можна побачити за допомогою системних збережених процедур sp_who і sp_who2. Зазвичай адресний простір цієї області займає майже весь обсяг оперативної пам'яті машини. Однак можна обмежити кількість пам'яті, яке SQL Server буде в змозі використати для буферів кешування, якщо при створенні конфігурації SQL Server вказати параметр max server memory , Тобто максимальний розмір оперативної пам'яті, доступний для SQL Server.


Другий компонент адресного простору SQL Server являє собою область пам'яті, яку я зазвичай називаю небуферним пулом. Ця область оперативної пам'яті зарезервована, перш за все, для компонентів виконуваного коду або для компонентів, що вимагають виділення великих об'ємів оперативної пам'яті порціями, переважаючими 8 Кбайт. До числа таких компонентів належать: виконувані файли і динамічні бібліотеки DLL, які використовують в роботі Open Data Services і серверні мережеві бібліотеки Network-Libraries; бібліотеки DLL постачальника OLE DB для сервера, на якому функціонує SQL Server; а також розширені збережені процедури, використовувані в динамічних бібліотеках DLL і системних збережених процедурах OLE Automation для створення екземплярів об'єктів OLE Automation. Ця область пам'яті може також містити плани виконання запитів і збережених процедур, яким потрібні великі обсяги пам'яті.


Коли служба SQL Server стартує, операційна система завантажує в оперативну пам'ять виконувані модулі SQL Server і ті статичні бібліотеки DLL, які потрібні операційній системі. Після цього резервується секція адресного простору для використання в якості небуферного пулу. За замовчуванням SQL Server резервує 128 Мбайт загального адресного простору плюс необхідний розмір пам'яті для стеків всіх потоків. Цей розмір обчислюється на підставі зазначених вище в конфігурації параметра max worker threads (Максимальна кількість робочих потоків). Для одного потоку резервується приблизно 0,5 Мбайт пам'яті.


Буферний пул забирає все, що залишився адресний простір. Протягом всього часу роботи SQL Server цей простір буде можливе винятково буферному пулу (і пов'язаних з ним об'єктів пам'яті, які також використовують сторінки розміром по 8 Кбайт і тому можуть брати пам'ять з буферного пула).


У файлі readme_txt, який супроводжує пакет SP2, обговорюється застосування для SQL Server 7.0 стартового перемикача / g memory_to_reserve, який можна використовувати для зміни розміру області оперативної пам'яті, що виділяється в якості резерву для небуферного компонента адресного простору. Ось що там сказано:

[Цей перемикач] задає ціле число мегабайтів оперативної пам'яті, які SQL Server залишить доступними для розподілу пам'яті усередині процесу SQL Server, проте за межами пулу оперативної пам'яті SQL Server. Пул оперативної пам'яті представляє собою область пам'яті, яку SQL Server використовує для завантаження в неї специфічних елементів. До них відносяться файли бібліотек. Dll для розширених збережених процедур; постачальники OLE DB, до яких звертаються розподілені запити, а також об'єкти OLE Automation, на які є посилання в пропозиціях Transact-SQL.

Мені здалося, що це опис, що міститься у файлі readme_txt, може внести деяку плутанину з-за неоднозначного трактування термінів. Найбільші сумніви викликає використання терміну пул оперативної пам'яті, memory pool. Фахівці, що працюють в команді розробників SQL Server в корпорації Microsoft, сказали мені, що при спілкуванні між собою вони ніколи не вживають термін пул оперативної пам'яті. Тому я буду продовжувати використовувати терміни буферний пул і небуферний пул.


Коли слід користуватися цим перемикачем?


Якщо є великий обсяг оперативної пам'яті, і процес SQL Server вичерпав усі виділене йому віртуальний адресний простір, може виникнути необхідність змінити обсяг пам'яті, зарезервованої для небуферного пулу. Спробуйте скористатися перемикачем / g, якщо в журналі помилок SQL Server починає регулярно з'являтися таке повідомлення:


Warning: Clearing procedure cache to free contiguous memory.
Попередження: очищення процедурного кеша для звільнення суміжній галузі оперативної пам'яті.

Це повідомлення породжується об'єктами оперативної пам'яті, такими як плани виконання процедур і запитів, які зазвичай запозичують оперативну пам'ять з буферного пула. Коли цим об'єктам доводиться розподіляти пам'ять порціями, розмір яких перевищує 8 Кбайт, вони змушені звертатися за оперативною пам'яттю до області небуферного пулу. Якщо ж в області небуферного пулу розмір безперервної пам'яті виявляється недостатнім, SQL Server починає видаляти з оперативної пам'яті зберігаються там плани виконання процедур. Тим самим SQL Server намагається знайти необхідний обсяг пам'яті, перш ніж повторювати всю операцію наново.


Однак зверніть увагу на коротку попередження, наведене у файлі readme пакету SP2. У ньому йдеться: "incorrect use of this option (/ g) can lead to conditions under which SQL Server may not start or may encounter run-time errors ". Тобто в результаті некоректного застосування цього режиму може статися так, що SQL Server буде не в змозі стартувати, або будуть виникати помилки в процесі роботи. Тому необхідно переконатися в тому, що залишається достатній обсяг оперативної пам'яті для внутрішніх структур SQL Server і мінімальна кількість сторінок пам'яті для даних і планів виконання запитів.


У деяких випадках перемикач / g можна використовувати для зниження надлишкового об'єму зарезервованої пам'яті. Зменшення розміру зарезервованого простору оперативної пам'яті дозволить збільшити обсяг пам'яті, доступний для розміщення сторінок даних та індексів. А це, у свою чергу, призведе до зростання продуктивності додатків, що інтенсивно використовують оперативну пам'ять.


Мої рекомендації


Я настійно рекомендую читачам провести ретельне тестування перемикача / g і не вдаватися до його використання до тих пір, поки в цьому дійсно не виникне необхідність. Хоча файл readme, на який я посилаюся в цій статті, а також опис перемикача / g ставляться до версії SQL Server 7.0, той же самий перемикач існує і у версії SQL Server 2000. Пам'ятайте, що в SQL Server 2000 по замовчуванням обсяг оперативної пам'яті поза буферного пулу дорівнює 256 Мбайт, у той час як в SQL Server 7.0 він становить 128 Кбайт. Крім того, цей перемикач вийде з ужитку, коли з'явиться 64-розрядна версія SQL Server. Адже тоді адресний простір будь-якої програми вийде далеко за межі, які сьогодні обмежують його розмір двома або трьома мегабайтами.


Тим, хто не читає файли readme, вважаючи, що вони призначені виключно для початківців, я раджу переглянути свою точку зору. Багато хто, якщо не всі, файли readme, супроводжуючі пакети виправлень і вихідні продукти, містять важливі відомості про можливості та поведінці програм. Наприклад, в один з пакетів з виправленнями для SQL Server 6.5 розробники корпорації Microsoft включили кілька нових можливостей створення конфігурації системи. А оскільки ні друкована, ні мережева документація не оновлювалися, єдиний спосіб дізнатися про ці можливості – прочитати файл readme.txt.

Келен Ділану (Kalen_delaney@compuserve.com, www.InsideSQLServer.com) має сертифікати MCT і MCSE, працює незалежним консультантом і викладачем на північно-заході тихоокеанського узбережжя США. Почала працювати з SQL Server ще в 1987 році. Келен написала книгу "Inside SQL Server 7.0", випущену видавництвом Microsoft Press, вона також є співавтором книг "SQL Server 6.5 Unleashed" і "Teach yourself SQL Server in 21 days ", виданих у Sams Publishing.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*