Configuration Manager często zadawane pytania dotyczące ustalania rozmiaru i wydajności witryny

Oddziel Configuration Manager skrzynki odbiorcze i SQL Server pliki na co najmniej dwóch różnych woluminach. Ta separacja umożliwia optymalizację rozmiarów alokacji klastra dla różnych rodzajów operacji we/wy, które wykonują.

W przypadku woluminu hostującego skrzynki odbiorcze serwera lokacji użyj systemu plików NTFS z jednostkami alokacji 4K lub 8K. System plików ReFS zapisuje 64k nawet dla małych plików. Configuration Manager ma wiele małych plików, więc system plików ReFS może spowodować niepotrzebne obciążenie dysku.

W przypadku dysków zawierających SQL Server pliki bazy danych użyj formatowania NTFS lub ReFS z jednostkami alokacji 64K.

Nowoczesne tablice dysków półprzewodnikowych (SSD) i azure Premium Storage mogą zapewniać dużą liczbę operacji we/wy na sekundę na jednym woluminie z kilkoma dyskami. Zwykle dodaje się więcej dysków do tablicy, aby uzyskać dodatkowy magazyn, a nie dodatkową przepływność. Jeśli używasz dysków fizycznych opartych na wrzecionach, może być potrzebnych więcej operacji we/wy na sekundę, niż można wygenerować na jednym woluminie. Należy przydzielić 60% łącznej zalecanej liczby operacji we/wy na sekundę i miejsca na dysku dla pliku mdf , 20% dla pliku ldf i 20% dla plików dziennika i plików tymczasowych danych. Pliki .ldf i temp mogą znajdować się na jednym woluminie z 40% (20% + 20%) przydzielonych operacji we/wy na sekundę.

SQL Server wersje starsze niż SQL Server 2016 r. utworzone domyślnie tylko jeden plik danych tymczasowych. Należy utworzyć więcej, aby uniknąć blokad SQL Server i oczekiwania na dostęp do pojedynczego pliku. Opinie społeczności różnią się w zależności od najlepszej liczby plików danych tymczasowych do utworzenia, od czterech do ośmiu. Testowanie pokazuje niewielką różnicę między czterema a ośmioma, dzięki czemu można utworzyć cztery pliki danych tymczasowych o jednakowych rozmiarach . Pliki danych bazy danych tempdb powinny mieć do 20–25% rozmiaru pełnej bazy danych.

W przypadku konfigurowania ustaw pamięć kontrolera RAID na 70% alokacji dla operacji zapisu i 30% dla operacji odczytu. Ogólnie rzecz biorąc, użyj konfiguracji macierzy RAID 10 dla bazy danych lokacji. Raid 1 jest również akceptowalny w przypadku małych lokacji z niskimi wymaganiami we/wy lub jeśli używasz szybkich dysków SSD. W przypadku większych macierzy dysków skonfiguruj dyski zapasowe w celu automatycznego zastępowania dysków, które kończą się niepowodzeniem.

Przykład: Maszyna fizyczna z dyskami fizycznymi

Wytyczne dotyczące ustalania rozmiaru dla kolokowanego serwera lokacji i SQL Server z 100 000 klientów to 1200 operacji we/wy na sekundę dla skrzynek odbiorczych serwera lokacji i 5000 operacji we/wy na sekundę dla plików SQL Server.

Wynikowe konfiguracja dysku może wyglądać następująco:

1. Nie obejmuje zalecanych dysków zapasowych.
2. Ta wartość pochodzi z przykładowych konfiguracji dysków.

Funkcja Hyper-V zapewnia podobną wydajność do serwera fizycznego, jeśli zasoby sprzętowe (rdzenie procesora CPU i magazyn przekazywania) są w 100% dedykowane maszynie wirtualnej. Użycie plików dysków vhd lub vhdx o stałym rozmiarze powoduje minimalny wpływ wydajności operacji we/wy na 1–5%. Dynamiczne rozszerzanie plików dysków vhd lub vhdx powoduje do 25% wpływu obciążenia Configuration Manager na wydajność operacji we/wy. Jeśli potrzebujesz dynamicznie rozszerzających się dysków, zrekompensuj, dodając do tablicy dodatkową wydajność operacji we/wy na sekundę o 25%.

Podczas uruchamiania serwera lokacji Configuration Manager lub SQL Server wewnątrz maszyny wirtualnej wyizoluj dyski systemu operacyjnego hosta funkcji Hyper-V od systemu operacyjnego maszyny wirtualnej i dysków danych.

