Az utóbbi időben a processzorok órajele mellett azok energia gazdálkodási funkcióit is jelentősen fejlesztették, ami elég hasznos egy laptop esetén, és nem mindig hasznos pl. valós idejű használat során egy asztali gépben.
Akit nem érdekel a fogyasztás, ellenben konstans performanciát szeretne elérni, érdemes lehet módosítani az alapértelmezett energiagazdálkodási beállításokat (power options).
Ehhez egy jó kiindulási alapot nyújthat az alábbi cikk:
Az újabb Windows verziók kapcsán – kivéve Windows 10 – a Microsoft kiemelt figyelmet fordított az operációs rendszer teljesítménye. Az ez irányú törekvések emlékét őrzik az egyre jobb performancia elemző eszközök, mint pl. a Task Manager (és az onnan elérhető Resource Monitor). Bár ezek továbbra sem váltják ki a jó öreg Process Explorer, Process Monitor-t, de az esetek egy részében a problémák már detektálhatók natív windows-os eszközökkel (is).
A szuper optimalizált windows-om a napokban ismét lehetőséget biztosított, hogy foglalkozzak vele kicsit, mert login előtt megállt, és várt vagy 20 másodpercet, ezután dobott a login képernyőre. Mivel itt még boot fázisról beszélünk, sajnos a fenti eszközök egyike sem használható. Első körben megnéztem az event log-ot, hátha találok benne valami érdekeset (ahogy a mondás tartja, aki keres az talál), de ennek a várakozáshoz sajnos nem volt köze.
Egyéb okokból már telepítve volt a gépen a Windows Assessment and Deployment Kit (Windows ADK) Windows Performance Analyzer komponense, ami lehetőséget biztosít trace-k készítésére, azok elemzésére, akár boot idő alatt is.
A használatához rá kell venni a windows-t, hogy trace fájlt generáljon, melyből majd kideríthetjük, hogy mi is történik a vizsgált időszakban. Régen ehhez pár száz karakterből álló parancssort kellett készíteni (xbootmgr…), de a Microsoftnál is sejthették, hogy ez ebben a formában nem valami jó, és egy szorgalmas fejlesztőnek hála ma már ezt konfigurálhatjuk grafikus felületen is (na jó a felület képességeit nem vitték túlzásba, de hát ki a kicsit nem becsüli…).
wprui.exe
Az ily módon megkeletkezett fájlt (pl.: boot_1.etl) a Windows Performance Analyzer-rel tudjuk alaposabban megvizsgálni. Mivel az én problémám a boot alatt jelentkezett, de még login előtt, az első nézet amit bekapcsoltam a Boot Phases volt. Itt már látszott, hogy a bejelentkezés előtt a Winlogon init 31 másodpercig tartott, ami gombócból is sok, nem hogy boot időből…
A fenti nézethez hozzádobtam még a Processes nézetet, hogy látszódjon milyen alkalmazások indultak el ezen idő alatt.
A processeket vizsgálgatva feltűnt egy alkalmazás ami a login inittel indult, és 29.9 másodpercig futott… Ez az alkalmazás pedig nem volt más, mint az OriginWebHelperService.exe…
Ezután eszembe jutott, hogy nemrég elindítottam az Origin-t, és frissítette magát… A process egyébként service-ként települt, a frissítés rakta fel/kapcsolta be, ott kellett kikapcsolni, és a probléma megszűnt… Ezúton is köszönöm az EA-nak a fejtörőt, szórakoztatóbb volt, mint a legtöbb mostani játékuk 😉
Táblák kezelése kapcsán előfordul néha, hogy bizonyos dupla előfordulásokat szeretnénk megjelölni/kitörölni. Ezt a Google spreadsheet-ek esetén script segítségével tehetjük meg.
Az alábbi script pirossal jelöli azon sor előfordulásokat, ami a táblázatban már egyszer szerepelt:
function markDuplicates() {
var sheet = SpreadsheetApp.getActiveSheet();
var range = sheet.getDataRange();
var newData = new Array();
for(var i = range.getRow(); i < range.getLastRow(); i++){
var row = range.offset(i, 0, 1);
var rowData = row.getValues();
for(j in newData){
if(rowData.join() == newData[j].join()){
row.setBackgroundRGB(255, 0, 0);
}
}
newData.push(rowData);
}
}
A kód készítése során az alábbi források segítettek:
Réges rég elkövettem azt a hibát, hogy windows alapú gépen kezdtem el zenélni. Aztán hozzászoktam, megszerettem, és bár azóta volt szerencsém más operációs rendszereket is kipróbálni, a végén mindig visszatértem hozzá. A számítógépen történő zenélés nagyon furcsa dolog, ha menet közben bármi megakad, akkor lehet újracsinálni a munka egy részét, és vannak olyan pillanatok, amiket később már nem lehet, vagy nagyon nehéz újracsinálni, tehát ehhez egy elég stabil rendszer kell. Sokan ezen a ponton alapból lemondanak a windows-ról, pedig kitartó munkával (és nem kevés utánajárással) meglepő eredményeket lehet elérni, hozzáállás kérdése az egész. Míg egy debiant szépen lassan épít fel az ember, a windowsnál épp az ellenkezőjét kell csinálni, szépen lassan lebontani a rétegeket.
tl;dr: Az optimalizált windows olyan mint egy jó versenyautó: Gyors, de egyáltalán nem kényelmes. Átlag felhasználóként a driverek frissítése az egyetlen szükséges lépés, a többi beállítás inkább problémát fog okozni, és érezhető előnyt nem jelent.
Mi is az optimalizálás célja: az alkalmazásunk működése és a hw komponensek között a lehető legkisebb késleltetés történjen, és ebbe az operációs rendszer lehetőleg ne keverjen bele.
az usb eszközök számát minimalizáljuk (ps/2 billentyűzet)
usb hub-ot semmiképp se használjunk
BIOS:
kapcsoljuk ki a hyper threadingot
mindenféle virtualizáció támogatást
HPET-et
Integrált videó és hangkártyát
Driverek:
Ha ezzel megvagyunk, akkor állhatunk neki a windows-nak. Alapesetben én azt javaslom, hogy mindenből a legfrissebb drivert rakjuk fel, de a driver-ek minőségének megállapítása során csak a folyamatos mérések nyújthatnak támpontot. A driverek frissítésére kiválló a Snappy Driver Installer, a driverek minőségének ellenőrzésére a LatencyMon alkalmazást tudjuk használni.
Windows komponensek:
Ezek után el kell távolítani a windows összes olyan összetevőjét, amit valószínűleg sosem fogunk használni:
– Internet Exploder
– Windows Location Provider
– Work folders client
– XPS services
– XPS viewer
Én a print services-t is levettem, nem szándékozok papírra nyomtatni a közeljövőben.
Windows:
A főbb alapvetéseket a Focusrite elég jól összefoglalta, érdemes követni a leírásukat. A lényeg kivonatolva:
Power management -> high performance, cpu minimum és maximuma is 100% legyen
Rendszerhangok kikapcsolása
Processzor prioritás: Background services
Tűzfal, vírusírtó kikapcsolás
Vizuális effektek
És egy dolog, amit itt nem írnak: fix (min == max) méretű swap file használata.
Hálózat:
Ha ez megvan, akkor kikapcsolhatjuk az összes olyan dolgot, amire nincs szükségünk a hálózaton (és lássuk be elég kevés dologra van szükségünk valójában):
Az IPV6 kikapcsolásához már a registry-t kell átírnunk: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
new DWORD (32-bit) Value -> DisabledComponents = 0xff
Amennyiben a hálózat késleltetése számít nekünk, akkor a szükséges optimalizációkat elvégezhetjük a TCPOptimizer nevű alkalmazással, de ez inkább streaming, és játékok esetén lehet hasznos.
Szolgáltatások:
Ezek után már csak azt kell elérnünk, hogy csak azok a programok fussanak, amire tényleg szükségünk van. Mivel a windows a legtöbb komponensét szolgáltatásokon keresztül indítja, itt is kell leállítanunk őket. Ezt a services.msc futtatásával tehetjük meg.
Bizonyos szolgáltatásokat viszont nem nagyon tudunk leállítani (mint pl. a Task Scheduler) mert a windows ezt nem engedi. Ezeket a registry segítségével tudjuk kikapcsolni.
A szolgáltatások kulcsait itt találjuk: HKLM\SYSTEM\CurrentControlSet\Services
A szolgáltatások rövid névvel kerülnek ide elmentésre, de azokat láthatjuk a service listában is, az adott szolgáltatás Properties oldalán (pl. a Task Scheduler neve Schedule)
Az indítás módát a Start tartalmazza, a 4 érték jelenti a Disabled beállítást. (forrás)
A szükséges szolgáltatások:
A többi dolog nem szükséges.
A TCP/IP NetBIOS helper szolgáltatás a SAMBA megosztások eléréséhez szükséges.
Amennyiben fájlokat szeretnénk megosztani, el kell indítani a Server szolgáltatást.
Amennyiben a Windows Update-t szeretnénk használni, akkor előtte el kell indítani az alábbi szolgáltatásokat:
Network List Service
Network Location Awareness
Background Intelligent Transfer Service
Windows update
Figyelem:
a BITS az operációs rendszer más dolgaihoz is kellhet (pl. nyelvek telepítése, DISM és SFC javításokhoz), csak akkor állítsuk le, ha ezek már mind rendben vannak.
a Task Scheduler leállítása után nekünk kell futtatni azokat a dolgokat, amik az operációs rendszer hatékony működését biztosítják, és a Task Scheduler időzítve futtatta őket (pl. a WinSxS könyvtár takarítását).
Alkalmazások:
Bár a fentiek után ezt külön kiemelni nem is érdemes, fontos, hogy a gépen csak az az alkalmazás fusson, amit használni akarunk, ezért a Task Manager Startup szekciójából mindent állítsunk disabled-re. Ez nem csak a rendszer teljesítményére lesz jó hatással, hanem a boot time-ra is (nálam jelenleg 5 másodperc alatti). Amire még szükségünk lehet az a ctfmon alkalmazás (C:\Windows\System32\ctfmon.exe) ami a tray-en a billentyűzet nyelvének állítását teszi lehetővé. De lehetőleg ezt is csak akkor indítsuk el, ha szükségünk van a magyar billentyűzetre, és utána zárjuk is be szépen.
A fentiek után már kész is a szuper munkára fogható windows-unk, ami valahogy így fog kinézni:
Le akartam törölni pár nagyobb sémát Oracle alatt, aminek az lett az eredménye, hogy 20 órát futott a DROP USER… Kis olvasgatás után az körvonalazódott, hogy ezt a funkciót nem sikerült jól implementálni, ezért inkább töröljek kézzel mindent, és csak a végén töröljem a már üres sémákat… Nagy nehezen kiizzadtam magamból a lenti scriptet, ami működik is, de mivel az impdb implementációja sem sikerült teljesen ezért a végső megoldás az lett, hogy el kell dobni a teljes adatbázist, és újra kell gyártani nulláról… De ha már megírtam, akkor elmentem, hátha még jól jöhet a későbbiekben…
BEGIN
FOR r1 IN ( SELECT 'DROP ' || object_type || ' ' || owner || '.' || object_name || DECODE ( object_type, 'TABLE', ' CASCADE CONSTRAINTS PURGE' ) AS v_sql
FROM all_objects
WHERE owner in ('SCHEMA1', 'SCHEMA2') AND
object_type IN ( 'TABLE', 'VIEW', 'PACKAGE', 'TYPE', 'PROCEDURE', 'FUNCTION', 'TRIGGER', 'SEQUENCE' )
ORDER BY object_type, object_name ) LOOP
BEGIN
EXECUTE IMMEDIATE r1.v_sql; exception when others then null;
END;
END LOOP;
END;
/
DROP USER CUSTOMER SCHEMA1 CASCADE;
DROP USER CUSTOMER SCHEMA2 CASCADE;
Ritkán adódik alkalom arra, hogy belelássunk egy-egy független játék készítésének költségeibe, és bevételeibe, pedig ezek elég jó támpontot nyújthatnak azoknak, akik ilyesmiben gondolkoznak. Nem is tudom mit tehetnék hozzá, beszéljenek helyettem a számok…
Több mint 10 éve linux alapokon működött a szerverem. Akkor azért váltottam Windowsról, mert feltörték a rajta futó IIS szervert egy expolit-on keresztül (szégyen gyalázat), és úgy döntöttem, többet ilyen nem lesz. Az utóbbi pár évben, viszont semmi sem történt… Rájöttem, hogy már nem szórakoztat az ubuntu, minden működik, már a dist upgradek sem a régiek, hogy utána összeomlana a rendszer és újra össze kell rakni darabokból… Szóval egy hirtelen ötlettől vezérelve, arra gondoltam, hogy megpróbálom ugyanezt Microsoft alapon is, mert miért is ne.
A Microsoft azért nem aprózza el ezt a bemutatkozás, és felhasználói élmény dolgot, az első pár nap alatt feltépődtek a régi sebek, jöttek újak, annak ellenére, hogy a Windows 3.1 óta midnig Windowst használtam desktopra…
A szerverem az Raspberry térhódításával majdhogynem csak egy NAS-ra degradálódott, pár extra funkcióval. Gondoltam első körben megosztok pár dolgot, elvégre mégiscsak az Ms találta ki az smb protokollt. Na de az összes meghajtót ami a gépben van, azt viszont nagyon nem terveztem megosztani. Ez volt az első dolog (a windows 10 update dialógus ablak után) ahol gyökeresen eltért a véleményünk a dolgok menetével kapcsolatban… A Windows szerint nincs is annál jobb dolog, mint az administrative shares (nem tudom ki találta ki, és az IT security hogy hagyhatta ezt produkcióba kerülni, és azóta is miért létezik ez még egyáltalán, de legalább a net send-et kivették… az is valami 🙂
Aki ki szeretné kapcsolni ezen remek funkciót a gépén nem kell mást tennie, mint létrehozni egy AutoShareWKS nevű DWORD(32) kulcsot az alábbi helyre:
Igen, még létre sincs hozva 1 értékkel, hogy csak át kelljen írni, és ezen infók fórumok útján terjednek… Vannak dolgok, amik nem változnak, ekkor már éreztem, hogy megérkeztem 🙂
És természetesen a network credential-os bug-ot sem sikerült javítani az elmúlt ~20 év alatt. Pedig nem bonyolult reprodukálni. Fogunk egy szervert, ahol pár megosztás bárki számára lekérdezhető. Aztán belerakunk pár olyan megosztást, ami csak adott felhasználók számára elérhetőek. Amikor a windows authentikál először megpróbálja kérdés nélkül a bejelentkezett felhasználó adataival (Ez egyébként megint egy érdekes kérdés, miért történik így. Vajon csak nekem jutott eszembe, hogy egy speciális megosztással, és egy megfelelő rainbow táblával viszonylag egyszerűen megtudható az adott felhasználó jelszava?). Ha a windows egyszer sikeresen azonosította magát egy szerveren, akkor a felhasználó hiába ír be jó azonosító adatokat az idők végtelenségéig a privilegizált megosztáshoz, csak a lenti dialógusablakot fogja látni:
Ilyenkor mindenki elkezdi keresni a szerveren a problémát, hiszen Access is denied, mi más lehet a probléma… Úgy gondolom, hogy az emberek többsége itt adja fel, de nézzük csak meg mi történik, ha ugyanezt tesszük parancssorból?
C:\Users\voji>net use \\192.168.1.10\openhab
The password is invalid for \\192.168.1.10\openhab.
Enter the user name for '192.168.1.10': openhab
Enter the password for 192.168.1.10:
System error 1219 has occurred.
Multiple connections to a server or shared resource by the same user,
using more than one user name, are not allowed.
Disconnect all previous connections to the server
or shared resource and try again.
Minderről a GUI annyit mond, hogy Access is denied. Grafikus felületről akarsz csatlakozgatni mindenhova? Akkor úgysem értesz hozzá, minek is terhelne az operációs rendszer ezzel a sok felesleges információval… A “soft” mountokat GUI-ról szintén nem lehet látni, szóval amúgy is mindegy lenne… De ha már itt tartunk, akkor kicsit jobban megnézve, milyen share is van jelenleg “mountolva”:
C:\Users\voji>net use
New connections will be remembered.
Status Local Remote Network
-------------------------------------------------------------------------------
OK \\192.168.1.10\IPC$ Microsoft Windows Network
The command completed successfully.
Bizony, IPC (Inter Proces Communication), amit az RPC (Remote Procedure Call) használ. Egyszerűen hibátlan… És ha tudnátok, hogy az RPC-n belül még mennyi rövidítés van (EPM, COM+, BIT, RPCSS, és még csak a jéghegy csúcsát karcolgatjuk…)
A lényeg, hogy jelen probléma megoldására a bátrak használhatják az alábbi parancsot:
net use * /d
Kevésbé bátrak beírhatják a * helyére a mount nevét is (ami a fenti példában: \\192.168.1.10\IPC$)
És ezek csak azok a dolgok amik NT4 óta így maradtak… Az újakba, mint pl. a fastboot még bele se mentünk… Pedig…
A microsoft kitalálta, hogy a kernel modulok, és driverek viszonylag ritkán változnak az operációs rendszer élete során, ezért ezeket felesleges is mindig nulláról betöltögetni. Ezért az új windows verziók esetében (8+) bevezették a fastboot-ot, ami annyit tesz, hogy amennyiben kikapcsoljuk a gépet, akkor valójában nem az történik, amire a felhasználó első körben számít. Ugyanis a windows fogja és hasonló dolgot csinál, mint amikor hibernate-t mondunk, egy különbséggel. Nem a teljes memóriát menti, hanem csak a futó szolgáltatások memóriaképét. Zseniális ötlet, akit érdekel, hogy működik, itt olvashat egy felületes cikket a témában: http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html
A probléma nem is ezzel van, hisz mivel ez az alapbeállítás, a világ elég nagy részén így kapcsolják ki kedvenc operációs rendszerüket. Ellenben volt a windowsban egy funkció, amit elég gyakran használtam, mégpedig a Group Policy Editorban a startup / shutdown scripts. Ez pont annyit tud(ott), mint amit a neve is mond: megadható neki egy program, amit a rendszer Local System-ként végrehajt a rendszer indulása és leállása során. A fastboot viszont kicsit bekavart a képbe, mert a be/kikapcsolás már nem inicializálja a rendszert a megszokott módon, és ebben az esetben nem is fut le egyik megadott script se. Hogy ebből mit lát a végfelhasználó? Megírja a scriptet, restart, működik. Aztán shutdown, és nem fut az a script, ami az előbb még futott. Aztán előbb utóbb összerakja, hogy hát itt valaki nagyon vicces kedvében volt, mert a startup/shutdown script csak restart esetén fut. A megoldásra két lehetőség van: Vagy kikapcsoljuk a fastboot-ot tokkal-vonóval, és akkor működni fog a startup és shutdown script, vagy továbbra is használjuk a fastboot-ot, de akkor nincs lehetőségünk korrekt módon programokat futtatni a windows indulása/leállítása során (én legalábbis nem találtam, de ha valaki tud ilyet és megosztja velem, akkor jár neki a Mars szelet).
Aztán kipróbáltam még az új Storage Spaces Pool-t (gyk.: mdadm by microsoft). Azt még nem tudom, mi fog történni, ha összeomlik a RAID array, mert ezzel kapcsolatban a Microsoft azt mondja, hogy nem omlik, de ilyen apróságoktól nem szoktam megrettenni. Az mondjuk azért nem annyira bíztató, hogy a disk kivételéről még csak nem is zenélnek a grafikus felületen. A problémára a megoldást természetesen megint egy fórumban lehet megtalálni, vagy jobb esetben, a fórum alapján készült blogbejegyzésben 🙂
És a viccesebbnél viccesebb hibákról még nem is beszéltem. A mostani kedvencem a KB3053711 (user error-nak szoktam hívni). Tessék elolvasni a kapcsolódó knowledge base article-t és a javasolt megoldást… Igazából minden szava arany, csak azt sajnálom, hogy a kapcsolódó forráskódot nem mellékelték, mert ez már az a szint amit minden szakmabelinek látnia kellene…
A Microsoft egyértelműen utolérhetetlen a felhasználói élmény fokozásában… 🙂
Régen ledöbbentem, amikor a levélben “tomorrow 14:00”-ra az ipad felajánlotta, hogy ezt beírná a naptáramba. Ma pedig ezt produkálta az Inbox:
Szerintem ez még csak egy ügyes grep, de a jelenleg futó személyi asszisztens és AI fejlesztések mellett ez a vonal elég messzire vezethet a közeljövőben…
