Основният фокус на този блог сайт е производителността в среда на SQL Server. Може да се твърди, че производителността започва с дизайна на база данни и приложения. Но можете също да докажете, че наличието на подходящите ресурси е от съществено значение за доброто представяне. За цялата дискусия относно правилните ресурси (кой модел на процесора, колко памет, какъв вид хранилище) понякога пренебрегваме акта на планиране на капацитета:използвайки данните, които имаме да вземаме информирани решения за това, от което имаме нужда . Планирането на капацитета не е просто да разберем колко дисково пространство ни трябва, а също така включва ресурсите, които екземплярът на SQL Server трябва да има на разположение, за да се справи с работното натоварване.
Нови или съществуващи?
Планирането на капацитет за ново решение е наистина трудно. Трябва да изготвите оценки за работното натоварване въз основа на информацията, която събирате от бизнеса. Това означава, че трябва да задавате трудни въпроси за това колко данни ще очакват през първия месец, първите шест месеца и първата година. Когато идва ново решение, това често е ПОСЛЕДНОТО нещо, за което бизнесът мисли, така че много често ще получите неясни отговори. В случай на ново решение, наистина трябва да направите най-доброто предположение. Не скубайте косата си, опитвайки се да получите точни числа.
Ако решението е от доставчик, трябва да поискате от него препоръки за планиране както за необходимото пространство, така и за необходимите ресурси. Признавам, те може да нямат тези данни, но вие не получавате това, което не поискате. Никога не боли да опиташ.
[Бонус:Ако доставчикът няма никаква информация за предоставяне, не би ли било полезно, ако след като системата работи и работи в продължение на няколко месеца, вие им изпратите вашите данни... като например какъв хардуер имате , и как изглежда натоварването? Не е необходимо това да е 20-страничен текст, но обратната връзка може да ги подтикне към по-проактивни действия занапред.]
По отношение на съществуващо решение, ако имате проблем с производителността или искате да надстроите хардуера, ще искате да съхраните информация за текущата среда, за да планирате нова.
Съхранение
Планиране за сумата необходимото място за съхранение е доста просто, просто изисква известно предварително планиране. В моите статии за проактивна проверка на здравето на SQL Server обсъждам наблюдение на дисковото пространство и включвам заявка за улавяне на информация за файла. Тази заявка улавя размера на файловете на базата данни за екземпляра, както и използваното пространство. Наложително е тези данни да се променят във времето, а това не означава няколко седмици. Търсите да видите как файловете се променят в продължение на месеци, вероятно до една до две години, защото моделите на използване за приложение могат да се променят. Тази информация е лесна за улавяне, изисква малко място за съхранение и е безценна за справка, когато си набавяте място за съхранение. Ако можете да предоставите количествени данни за растежа на системата, тогава имате много по-голям шанс да получите необходимото място отпред, вместо да се налага да го искате по-късно. И когато искате място, не забравяйте да включите tempdb в изчисленията си.
Хардуерни ресурси
ЦП
Оптимизирането на производителността на вашия процесор не се отнася само до броя на процесорите, които имате, вие също трябва да вземете предвид модела и работното натоварване (например склад за данни с големи паралелни заявки срещу OLTP със серийни заявки). С тази информация и малко помощ от Glenn можете да определите най-добрия процесор за вашия сървър. Не забравяйте да вземете предвид разходите за лицензиране и ограниченията въз основа на вашето издание на SQL Server!
Памет
Паметта е сравнително евтина и нашата препоръка е винаги да купувате максималното количество памет, което сървърът може да побере. Четенето на данни от паметта е значително по-бързо от четенето им от диск, така че колкото повече данни се побират в паметта, толкова по-добре. Имайте предвид, че цялата база данни не има да се побере в паметта. Просто се нуждаете от работния набор от данни, за да се побере в паметта. Помислете за база данни от 2TB. Малко вероятно е при OLTP сценарий всички 2TB да се осъществяват всеки ден. Обикновено се осъществява достъп само до последните данни – може би само за последните 30 или 60 дни. Това са данните, които трябва да се поберат в паметта. Но, разбира се, рядко виждаме чиста OLTP среда, често това е смесена среда, защото потребителите обичат да изпълняват отчети върху големи набори от данни и няма хранилище за данни или копие за отчитане на базата данни, така че те имат да стартирате отчетите срещу производството. Това усложнява изискването за памет. Сега, понякога имате нужда от тези по-стари данни в паметта, но понякога не. Важно е да разберете натоварването; какви типове заявки се изпълняват към базата данни?
Ако използвате Standard Edition, проверете дали имате повече памет в сървъра от максималната поддържана памет. Например, при SQL Server 2014 и по-нова версия, в Standard Edition максималният обем памет, който можете да разпределите на буферния пул (чрез настройката за максимална памет на сървъра), е 128 GB. Следователно, вие искате да имате повече памет в сървъра (например 160 GB), за да можете да зададете максимална памет на сървъра на възможно най-високата стойност от 128 GB и все още да имате налична памет за ОС и други процеси на SQL Server. Освен това със SQL Server 2016 SP1 Standard Edition можете да използвате OLTP в паметта с ограничение от 32 GB на база данни. Това е над максималната стойност на паметта на сървъра, така че ако планирате да използвате тази функция, закупете съответно памет.
Съхранение
Когато говорим за изисквания за производителност за съхранение, често чувате хората да говорят за IOPS (входно/изходни операции в секунда). Всъщност тази статия беше вдъхновена от въпрос от зрител, който гледаше моя курс на Pluralsight за сравнителен анализ и базово определяне. Въпросът беше:„Как съпоставяте броячите на монитора на производителността за четене и запис в секунда към потребителски връзки, за да оцените броя на IO на потребител?“ Четенията и записите в секунда са входно/изходните операции, така че разполагаме с тези данни чрез PerfMon на ниво екземпляр и това е, което използвате, за да дефинирате изискванията за IOPS за даден екземпляр.
Въпреки това, ако знаете чете и пише и потребителски връзки, тогава можете да направите малко математика и да разберете IOPS на потребител. Това е полезно, ако планирате да разширите решението и да добавите повече потребители. Искате да сте сигурни, че решението ще се мащабира и една от опциите, която имате, е да вземете изчислените си IOPS на потребител, въз основа на X брой потребители, и след това да оцените IOPS на екземпляра за Y брой потребители. Сега правим много предположения с това изчисление. Предполагаме, че начинът, по който новите връзки използват системата, е същият като днес – това може или не може да е така в крайна сметка, няма да разберете, докато системата не е на мястото си. Когато разберете тази стойност (четене + запис / потребителски връзки =среден IOPS на потребител), тогава знаете как да оцените IOPS за решение въз основа на очакваните потребителски връзки.
След това предавате тази информация на вашия човек за съхранение, за да обсъдите възможните налични конфигурации. Можете да изчислите максималния IOPS за дискова конфигурация, при условие че имате информация за дисковете (например брой дискове, скорост, размер и конфигурация на RAID). Можете да тествате пропускателната способност на IO за устройство с помощта на CrystalDiskMark, въпреки че това може да не е възможно, ако хранилището не е решено. След като е на място обаче, трябва да преминете през това тестване, за да се уверите, че IOPS за дадено устройство може да покрие очакваното работно натоварване.
IOPS са само един от начините да погледнете производителността на съхранението. Разберете, че тези данни ви казват колко IO се случва и в идеалния случай, ако знаете IOPS и имате място за съхранение, което да отговаря на изискванията, тогава забавянето трябва да бъде минимално. Но латентността е това, което влияе на производителността. За да определите каква латентност съществува, ще трябва да използвате инструмент като DiskSpd, за да сравните хранилището. Glenn има страхотна статия, която обяснява как да анализирате производителността на IO, а след това друга статия за това как да използвате DiskSpd, за да го тествате, за да разберете латентността. Силно препоръчвам да прегледате и двете статии, ако не сте разглеждали хранилището и производителността преди това.
Заключение
Планирането на капацитет е нещо повече от това да знаете колко място ви трябва за файловете на базата данни. Трябва да разберете работното натоварване и какво изисква то по отношение на ресурсите на процесора, паметта и диска. За да направите това, имате нужда от данни...което означава, че имате нужда от улавяне на базови линии. Първата ми сесия в общността на SQL Server беше през декември 2010 г. и беше по темата за основните положения. Шест години по-късно все още говоря за важността им и все още чувам от хората, че нямат тези числа. Ако искате да правите интелигентно, целенасочено планиране на капацитета, тогава трябва да съберете подходящите данни... в противен случай просто предполагате.
