7 Minutės
Microsoft gruodžio 2025 kumuliatyvus atnaujinimas Windows 11 — KB5072033 — buvo skirtas pagerinti saugumą ir sistemos patikimumą, tačiau daugelis vartotojų praneša, kad jų kompiuteriai pradėjo veikti lėčiau. Apžvalgos ir pranešimai rodo padidėjusį procesoriaus (CPU), atminties ir disko naudojimą po pleistro įdiegimo sistemos versijose 24H2 ir 25H2.
Kas pasikeitė ir kodėl vartotojai tai pastebėjo
Pagrindinė problema slypi subtiliame AppX Deployment Service (AppXSVC) konfigūracijos pakeitime. AppXSVC yra foninė paslauga, kuri atsakinga už Microsoft Store integruotų programų, tokių kaip Skaičiuotuvas (Calculator) ar Nuotraukos (Photos), diegimą ir atnaujinimą. Iki šio atnaujinimo AppXSVC dažniausiai veikė su „Manual" (rankiniu) paleidimo režimu ir būdavo aktyvuojama tik prireikus. Gruodžio pleistras pakeitė šį elgesį į „Automatic" režimą, tad paslauga paleidžiama kartu su sistema ir gali išlikti aktyvi arba nuolat persikrauti fone.
Toks režimo pakeitimas kai kuriuose įrenginiuose — ypač mažesnės galios ar su ribotomis resursų atsargomis — lėmė didesnį CPU, atminties ir disko apkrovimą. AppXSVC susijusios našumo problemos nėra visiškai nauja tema IT bendruomenėse, tačiau vartotojai tvirtina, kad po KB5072033 pleistro simptomai tapo aiškesni ir pasitaiko dažniau.
Techninis paaiškinimas: paleidimo režimai ir fono procesai
Windows paslaugų paleidimo tipai (Automatic, Delayed Automatic, Manual, Disabled) nulemia, kada ir kaip paslaugos įkraunamos. Perėjimas iš Manual į Automatic reiškia, kad paslauga gali būti inicijuojama visos sistemos paleidimo metu, o jei ji dar ir turi mechanizmus periodiškai tikrinti atnaujinimus, tai gali sukelti nuolatinius diskinių operacijų spurtus ir papildomą CPU apkrovą. Taip pat tam tikromis sąlygomis paslauga gali dažnai restartuotis, kas dar labiau didina IO ir kontekstinius pertraukimus, kas pastebima kaip sistemos lėtinimas.
Veiksniai, didinantys poveikį
Ne visi kompiuteriai reaguoja vienodai. Veiksniai, kurie didina KB5072033 poveikį, yra:
- Senesnės arba mažesnės spartos CPU ir SSD/HDD (žemesnės IOPS galimybės).
- Mažesnė operatyvioji atmintis (RAM), dėl ko įtartini procesai priverčia sistemą aktyviau keisti puslapiavimo sritis.
- Daug integruotų Microsoft Store programų arba programų, kurios dažnai tikrinamos atnaujinimams.
- Valdomose aplinkose (pvz., įmonių tinkluose) papildomos administravimo ir saugumo priemonės, kurios kartu su AppXSVC veikimu sukelia daugiau logavimo ar scan operacijų.
Kodėl IT komandos ypač nusivylusios
Valdomose aplinkose naujas AppXSVC paleidimo ir sustabdymo elgesys gali trikdyti stebėjimo ir įspėjimų sistemas. Monitoring'o įrankiai, pvz., Zabbix, Nagios ar kiti sprendimai, gali interpretuoti pasikartojančią AppXSVC veiklą kaip gedimus ar klaidas ir generuoti gausų įspėjimų srautą. Tokia signalų audra trukdo operatyviai identifikuoti tikrus incidentus ir kelia apgavystės (false positive) riziką.
Vienas IT administratorius pranešė, kad teko rankiniu būdu nuslopinti gausybę įspėjimų, kad atstatytų realų infrastruktūros matomumą. Toks laikinų filtrų ar „silencing" taikymas nėra idealus — jis sumažina triukšmą, bet gali paslėpti svarbius signalo fragmentus.
Stebėjimo ir įspėjimų mechanikų niuansai
Tipinės problemos, su kuriomis susiduria IT:
- Event Viewer (Įvykių žurnalas) užpildomas paslaugos įrašais, kurie įvertinami kaip klaidos ar nusiskundimai.
- Performance counters rodo periodinius CPU/I/O pikus, kurie prilyginami programų gedimams.
- Agentiniai sprendimai (pvz., valdymo agentai) gali bandyti keletą kartų perkrauti arba aptarnauti paslaugą, kas dar labiau išprovokuoja resursų spurtus.
Tarpu sprendimai, rizikos ir Microsoft pozicija
Microsoft patvirtino pakeitimą savo palaikymo pastaboje, nurodydama, kad „Automatic" paleidimas buvo įvestas tam, kad pagerintų patikimumą „tam tikrais izoliuotais scenarijais". Kartu kompanija įspėjo, kad AppXSVC išjungimas gali sutrikdyti Microsoft Store programų atnaujinimus arba nebeleisti automatiškai diegti naujinių.
- Kai kurie pažangesni vartotojai bando keisti paslaugos nustatymus arba redaguoti registrą (registry), kad grąžintų seną Manual paleidimo elgesį. Microsoft nerekomenduoja tokio metodo, nes tai gali pakenkti oficialiems programų atnaujinimams ir palaikymo srautams.
- Kiti administratoriai tiesiog stebi resursų naudojimą ir laikinai atšaukia atnaujinimą valdomose aplinkose, kol nebus pateikta pataisa ar išsamesnė gairė.
- IT komandoms praktinis patarimas — laikinai filtruoti arba sukonfigūruoti įspėjimų lygį, kad triukšmas sumažėtų ir administratoriai galėtų tyrinėti problemą be gausaus falsyvių aliarmų srauto.
Saugumo ir palaikymo rizikos
Reikia aiškiai įvertinti rizikas prieš imantis bet kokių pakeitimų:
- Išjungus AppXSVC galima sutrikdyti saugumo atnaujinimų diegimą per Microsoft Store platformą arba per susijusias infrastruktūras.
- Registry ar paslaugos konfigūracijos keitimas gali būti nepalaikomas oficialiai ir gali komplikuoti palaikymo atvejus su Microsoft arba pardavėjais.
- Atnaujinimo atšaukimas plačiu mastu gali palikti sistemas be esminių pataisų, todėl reikia derinti verslo rizikos ir operacinės rizikos santykį.
Ką stebėti ir kokie tolesni žingsniai
Jeigu po gruodžio pleistro jūsų PC pasirodo sulėtėjęs, šie konkretūs žingsniai padės įvertinti ir valdyti situaciją:
1. Sistemos diagnostika
Patikrinkite užduočių valdytoją (Task Manager) arba profesionalius įrankius (Process Explorer, Resource Monitor) ir ieškokite AppXSVC ar susijusių proceso pavadinimų. Stebėkite CPU, atminties ir disko veiklą, ypač logiškai susiedami pikus su AppXSVC veikla. Taip pat patikrinkite Event Viewer įrašus, susijusius su AppXSVC arba su pakartotinėmis paslaugos klaidomis.
2. Administravimo ir diegimo strategija
Jei administruojate kelias sistemas, prieš platų išleidimą rekomenduojama patikrinti atnaujinimą ant mažesnės kontrolinės grupės (canary / pilot). Tokiu būdu galite pamatuoti poveikį skirtinguose aparatavimo lygiuose ir operacinių sistemų konfigūracijose (SSD vs HDD, RAM kiekis, procesoriaus architektūra).
3. Laikinas atšaukimas ir valdymo priemonės
Valdomose aplinkose atnaujinimą galima laikinai atšaukti per įrankius kaip WSUS, SCCM (ConfigMgr) arba Windows Update for Business politiką, kol Microsoft neišleis pataisos. Jeigu reikia, IT komandos gali nusistatyti papildomus monitoringo filtrus ir pranešimų taisykles, kad sumažintų triukšmą ir išlaikytų operatyvinį matomumą.
4. Galimi techniniai darbo įrankiai
Administratorių įrankiai, kuriuos verta naudoti tyrimui ir stebėsenai:
- Task Manager, Resource Monitor, Process Explorer — realaus laiko procesų stebėjimui.
- PowerShell komandos, pvz., Get-Service AppXSVC arba Get-Process, kad patikrinti paslaugos būseną ir veikiančius procesus.
- Event Viewer — žurnalų peržiūrai. Ieškokite įrašų, rodančių dažno AppXSVC paleidimo, klaidų ar specifinių Event ID, susijusių su paslaugos darbo sutrikimais.
- Monitoring įrankiai (Zabbix, Nagios, Prometheus) — pritaikyti alertų taisykles, kad atpažintų pasikartojančius, bet ne kritinius įvykius.
Primygtinai rekomenduojama vengti ilgalaikių, neoficialių pataisų (registry pakeitimų ar paslaugos išjungimo) be visiško poveikio įvertinimo ir atsarginės plano. Microsoft kol kas pateikė paaiškinimą apie pakeitimo paskirtį, bet nepatvirtino saugios, nuolatinės procedūros senajam elgesiui atkurti.
Ilgesnio laikotarpio valdymas
Organizacijos turėtų sukurti nuoseklią strategiją: 1) įvertinti poveikį pilotiniame tinkle; 2) nuspręsti dėl laikinų atšaukimų ar politikų; 3) stebėti Microsoft palaikymo kanalus dėl pataisų; 4) pasiruošti standartiniams atkūrimo scenarijams, jeigu oficiali pataisa vėluoja.
Galiausiai, vartotojai ir IT administratoriai balansuoja tarp galimo patikimumo pagerinimo ir realiai juntamo našumo nuosmukio. Šiuo metu atsargumas, kruopšti testavimo praktika ir nuolatinė stebėsena — geriausias kelias į priekį.
Šaltinis: gizmochina
Palikite komentarą