Aby uzyskać więcej informacji na temat optymalizacji maszyn wirtualnych, zobacz Dostrajanie wydajności serwerów funkcji Hyper-V.

Przykład: serwer lokacji oparty na maszynie wirtualnej funkcji Hyper-V

Wytyczne dotyczące ustalania rozmiaru dla kolokowanego serwera lokacji i SQL Server z 150 000 klientów to 1800 operacji we/wy na sekundę dla skrzynek odbiorczych serwera lokacji i 7400 operacji we/wy na sekundę dla plików SQL Server.

Wynikowe konfiguracja dysku może wyglądać następująco:

1. Nie obejmuje zalecanych dysków zapasowych.
2. Stały rozmiar, przekazywanie pliku vhdx dla dysku maszyny wirtualnej dedykowanego woluminowi bazowemu.
3. Ta wartość pochodzi z przykładowych konfiguracji dysków.

Zacznij od przeczytania często zadawanych pytań Configuration Manager na platformie Azure.

Maszyny wirtualne infrastruktury jako usługi (IaaS) platformy Azure korzystające z dysków opartych na Premium Storage mogą mieć dużą ilość operacji we/wy na sekundę. Na tych maszynach wirtualnych skonfiguruj dodatkowe dyski pod kątem przewidywanych potrzeb dotyczących miejsca na dysku, a nie dla dodatkowych operacji we/wy na sekundę.

Usługa Azure Storage jest z natury nadmiarowa i nie wymaga wielu dysków w celu zapewnienia dostępności. Dyski można rozbierać w menedżerze dysków lub Miejsca do magazynowania, aby zapewnić dodatkowe miejsce i wydajność.

Aby uzyskać więcej informacji i zaleceń dotyczących maksymalizacji wydajności Premium Storage i uruchamiania serwerów SQL na maszynach wirtualnych IaaS platformy Azure, zobacz:

• Optymalizowanie wydajności aplikacji

• Wskazówki dotyczące dysków

Przykład: serwer lokacji oparty na platformie Azure

Wytyczne dotyczące ustalania rozmiaru dla kolokowanego serwera lokacji i SQL Server z 50 000 klientów to osiem rdzeni, 32 GB i 1200 operacji we/wy na sekundę dla skrzynek odbiorczych serwera lokacji oraz 2800 operacji we/wy na sekundę dla plików SQL Server.

Wynikową maszyną platformy Azure może być DS13v2 (osiem rdzeni, 56 GB) z następującą konfiguracją dysku:

1. Ta wartość pochodzi z przykładowych konfiguracji dysków.
2. Wskazówki dotyczące platformy Azure umożliwiają umieszczenie bazy danych TempDB na lokalnym dysku D: opartym na dyskach SSD, ponieważ nie przekroczy on dostępnego miejsca i umożliwia dodatkową dystrybucję operacji we/wy dysku.

Przykład: serwer lokacji oparty na platformie Azure (w celu natychmiastowego zwiększenia wydajności)

Przepływność dysku platformy Azure jest ograniczona przez rozmiar maszyny wirtualnej. Konfiguracja w poprzednim przykładzie platformy Azure może ograniczyć przyszłe rozszerzanie lub dodatkową wydajność. Jeśli dodasz dodatkowe dyski podczas początkowego wdrażania maszyny wirtualnej platformy Azure, możesz zwiększyć rozmiar maszyny wirtualnej platformy Azure w celu zwiększenia mocy obliczeniowej w przyszłości przy minimalnych inwestycjach z góry. Znacznie łatwiej jest zaplanować z wyprzedzeniem zwiększenie wydajności lokacji w miarę zmian wymagań, zamiast później wykonywać bardziej skomplikowaną migrację.

Zmień dyski w poprzednim przykładzie platformy Azure, aby zobaczyć, jak zmienia się liczba operacji we/wy na sekundę.

DS13v2

1. Dyski są rozkładane przy użyciu Miejsca do magazynowania.
2. Ta wartość pochodzi z przykładowych konfiguracji dysków. Rozmiar maszyny wirtualnej ogranicza wydajność.
3. Wskazówki dotyczące platformy Azure umożliwiają umieszczenie bazy danych TempDB na lokalnym dysku D: opartym na dyskach SSD, ponieważ nie przekroczy on dostępnego miejsca i umożliwia dodatkową dystrybucję operacji we/wy dysku.

