sp_configure – część 3
Ruszamy z kontynuacją cyklu – tym razem opiszę 14 opcji, które są opcjami zaawansowanymi a jednocześnie ich uruchomienie wymaga restart usługi.
SELECT name, value, minimum, maximum
FROM sys.configurations
WHERE is_dynamic = 0 AND is_advanced = 1
ORDER BY name
Dla przypomnienia jeszcze poprzednie części:
http://itsouldiers.com/blog/2009/06/sp_configure-czesc-1/
http://itsouldiers.com/blog/2009/06/sp_configure-czesc-2/
affinity I/O mask
dostępne wartości: -2GB -> 2GB, domyślnie – 0
zastosowanie: część zestawu instrukcji affinity mask oraz affinity64 mask; pozwala przydzielić wątkom SQL Server obsługującym podsystem I/O konkretne procesory. Opcja ta wyrażana jest 32bitową liczbą, ustawienie jakiegokolwiek bitu tej liczby na 1 powoduje pracę wątków odpowiedzialnych za obsługę I/O na tych procesorach. Uwaga! nie powinna zajść sytuacja że zarówno opcja affinity mask jak i affinity I/O mask ma ustawione te same bity maski na 1 – czyli nie może być konfliktu w dostępie do zasobów, kiedy spróbujemy taki konflikt skonfigurować otrzymamy komunikat:
Msg 5834, Level 16, State 1, Line 1
The affinity mask specified conflicts with the IO affinity mask specified. Use the override option to force this configuration.
Jednakże nawet przy konfliktowym ustawieniu tych opcji SQL Server uruchamia się poprawnie (co nie znaczy że pracuje później poprawnie). Po uruchomieniu I/O affinity, w errorlogu SQL Server w sekwencji startowej możemy zobaczyć komunikat:
I/O affinity turned on, processor mask 0×00000001. Disk I/Os will execute on CPUs per affinity I/O mask/affinity64 mask config option.
AWE enabled
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: opcja umożliwia w 32 bitowych buildach SQL Server zaalokować więcej niż 2GB pamięci (3GB z przełącznikiem /3GB); niestety nowo zaalokowana pamięć dostępna jest tylko dla buforów danych; rozmiar alokowanej pamięci należy ograniczać przy użyciu opcji min/max server memory; aby ją uruchomić należy kontu na jakim pracuje SQL Server dać uprawnienia do blokowania stron w pamięci; AWE umożliwia do zaalokowania do 64GB pamięci (w zależności od edycji systemu operacyjnego).
Skąd się wzięło AWE ? Firma Intel wraz z wejściem Intel Pentium Pro zaimplementowała w nim mechanizm Physical Address Extension (PAE) 36bitowej szyny adresowej – umożliwiał on ominięcie limitów 32bitowych architektur x86; niestety wymagało to wsparcia systemu operacyjnego – pierwszym systemem, wspierającym tę technologię był Windows NT 4.o Enterprise. Address Windowing Extensions (AWE) jest zestawem instrukcji API Windows umożliwiających korzystanie z mechanizmu PAE.
Przełączniki boot.ini:
- /3GB – zmienia pierwotny podział pamięci operacyjnej z 2/2GB na 1/3GB – dzięki temu maksymalnie 3GB pamięci wirtualnej jest dostępne dla pojedynczego procesu
- /userva=xxxx – jest uzupełnieniem przełącznika /3GB, dzięki userva można dokładniej określać ile pamięci będzie dostępne dla użytkowników a ile pozostanie dla jądra systemu operacyjnego. Np. przełącznik: /userva=2500 spowoduje przydzielenie 2500MB dla aplikacji użytkowników i 1596MB dla jądra systemu operacyjnego.
- /PAE – umożliwia korzystanie z PAE (dzięki temu Windows x86 zobaczy powyżej 4GB pamięci); na technecie można znaleźć informacje że PAE jest włączane automatycznie “if the server is using hot-add memory devices”
Jak używać ?
W serwerach od 4 do 16GB pamięci operacyjnej – należy korzystać zarówno z /3GB jak i z /PAE; jeśli serwer posiada powyżej 16GB pamięci należy korzystać tylko z /PAE (wówczas jądro systemu potrzebuje więcej przestrzeni do zbudowania map alokacji i nie można go ograniczać do 1GB).
Więcej informacji
AWE – http://msdn.microsoft.com/en-us/library/ms175581.aspx
PAE – http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx
userva – http://support.microsoft.com/kb/316739/
c2 audit mode
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: Uruchomienie śledzenia na poziomie c2 powoduje zapisanie do pliku trace zarówno pomyślnych jak i niepomyślnych prób dostępu do obiektów jak i wywołań poleceń; plik jest zachowywany w w folderze wskazanym przez domyślną ścieżkę dla danych; co 200MB SQL Server zamyka stary plik i otwiera nowy (podobna sytuacja ma miejsce przy restarcie usługi). Jak się łatwo domyśleć w przypadku obciążonych serwerów należy przemyśleć gdzie należy składować pliki trace oraz czy mamy wystarczająco mocy obliczeniowej – możliwy nawet kilku procentowy narzut na obciążenie procesora jak i czas wykonania. Śledzenie na poziomie C2 jest bardzo, bardzo (wszystkie eventy z grupy Security Audit, wraz ze wszystkimi kolumnami) dokładne i należy dokładnie rozważyć kiedy go użyć. Być czasem lepiej stworzyć swój własny trace, będący bardziej selektywny i jednocześnie mniej obciążający serwer.
Common Criteria compliance enabled
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: standard bezpieczeństwa, który zastąpił certyfikacje C2; aktualnie SQL Server posiada następujące poświadczenia (na podstawie: https://www.microsoft.com/sql/commoncriteria/certifications.mspx)
SQL Server 2005 SP1 – EAL1 (32 bit Enterprise Edition)
SQL Server 2005 SP2 – EAL4+ oraz NSA DBMS Protection Profile V1.1 (32 bit Enterprise Edition)
SQL Server 2008 RTM – EAL1
Uruchomienie trybu zgodności z Common Criteria ma znaczący wpław na działanie SQL Server, poniżej kilka przykładów:
Residual Information Protection (RIP) – powoduje konieczność zapisania pamięci znanym ciągiem bitów zanim zostanie przydzielona innemu zasobowi
The ability to view login statistics – powoduje przechowywanie daty ostatniego pomyślnego i niepomyślnego logowania oraz liczby prób pomiędzy nimi; dane dostępne w widoku sys.dm_exec_sessions
That column GRANT should not override table DENY – powoduje “a table-level DENY takes precedence over a column-level GRANT; when the option is not enabled, a column-level GRANT takes precedence over a table-level DENY”
Aby system spełniał wymagania należy (w zależności od wersji) pobrać i uruchomić jeszcze skrypt budujący trace lub konfigurujący serwer.
Jak można się domyśleć po powyższych kryteriach Common Criteria nie zapewniają że produkt jest bezpieczny – a raczej stwierdzają że posiada pewne mechanizmy zabezpieczeń.
EKM provider enabled
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: Extensible Key Management umożliwia zastosowanie produktów firm trzecich jako modułów przechowujących klucze szyfrujące dane w SQL Server; dzięki temu klucze szyfrujące dane mogą być np. przechowywane na pendrive wpiętym w serwer baz danych – zamiast na samym serwerze.
fill factor (%)
dostępne wartości: 0 -> 100, domyślnie – 0
zastosowanie: po ustawieniu tej opcji na wartość inną niż 0 – wskazana wartość będzie określała procent zapełnienia stron (na poziomie liścia) w indeksach; zostawienie pewnej wolnej przestrzeni na stronie powoduje mniejszą fragmentację indeksu oraz mniejszą liczbę zdarzeń typu “split page”. W systemach o dużej zmienności danych fill factor powinien być ustawiony na niższy (mniejsze wypełnienie stron), natomiast w systemach takich jak hurtownie danych – często fillfactor ma wartość 100 (strony są zapełnianie w pełni). Fill factor powinien być dobierany do każdej bazy/tabeli po indywidualne analizie, ale przyjęło się stosowanie wartości 85 jako bezpiecznego punktu wyjścia dla dalszej optymalizacji.
lightweight pooling
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: kiedy na systemie bazodanowym obserwujemy wysoką liczbę przełączeń pomiędzy wątkami (ang. context switching) – co powoduje dodatkowe obciążenie procesów można spróbować przełączyć system w tryb lightweight pooling – czyli żeby zamiast wątków wykorzystywał włókna (fibre). Niestety w Books Online możemy przeczytać: “We do not recommend that you use fiber mode scheduling for routine operation. This is because it can decrease performance by inhibiting the regular benefits of context switching, and because some components of SQL Server that use Thread Local Storage (TLS) or thread-owned objects, such as mutexes (a type of Win32 kernel object), cannot function correctly in fiber mode.”
oraz: “Common language runtime (CLR) execution is not supported under lightweight pooling. Disable one of two options: “clr enabled” or “lightweight pooling”. Features that rely upon CLR and that do not work properly in fiber mode include the hierarchy data type, replication, and Policy-Based Management.”
co skutecznie powoduje że w nowoczesnych systemach korzystanie z tej opcji będzie jeszcze rzadsze niż do tej pory.
locks
dostępne wartości: 5000->2GB, domyślnie – 0
zastosowanie: umożliwia zarządzanie liczbą blokad obecnych w SQL Server a tym samym pozwala ograniczać zużycie przez nie pamięci; kiedy opcja ma wartość 0 – SQL Server uruchamiając się alokuje pamięć dla 2500 blokad, jeśli potrzeby rosną pula prosi o przydział kolejnej porcji pamięci; w takiej konfiguracji SQL Server nie alokuje więcej niż 60% pamięci dostępnej dla Database Engine; jeśli limit 60% zostanie osiągnięty lub nie ma więcej dostępnej pamięci generowane są błędy. Jeśli ktoś chciałby samemu ustawiać tę opcję musi pamiętać że każda blokada to jest 96bajtów pamięci – czyli.: 1k blokad -> 94kB, 100k -> 9,15MB, …
Jeśli liczba locków osiąga 40% pamięci przyznanej dla DB engine (przy konfiguracji dynamicznej) lub 40% wskazanej liczby blokad – następuję proces zwany lock escalation który ma na celu zmniejszenie liczby blokad dzięki zamianie wielu blokad o wysokiej szczegółowości na mniej blokad bardziej ogólnych.
status: obsolete
Dużo ciekawych informacji o procesie eskalacji blokad można znaleźć pod adresami:
http://technet.microsoft.com/en-us/library/ms184286.aspx
http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server-2008-Lock-escalation-changes.aspx
max worker threads
dostępne wartości: 128->32kB, domyślnie – 0
zastosowanie: SQL Server korzysta za natywnych wątków systemu operacyjnego; wewnątrz serwera bazy danych różne wątki mają przypisane różne role – np. są wątki odpowiedzialne za usuwanie tabel tymczasowych, za checkpoint czy lazy writer oraz za obsługę żądań użytkowników; kiedy opcja max worker threads jest ustawiona na 0 wówczas każde nowe zapytanie użytkownika tworzy nowy wątek (jeśli nie ma akurat wolnego) – w związku z czym w sytuacji dużego obciążenia może się zdarzyć że SQL Server będzie miał dodatkowy narzut na zarządzanie zbyt dużą liczbą wątków roboczych. W trybie automatycznym SQL Server tworzy wątki zgodnie z tabelą:
CPU / 32bit / 64bit
1-4 / 256 / 512
4-8 / 288 / 576
8-16 / 352 / 704
16-32 / 480 / 960
przy czym dla instalacji 32bitowych nie jest zalecane więcej niż 1024 wątki a 64bitowych 2048 wątków!
Określenie na sztywno liczby wątków roboczych może doprowadzić do sytuacji, w której wszystkie wątki będą zajęte a SQL Server nie będzie odpowiadał na nowe zapytania – gdyż nie będzie mógł przydzielić wątki do obsługi danego zapytania! Aby wybrnąć z tej sytuacji można:
- poczekać aż SQL Server zakończy obsługę zapytań ;-)
- podłączyć się DACiem i zmienić opcję max worker threads i zrestartować serwer … tyle że w momencie maksymalnego obciążenia może to nie być mile widziane …
- zrestartować usługę systemową
W związku z powyższym należy o opcji max worker threads pamiętać ale jej użycie powinno być starannie przemyślane!
open objects
dostępne wartości: 0->2GB, domyślnie – 0
zastosowanie: opcja w SQL Server 2000 służyła do określania maksymalnej liczby otwartych obiektów bazy danych
status: obsolete
priority boost
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: opcja służy do podniesienia priorytetu z jakim jest uruchamiana usługa SQL Server (kiedy opcja jest wyłączona jest to 7, po włączeniu jest to 13).
scan for startup procs
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: procedura sp_procoption umożliwia dodanie oznaczenia “autostart” procedurom; po takim oznaczeniu i po uruchomieniu opcji scan for startup procs SQL Server zaraz po załadowaniu bazy danych master zaczyna szukać procedur oznaczonych jako autostart, dla każdej takiej procedury przyznawany jest odrębny wątek, a procedura jest wykonywana z prawami sysadmina. Korzystanie z tej opcji jest jednym ze sposobów zakładania i utrzymywania “żywych” globalnych tabel tymczasowych.
set working set size
dostępne wartości: 0 – nie, 1 – tak, domyślnie – 0
zastosowanie: opcja w SQL Server 2000 pozwalała na blokowanie stron w pamięci (system operacyjny nie swapował pamięci zaalokowanej przez SQL Server) – opcja rządzi się takimi samymi prawami jak lock pages in memory – należy ustawić min/max server memory zanim uruchomimy ten feature
user connections
dostępne wartości: 0 ->32kB, domyślnie – 0
zastosowanie: opcja miała duże znaczenie w systemach o klasycznej architekturze klient-serwer – kiedy większość końcówek klienckich otwierała 1 lub więcej połączeń do serwera baz danych – Ponieważ zarządzanie dużą ilością wątków wprowadza pewien narzut (oraz z innych powodów) aktualnie w systemach wielo warstwowych często stosuje się mechanizm poolingu połączeń który powoduje że to samo połączenie jest wykorzystywane przez wiele różnych końcówek – niestety żeby to było możliwe musi zostać wprowadzona warstwa pośrednicząca w postaci np. serwera aplikacji czy serwera www.
Comments are closed.