Problemy z wydajnością programu SQL Server 2012 Enterprise Edition w ramach licencji CAL

W SQL Server 2012 wprowadzono wiele zmian licencyjnych; najbardziej znaczącym było przejście od licencjonowania opartego na gniazdach do licencjonowania opartego na rdzeniach w wersji Enterprise Edition. Jednym z wyzwań, przed jakimi stanął Microsoft w związku z tą zmianą, było zapewnienie ścieżki migracji klientom, którzy wcześniej korzystali z licencjonowania opartego na serwerze + CAL dla wersji Enterprise Edition przed wersją SQL Server 2012. Klienci objęci pakietem Software Assurance mogą uaktualnić do wersji SQL Server 2012 Enterprise Edition i nadal korzystać z serwera Licencjonowanie +CAL (znane również jako „grandfathering”), ale z ograniczeniem do 20 procesorów logicznych, zgodnie z dokumentacją w Przewodniku licencjonowania programu SQL Server 2012. Ta licencja obejmuje również maszyny wirtualne z limitem 4 maszyn wirtualnych objętych licencją Enterprise Server+CAL, ale nadal z tym samym ograniczeniem do 20 procesorów logicznych, co udokumentowano w przewodniku SQL Server 2012 Virtualization Licensing Guide.

Wiele osób zostało zaskoczonych ograniczeniem 20 procesorów logicznych, mimo że jest to udokumentowane w przewodnikach licencjonowania.

Podczas uruchamiania instancji w pliku ERRORLOG wprowadzany jest wpis, określający liczbę procesorów logicznych i egzekwowanie ograniczenia 20 procesorów:

Przy domyślnej konfiguracji, którą program SQL Server stosuje w ramach ograniczenia liczby procesorów logicznych do 20 procesorów przy użyciu serwera+CAL, pierwszych 20 programów planujących jest WIDOCZNYCH ONLINE, a wszelkie pozostałe programy planujące są WIDOCZNE W POŁĄCZENIU. W rezultacie mogą wystąpić problemy z wydajnością instancji z powodu braku równowagi harmonogramu węzłów NUMA. Aby to zademonstrować, stworzyłem maszynę wirtualną na naszym serwerze testowym Dell R720, który ma dwa gniazda i zainstalowane procesory Intel Xeon E5-2670, każdy z 8 rdzeniami i włączoną funkcją Hyperthreading, co daje w sumie 32 procesory logiczne dostępne w systemie Windows Server 2012 Datacenter Edition. Maszyna wirtualna została skonfigurowana tak, aby miała 32 wirtualne procesory z 16 wirtualnymi procesorami przydzielonymi w dwóch węzłach vNUMA.

Rysunek 1 – ustawienia vNUMA

W programie SQL Server w modelu licencjonowania Enterprise Server+CAL skutkuje to konfiguracją harmonogramu podobną do następującej:

SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulers;

Rysunek 2 – Przypisanie harmonogramu w ramach Enterprise Server+CAL

Jak widać, instancja używa wszystkich 16 procesorów logicznych w pierwszym węźle NUMA i tylko czterech procesorów logicznych w drugim węźle NUMA. Powoduje to znaczną nierównowagę harmonogramów między dwoma węzłami NUMA, co może prowadzić do znacznych problemów z wydajnością pod obciążeniem. Aby to zademonstrować, uruchomiłem 300 połączeń, uruchamiając obciążenie AdventureWorks Books Online względem instancji, a następnie przechwyciłem informacje o harmonogramie dla harmonogramów VISIBLE ONLINE w instancji, używając następującego zapytania:

SELECT parent_node_id, scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE';

Przykładowe wyjście tego zapytania pod obciążeniem pokazano na rysunku 3 poniżej.

Rysunek 3 — Harmonogramy są obciążone przy użyciu Enterprise Server+CAL

Ten objaw można również zobaczyć wizualnie w narzędziach monitorujących, takich jak SQL Sentry Performance Advisor:

Ilustracja 4 – brak równowagi NUMA, jak pokazano w SQL Sentry Performance Advisor

Informacje te wskazują na znaczną nierównowagę, w wyniku której wpłynie to na wydajność. Jest to wyraźnie widoczne w licznikach zadań, które można uruchomić dla czterech programów planujących w drugim węźle NUMA, które są trzy do czterech razy większe niż te dla programów planujących w pierwszym węźle NUMA. Więc na czym dokładnie polega problem i dlaczego tak się dzieje?

Na pierwszy rzut oka możesz pomyśleć, że jest to błąd w SQL Server, ale tak nie jest. Jest to coś, co dzieje się zgodnie z projektem, chociaż wątpię, aby ten scenariusz był oczekiwany, gdy pierwotnie zaimplementowano ograniczenie procesorów logicznych 20. W systemach opartych na NUMA nowe połączenia są przypisywane do węzłów NUMA w sposób okrężny, a następnie wewnątrz węzła NUMA połączenie jest przypisywane do harmonogramu na podstawie obciążenia. Jeśli zmienimy sposób, w jaki patrzymy na te dane i agregujemy dane na podstawie parent_node_id, zobaczymy, że zadania są faktycznie równoważone między węzłami NUMA. W tym celu użyjemy następującego zapytania, którego wynik pokazano na rysunku 5.