Jeśli w przyszłości potrzebujesz większej wydajności, możesz zwiększyć rozmiar maszyny wirtualnej do serwera DS14v2, co podwoi użycie procesora CPU i pamięci. Dodatkowa przepustowość dysku dozwolona przez ten rozmiar maszyny wirtualnej również natychmiast zwiększy liczbę operacji we/wy na sekundę dostępnego dysku na wcześniej skonfigurowanych dyskach.

DS14v2

1. Dyski są rozkładane przy użyciu Miejsca do magazynowania.
2. Ta wartość pochodzi z przykładowych konfiguracji dysków. Rozmiar maszyny wirtualnej ogranicza wydajność.
3. Wskazówki dotyczące platformy Azure umożliwiają umieszczenie bazy danych TempDB na lokalnym dysku D: opartym na dyskach SSD, ponieważ nie przekroczy on dostępnego miejsca i umożliwia dodatkową dystrybucję operacji we/wy dysku.

Oba mogą działać odpowiednio, zakładając, że pojedynczy serwer ma odpowiedni rozmiar lub łączność sieciowa jest wystarczająca między dwoma serwerami.

Zdalne SQL Server wymagają z góry i kosztów operacyjnych dodatkowego serwera, ale są typowe dla większości klientów na dużą skalę. Zalety tej konfiguracji obejmują:

• Zwiększone opcje dostępności lokacji, takie jak SQL Server Zawsze włączone
• Możliwość uruchamiania intensywnych raportów z mniej podsłuchaną funkcją przetwarzania w lokacji
• Prostsze odzyskiwanie po awarii w niektórych sytuacjach
• Łatwiejsze zarządzanie zabezpieczeniami
• Separacja ról dla zarządzania SQL Server, na przykład z oddzielnym zespołem dba

Kolokowana SQL Server wymaga jednego serwera i jest typowa dla większości klientów na małą skalę. Zalety tej konfiguracji obejmują:

• Niższe koszty maszyn, licencji i konserwacji
• Mniejsza liczba punktów awarii w lokacji
• Lepsza kontrola czasu przestoju planowania

Domyślnie SQL Server używa całej dostępnej pamięci na serwerze, co może spowodować zablokowanie systemu operacyjnego i innych procesów na maszynie. Aby uniknąć potencjalnych problemów z wydajnością, ważne jest, aby jawnie przydzielić pamięć do SQL Server. Na serwerach lokacji kolokowanych z SQL Server upewnij się, że system operacyjny ma wystarczającą ilość pamięci RAM do buforowania plików i innych operacji. Upewnij się, że jest jeszcze wystarczająca ilość pamięci RAM dla programu SMSExec i innych procesów Configuration Manager. Podczas uruchamiania SQL Server na serwerze zdalnym można przydzielić większość pamięci do programu SQL, ale nie wszystkie. Zapoznaj się z wytycznymi dotyczącymi ustalania rozmiaru , aby uzyskać wstępne wskazówki.

SQL Server alokację pamięci należy zaokrąglić do całego GB. Ponadto w miarę zwiększania pamięci RAM do dużych ilości można pozwolić SQL Server mieć wyższy procent. Na przykład, gdy jest dostępna co najmniej 256 GB pamięci RAM, można skonfigurować SQL Server do 95%, ponieważ nadal zachowuje to dużo pamięci dla systemu operacyjnego. Monitorowanie pliku strony to dobry sposób na zapewnienie wystarczającej ilości pamięci dla systemu operacyjnego i wszelkich procesów Configuration Manager.

Problemy z rywalizacją o pamięć mogą wystąpić, jeśli na SQL Server jest więcej niż 16 rdzeni fizycznych i za mało pamięci RAM. Obciążenie Configuration Manager działa lepiej, gdy co najmniej 3–4 GB pamięci RAM na rdzeń jest dostępne dla języka SQL. Podczas dodawania rdzeni do SQL Server należy zwiększyć ilość pamięci RAM w proporcjonalnych ilościach.

Ogólnie rzecz biorąc, grupy dostępności mają znikomy wpływ na wydajność systemu, gdy jest dostępna wystarczająca ilość sieci między serwerami repliki. W zajętym środowisku grupy dostępności można szybko tworzyć pliki ldf dziennika bazy danych. Jednak miejsce na pliki dziennika jest automatycznie zwalniane po pomyślnym utworzeniu kopii zapasowej bazy danych. Dodaj zadanie SQL Server dla bazy danych Configuration Manager, aby wykonać kopię zapasową, na przykład co 24 godziny, i kopię zapasową ldf co sześć godzin. Aby uzyskać więcej informacji na temat grup dostępności i Configuration Manager, w tym więcej informacji na temat strategii tworzenia kopii zapasowych SQL Server, zobacz Przygotowywanie do korzystania z zawsze włączonej grupy dostępności SQL Server.

