Já rád dělám hodně Group Policy Objectů (GPO). Každý obsahuje jen maličko nastavení. Jmenují se přesně podle toho, co dělají. Viz. přiložený obrázek - v tomto pokusu jich bylo 63, z toho některé mají zapnuté Enforce. V mnoha z nich je jen jedna hodnota. Na několika z nich je dokonce WMI filter. V některých používám Group Policy Preferences. Prostě klasický mix všehochuti.
Ano, jsou to jenom testovací GPO. Normálně jich udělám tak čtyřikrát tolik :-) Navíc já nevypínám tu druhou část - většina těch objeků má nastavení v Computer Configuration, ale přitom má "zapnutou" i část User Configuration. Uživatelská část je ale prázdná. Ano, mohl bych ji vypnout, abych systému přímo naznačil, že se do uživatelské části nemá vůbec dívat. Ale pro pokus jsem to neudělal.
Už jsem několikrát slyšel, že to je tragicky špatně a jsem "prase". Nejsem. To je asi tak špatně, jako že mě se líbí černá auta a někomu se líbí červená.
Podívejme se, jaký to má dopad na různé výkony.
Velikost SYSVOL
Sysvol žere ve skutečných datech 168 kB. Na disku to ale spotřebovává 788 kB, protože je to hodně souborů a každý se musí zarovnat na celý cluster. Souborů a adresářů je to 699.
Zjevně je to malinký objem, ale hrozba číhá v počtu souborů a adresářů. Jejich stahování na stanice je velice závislé na RTT (round-trip-time) mezi klientem a DC. Takže strach o výkon je zde jistě oprávněný. Otázka je, jestli je opodstatněný.
Testování GPUPDATE
Předně si uveďme, jak to budu testovat. Pro DC i stanici jsem si nastavil jen jedno CPU, abych jednodušeji zachytil jejich spotřebu. Oba dva mají dosta RAM paměti na to, aby se jim tam všechno v pohodě vešlo. Síť má RTT sub-milisecond, takže blesk. To nevadí, změříme počet a přepočítáme to.
Podstatné je, že na stanici spouštím jenom gpupdate bez parametrů. Nepoužívám parametr /force. Parametr force je na řešení potíží a vyvolá kompletní novou reaplikaci všech objektů. To se ale za normálních podmínek neděje. Klienti si stahují každý GPO jen jednou. Pokud se jeho obsah nezměnil od poslední aplikace, už to znovu neaplikují.
Klienti poznávají novinky podle verze GPO v LDAP a v SYSVOL. To je info, které normálně vidíte v GPMC konzoli na záložce Details.
Takže pomocí gpupdate bez parametrů simuluji to, co dělají všechny počítače v síti každých cca 2 hodiny.
Klient je Windows 8, Windows 2008 R2 a Windows 2003 bez GP preferences klienta. Řadič domény DC byl Windows 2012 R2. Každé CPU jádro bylo Intel Core i5 750 2.67 GHz.
Spotřeba CPU na stanici a DC
Změřil jsem CPU na stanici. Vylétlo to na chviličku na 100%, což se dalo čekat, mám jenom jeden procesor. Celá akce trvala cca 5 sekund. Normálně to samozřejmě běží na pozadí a uživatel o tom vůbec neví. Tady máte obrázek, samozřejmě jsem to měřil vícekrát na všech třech klientských operačních systémech.
Na Windows 2003 bez preferencí to dalo ve špičce 50% CPU a trvalo to jenom 3 sekundy.
Na řadiči domény to vzalo ve špičce dokonce jenom 5% CPU. Je to moc?
Řekněme, že ta špička 5 % je po dobu 1 sekundy. Kolik bych musel mít stanic, aby to udělalo trvalých 5% jednoho CPU na DC? Každý klient si aktualizuje politiku každé dvě hodiny. Rozloží se to řekněme rovnoměrně.
Trvale by znamenalo 3600 gpupdate během hodiny. Za hodinu se aktualizuje polovina stanic. Takže cca 7200 stanic by vytížilo jedno jádro CPU jednoho DC na 5% trvale. Začíná mi to rvát žíly.
Síťové charakteristiky
Obrázek zachycuje projev na síti v průběhu gpupdate.
Maximální hodnota byla 122 kB/s, takže cca 1 Mbps. Průměrně bych to odhadl na 800 kbps. Tentokrát bez výraznější špičky, po celou dobu aplikace, oněch 5 sekund.
Jak to vypadá s celou zátěží síťovky jednoho DC? Trvalý stah 800 kbps by během hodiny udělalo 720 stanic, to je tedy 1440 stanic v síti při dvouhodinovém gpupdate. Abyste dali tomu jednomu DCčku trvale alespoň 10 Mbps, museli byste mít 18 000 stanic.
Projev delšího RTT na pomalých pobočkových linkách
Co když je klient připojen přes pomalou (velká latency, tedy dlouhý RTT) linku z nějaké pobočky a nemá tam DC? Na síti to bude znamenat delší prodlevy mezi jednotlivými pakety. Tím se prodlouží čas aplikace. Ale úměrně tomu klesne špičková zátěž CPU a spotřeba linky v šířce pásma (bandwidth).
Závěr?
Abyste jedno jedinné DC zatěžovali při těchto mých 63 GPO objektech trvale na 5% jedinného jádra CPU a dávali mu trvale 4 Mbps, museli byste mít 7200 stanic.
Kamón.