Да бъдеш администратор на база данни може да бъде много предизвикателство в моменти, когато трябва да отстраняваш проблеми с производителността. Сървърът на базата данни е само един компонент от екосистемата на приложенията и рутинно се обвинява като проблем с производителността. SQL Server е една от онези черни кутии, които мнозина не разбират, подобно на SAN и мрежата. Производствените DBA, които наблюдават своите сървъри, могат бързо да идентифицират дали SQL Server работи извън нормалната си базова линия, но има две основни области, в които нямаме видимост:SAN и мрежата. DBA редовно трябва да работят с други инженери, когато става въпрос за отстраняване на проблеми с производителността, които не са пряко свързани със SQL Server. Можем лесно да проследяваме производителността на диска, като наблюдаваме sys.dm_io_virtual_file_stats , за което писах в Мониторинг на латентността при четене/записване; обаче проследяването на проблеми с производителността на мрежата в SQL Server не е толкова лесно.
Лошата производителност на мрежата може да бъде безшумен убиец за производителността на приложенията и моят личен опит показа, че това е така в много случаи. Често едно приложение ще започне да има проблеми с производителността и инженерът на приложението ще каже, че сървърът на приложения изглежда добре и започва да сочи с пръст базата данни. Ще получа обаждане да разгледам сървъра на базата данни и всички индикации показват, че сървърът на базата данни е в добро състояние (и това е мястото, където наблюдението за ключови показатели за ефективност и наличието на базова линия помага!). Тъй като екипите на приложенията и базата данни казваха, че всичко е наред, бихме помолили екипа на мрежата да провери нещата. Екипът на мрежата ще разгледа няколко неща и ще даде всичко ясно от своя страна. Отстраняването на неизправности на всеки екип и прегледът на съответните им системи отне време, като междувременно работата на приложението все още страдаше. След това проблемът щеше да ескалира, докато всички екипи не бъдат помолени да се присъединят към конферентен мост, за да отстранят проблемите заедно. В крайна сметка някой ще започне по-задълбочен мрежов тест и ще определи, че или имаме насищане на портове, маршрутизиране или някакъв друг сложен проблем с мрежата. Няколко щраквания или промяна на нещо в крайна сметка биха разрешили забавянето на приложението.
Най-значимият проблем с мрежата, който съм срещал с клиенти, обикновено включва честотна лента при извършване на архивиране. Много по-големи организации мигрират към 10Gb мрежа за основна инфраструктура, но когато работите както с физическа, така и с виртуална мрежа, е лесно да конфигурирате неправилно настройка или порт и да намалите до 1Gb. За редовен мрежов трафик на приложения може да не забележите влошаване на производителността, но веднага щом започнете да се опитвате да копирате 100s GB данни за архивиране, тези 1Gb ще се насити и вашите задачи за архивиране и възстановяване ще пострадат.
За DBA може да бъде предизвикателство да накарат другите да се вгледат толкова дълбоко в проблемите, които не смятат, че са техен проблем, защото първоначалните индикатори не разкриват проблема. Възможността да се въоръжите с данни, преди да се свържете с други екипи, ще ви помогне да ги включите. Като използвате iPerf, за да направите първоначален тест за честотна лента, можете бързо да определите дали получавате скоростите на мрежата, които трябва да получите. Например, ако използвате 10Gb мрежа между сървъра на приложения и сървъра на база данни и стартирате тест и получавате само 1Gb, тогава знаете, че нещо не е съвсем наред. Ако можете да документирате това откритие, тогава можете с увереност да помолите вашите мрежови инженери да разгледат проблем с честотната лента.
Как да започнете да използвате iPerf? Първо трябва да изтеглите инструмента от iPerf.fr. Тъй като работя върху Windows Server 2012, изтеглих двоичните файлове на Windows на моята машина. След като изтеглите и разархивирате пакета, ще трябва да стартирате програмата от команден ред. Изтеглих iPerf 3.0.11, който излиза от почти година. Не забравяйте да прочетете документацията на тази помощна програма. Тъй като това е инструмент за команден ред, има десетки опции, които можете да използвате. В примера по-долу ще използвам само няколко от тях, но в зависимост от вашата ситуация може да се наложи да използвате други опции, като например определяне на порта или увеличаване на размера на пакета. Моля, имайте предвид, че командите за опции са чувствителни към малки и големи букви.
За да използвате iPerf, трябва да използвате поне два сървъра, за да тествате честотната лента. След като копирате двоичните файлове на двата сървъра, първо трябва да стартирате iPerf слушателя на един от сървърите. За да направя това, ще изпълня следната команда:
iperf3 -sТази команда изпълнява iPerf в сървърен режим и позволява само една връзка в даден момент.
На втория сървър ще трябва да стартирате iPerf, като използвате няколко клиентски опции. Първо ще посочим -c, за да посочим клиентски режим. Също така ще използваме -t, за да посочим времето за изпълнение на всеки тест и -P, за да посочим броя на едновременните връзки, които да се направят. Искаме да посочим множество връзки, за да можем да натоварим правилно мрежата. За този тест ще изпълня следната команда:
iperf3 -c (име на сървъра или IP адрес на първия сървър) -t 30 -P 10Командата по-горе ще започне 30 секунден тест за предаване с 10 едновременни връзки.
Проведох този тест на две виртуални машини на моя Dell M6800, така че нямаше физическа мрежа, през която тези VM да преминат.
От сървър 2, свързващ се със сървър 1, получих 7,57 GB, прехвърлени с честотна лента от 2,17 Gbits/sec. Не е лошо за няколко виртуални машини на лаптоп.
Мрежова статистика / iPerf изход :Сървър 2 се свързва със сървър 1
От сървър 1, свързващ се със сървър 2, получих 6,98 GB, прехвърлени с честотна лента от 2,00 Gbits/sec. Както можете да видите, има лека разлика в числата, но все пак сравнително близо. Ако тези числа бяха драстично различни, тогава щеше да се наложи да разследвам причината.
Мрежова статистика / iPerf изход :Сървър 1 се свързва със сървър 2
Важно е да изпълните тези тестове, преди да влезете в производството и да създадете навик редовно да повтаряте тези тестове на вашите производствени сървъри. Трябва да знаете какво е нормално, ако не го наблюдавате, тогава не можете да го измерите. Ако знаете, че се извършват актуализации на фърмуера на вашите сървъри, виртуалния хост или някое основно мрежово оборудване, iPerf тест преди и след промените може бързо да ви предупреди, за да идентифицирате всякакви отрицателни странични ефекти.
Също така е важно да се извърши този тест срещу всички сървъри, които се свързват директно със сървъра на базата данни и всички сървъри, с които сървърът на базата данни взаимодейства директно, като например мрежови резервни устройства. IPerf работи както на Windows, така и на Linux, което улеснява тестването между двете операционни системи.
За DBA мрежата вече не трябва да бъде черна кутия, за която не знаете нищо. Използването на iPerf може да ви предупреди за всякакви проблеми с честотната лента в мрежата между вашия сървър на база данни и всеки друг сървър. Няма причина да разчитате само на PING и TRACERT за ограничено отстраняване на неизправности в мрежата. Изтеглете iPerf и започнете да документирате мрежовата си честотна лента.