SQL Server kompresja nie jest zalecana dla bazy danych Configuration Manager. Chociaż nie ma żadnych problemów funkcjonalnych z włączaniem kompresji w bazie danych Configuration Manager, wyniki testów nie wykazują dużych oszczędności rozmiaru w porównaniu z potencjalnym, sporym wpływem na wydajność systemu.

Wszystkie wpisy tajne w bazie danych Configuration Manager są już bezpiecznie przechowywane, ale dodanie szyfrowania SQL Server może dodać kolejną warstwę zabezpieczeń. Nie ma żadnych problemów funkcjonalnych z włączaniem szyfrowania w bazie danych, ale może wystąpić obniżenie wydajności nawet o 25%. Dlatego szyfruj z ostrożnością, szczególnie w środowiskach o dużej skali. Pamiętaj również, aby zaktualizować plany tworzenia kopii zapasowych i odzyskiwania, aby upewnić się, że można pomyślnie odzyskać zaszyfrowane dane.

Aby uzyskać informacje o obsługiwanych wersjach programu SQL, zobacz Obsługa wersji SQL Server. Z punktu widzenia wydajności wszystkie obsługiwane wersje SQL Server spełniają wymagane kryteria wydajności. Jednak SQL Server 2016 r. lub nowsze zwykle przewyższają SQL Server 2014 r. w niektórych aspektach obciążenia Configuration Manager. Ponadto uruchomienie SQL Server 2014 r. na poziomie zgodności SQL Server 2012 r. (110) ogólnie zwiększa wydajność. W czasie instalacji Configuration Manager bazy danych uruchomione w SQL Server 2014 r. są ustawione na poziom zgodności 110. SQL Server 2016 r. lub nowszy jest ustawiony na domyślny poziom zgodności tej wersji SQL Server, taki jak 130 dla SQL Server 2016 r. Uaktualnianie SQL Server nie powoduje zaktualizowania poziomów zgodności do momentu zainstalowania następnej głównej Configuration Manager bieżącej wersji gałęzi.

Jeśli w przypadku niektórych zapytań SQL w SQL Server 2016 r. lub nowszych wystąpią nietypowe przekroczenia limitu czasu lub spowolnienie, na przykład podczas korzystania z kontroli dostępu opartej na rolach w konsoli Administracja, spróbuj zmienić poziom zgodności SQL Server w bazie danych Configuration Manager na 110. Działanie na poziomie zgodności SQL Server 110 w SQL Server 2014 r. i nowszych wersjach SQL Server jest w pełni obsługiwane. Aby uzyskać więcej informacji, zobacz Limit czasu zapytań SQL lub spowolnienie konsoli dla niektórych Configuration Manager zapytań bazy danych.

Od stycznia 2018 r. należy unikać następujących wersji SQL Server z powodu różnych znanych problemów związanych z wydajnością lub innych potencjalnych problemów:

• SQL Server 2012 SP3 CU1 do CU5
• SQL Server 2014 SP1 CU6 do SP2 CU2
• SQL Server 2016 RTM do CU3, SP1 CU3 do CU5

Tak, aktualizuj indeksy tak często, jak raz w tygodniu i statystyki tak często, jak raz dziennie, aby zwiększyć wydajność SQL Server. Skrypty innych firm i dodatkowe informacje dostępne w społecznościach Configuration Manager i SQL Server mogą pomóc w optymalizacji tych zadań.

W dużych lokacjach niektóre tabele SQL Server, takie jak CI_CurrentComplianceStatusDetails, HinvChangeLog, mogą być duże w zależności od wzorców użycia. Może być konieczne zmniejszenie lub zmiana podejścia do konserwacji dla nich jeden po drugim.

SQL Server Express nie ma żadnego znaczącego wpływu na wydajność lokacji dodatkowych i jest odpowiednia dla większości klientów. Jest to również łatwe do wdrożenia i zarządzania, i jest zalecana konfiguracja dla prawie wszystkich klientów w dowolnym rozmiarze.