SELECT parent_node_id, SUM(current_tasks_count) AS current_tasks_count, SUM(runnable_tasks_count) AS runnable_tasks_count, SUM(active_workers_count) AS active_workers_count, AVG(load_factor) AS avg_load_factorFROM sys.dmers_BYHER_UPNOVIS'[GROMA_UPIS. /pre> 

 
Ilustracja 5 – Bilans round-robin węzłów NUMA 
 

 To zachowanie jest udokumentowane w Books Online dla programu SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Wiedząc, co wiem o SQLOS, SQL Server i sprzęcie, ma to sens. Przed ograniczeniem do 20 procesorów logicznych w programie SQL Server 2012 Enterprise Edition z licencją Server+CAL rzadko zdarzało się, aby program SQL Server miał nierównowagę harmonogramu między węzłami NUMA na serwerze produkcyjnym. Jednym z problemów w tym konkretnym przypadku jest sposób, w jaki wirtualna NUMA została przekazana do maszyny wirtualnej. Przeprowadzenie dokładnie tej samej instalacji na fizycznym sprzęcie umożliwia wszystkim programistom bycie WIDOCZNYM W SIECI, ponieważ dodatkowe procesory logiczne prezentowane przez hiperwątki są rozróżniane przez SQL i są bezpłatne.
 

 Innymi słowy, limit 20 procesorów logicznych w rzeczywistości skutkuje 40 harmonogramami ONLINE, jeśli (a) nie jest to maszyna wirtualna, (b) procesory to Intel i (c) hiperwątkowość jest włączona. 
 

 Widzimy więc następujący komunikat w dzienniku błędów:
 Data 14.11.2012 22.36:18
Dziennik    Serwer SQL (obecnie – 14.11.2012 22.36:00)
Serwer źródłowy
Wiadomość
SQL Serwer wykrył 2 gniazda z 8 rdzeniami na gniazdo i 16 procesorami logicznymi na gniazdo, łącznie 32 procesory logiczne; przy użyciu 32 procesorów logicznych w oparciu o licencje SQL Server. To jest wiadomość informacyjna; nie jest wymagane żadne działanie użytkownika. 

 I to samo zapytanie co powyżej powoduje, że wszystkie 32 procesory są WIDOCZNE W INTERNECIE:
 
SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE';
 

 
Rysunek 6 – Ta sama konfiguracja na sprzęcie fizycznym 
 

 W tym przypadku, ponieważ są tylko 32 procesory logiczne, limit 20 (no, 40) rdzeni nie ma na nas żadnego wpływu, a praca jest rozłożona równomiernie na wszystkie rdzenie.
 

 W scenariuszach, w których ograniczenie 20 procesorów wpływa na równowagę harmonogramów NUMA, można ręcznie zmienić konfigurację serwera, aby zrównoważyć liczbę harmonogramów WIDOCZNYCH ONLINE w każdym z węzłów NUMA za pomocą ALTER SERVER CONFIGURATION . W podanym przykładzie maszyny wirtualnej następujące polecenie skonfiguruje pierwszych 10 procesorów logicznych w każdym węźle NUMA na VISIBLE ONLINE.
 
ZMIEŃ KONFIGURACJA SERWERA USTAW POWIĄZANIE PROCESÓW CPU =0 do 9, 16 do 25;
 

 Dzięki tej nowej konfiguracji, przy tym samym obciążeniu 300 sesji i obciążeniu AdventureWorks Books Online, widzimy, że nierównowaga obciążenia już nie występuje.
 

 
Ilustracja 7 – Saldo przywrócone z ręczną konfiguracją 
 

 I znowu, używając SQL Sentry Performance Advisor, możemy zobaczyć, jak obciążenie procesora jest rozłożone bardziej równomiernie na oba węzły NUMA:
 

 
Rysunek 8 – Saldo NUMA pokazane w SQL Sentry Performance Advisor 
 

 Ten problem nie ogranicza się wyłącznie do maszyn wirtualnych i sposobu, w jaki wirtualne procesory są prezentowane systemowi operacyjnemu. Możliwe jest również napotkanie tego problemu na fizycznym sprzęcie. Na przykład starszy Dell R910 z czterema gniazdami i ośmioma rdzeniami na gniazdo lub nawet serwer oparty na AMD Opteron 6200 Interlagos z dwoma gniazdami i 16 rdzeniami na gniazdo, który przedstawia się jako cztery węzły NUMA po osiem rdzeni każdy. W każdej z tych konfiguracji nierównowaga procesów może również spowodować całkowite przełączenie jednego z węzłów NUMA w tryb offline. W konsekwencji inne efekty uboczne, takie jak dystrybucja pamięci z tego węzła przez węzły online, prowadzące do problemów z dostępem do pamięci obcej, mogą również obniżyć wydajność.
 
Podsumowanie
 

 Domyślna konfiguracja programu SQL Server 2012 z licencją Enterprise Edition dla serwera+CAL nie jest idealna we wszystkich konfiguracjach NUMA, które mogą istnieć dla programu SQL Server. Zawsze, gdy używane jest licencjonowanie Enterprise Server+CAL, należy sprawdzić konfigurację NUMA i stany harmonogramu dla każdego węzła NUMA, aby upewnić się, że SQL Server jest skonfigurowany pod kątem optymalnej wydajności. Ten problem nie występuje w przypadku licencjonowania opartego na rdzeniach, ponieważ wszystkie programy planujące są licencjonowane i WIDOCZNE W INTERNECIE.