Istnieje jedna sytuacja, w której może być wymagana pełna instalacja SQL Server. Jeśli w środowisku istnieje duża liczba punktów dystrybucji, pakietów lub źródeł, można przekroczyć limit rozmiaru 10 GB SQL Server Express. Jeśli liczba pakietów razy większa niż liczba punktów dystrybucji przekracza 4 000 000, na przykład 2000 DPs z 2000 elementami zawartości, rozważ użycie pełnych SQL Server w lokacjach dodatkowych.

Pozostawienie ustawienia na poziomie 0 (użyj wszystkich dostępnych procesorów) jest optymalne dla ogólnej wydajności przetwarzania w większości przypadków.

Wielu administratorów Configuration Manager postępuj zgodnie ze wskazówkami zawartymi w temacie Zalecenia i wytyczne dotyczące opcji konfiguracji "maksymalny stopień równoległości" w SQL Server. W przypadku większości nowoczesnych dużych urządzeń te wskazówki prowadzą do sugerowanego maksymalnego ustawienia ośmiu. Jeśli jednak uruchomisz wiele mniejszych zapytań w porównaniu z liczbą procesorów, może to pomóc w ustawieniu większej liczby. Ograniczenie się do ośmiu niekoniecznie jest najlepszym ustawieniem w większych lokacjach, gdy dostępnych jest więcej rdzeni.

W programie SQL Server z więcej niż ośmioma rdzeniami zacznij od ustawienia 0 i wprowadź zmiany tylko wtedy, gdy wystąpią problemy z wydajnością lub nadmierne blokowanie. Jeśli musisz zmienić funkcję MaxDOP, ponieważ występują problemy z wydajnością na poziomie 0, zacznij od nowej wartości co najmniej większej lub równej minimalnej zalecanej liczbie rdzeni dla SQL Server rozmiaru tej lokacji. Obniżenie tej wartości prawie zawsze ma negatywny wpływ na wydajność. Na przykład zdalny SQL Server dla 100 000 lokacji klienckiej wymaga co najmniej 12 rdzeni. Jeśli SQL Server ma 16 rdzeni, rozpocznij testowanie ustawienia MaxDOP z wartością 12.

Należy zachować ostrożność podczas wyłączania ochrony antywirusowej w dowolnym systemie. W środowiskach o dużej głośności i zabezpieczeniach zalecamy wyłączenie aktywnego monitorowania w celu uzyskania optymalnej wydajności.

Aby uzyskać więcej informacji na temat zalecanych wykluczeń antywirusowych, zobacz Zalecane wykluczenia antywirusowe dla Configuration Manager 2012 r. i serwerów lokacji bieżącej gałęzi, systemów lokacji i klientów.

Zmiana kilku kluczowych ustawień usług IIS, takich jak długość kolejki puli WsusPool i limit pamięci prywatnej WsusPool, może zwiększyć wydajność usług WSUS, nawet w przypadku mniejszych instalacji. Aby uzyskać więcej informacji, zobacz Zalecany sprzęt.

Upewnij się również, że masz zainstalowane najnowsze aktualizacje systemu operacyjnego z uruchomionym programem WSUS:

• Windows Server 2012: wszelkie aktualizacje zbiorcze inne niż "Tylko zabezpieczenia" wydane w październiku 2017 r. lub nowszym. (KB4041690)
• Windows Server 2012 R2: wszelkie aktualizacje zbiorcze inne niż "Tylko zabezpieczenia" wydane w sierpniu 2017 r. lub nowszym. (KB4039871)
• Windows Server 2016: wszelkie aktualizacje zbiorcze inne niż "Tylko zabezpieczenia" wydane w sierpniu 2017 r. lub nowszym. (KB4039396)

Zobacz Kompletny przewodnik Microsoft konserwacji usług WSUS i Configuration Manager SUP.

Tradycyjne monitorowanie wydajności serwera działa efektywnie w przypadku ogólnych Configuration Manager. Można również korzystać z różnych pakietów administracyjnych programu System Center Operations Manager dla Configuration Manager, SQL Server i Windows Server w celu monitorowania podstawowej kondycji serwerów. Możesz również bezpośrednio monitorować liczniki systemu Windows monitor wydajności (PerfMon), które udostępnia Configuration Manager. Monitoruj listy prac w różnych skrzynkach odbiorczych pod kątem wczesnych oznak ostrzegawczych potencjalnych problemów z wydajnością witryny lub list prac.

Zobacz też

• Wytyczne dotyczące ustalania rozmiaru i wydajności witryny
• Configuration Manager na platformie Azure — często zadawane pytania