De meest voor de hand liggende reden om te kiezen voor een 64 bit Citrix (of Terminal server) omgeving is vanwege het beschikbare werkgeheugen. Een 32 bit besturingsysteem kan niet meer dan 4 GB adresseren (2 ^ 32 = 4294967296) en zal dus op een alternatieve manier meer geheugen moeten adresseren. Het is dus wel mogelijk maar levert beperkingen op.
Hier lijkt een 64 bit omgeving dé oplossing.
Bij het inrichten van een Citrix (of Terminal server) omgeving op een 64 bit platform zijn er een aantal dingen waar je rekening mee moet houden. Zeker in het kader van het gebruik van geheugen.
Allereerst (de meest voor de hand liggende stap) dient gekeken te worden naar de applicaties. In de meeste omgevingen waar ik kom zijn alle applicaties 32 bit, niet 64 bit. Dit heeft als gevolg dat als er een 32 bit applicatie wordt opgestart er extra handelingen moeten worden verricht zodat de applicatie gebruikt kan worden in de desbetreffende omgeving. Bij het gebruiken van deze applicaties op een 64 bit omgeving zal het geheugenverbruik van elk proces 1.5 a 2 keer zoveel zijn als op een 32 bit omgeving. Goed, dat is met de mogelijkheden van een 64 bit omgeving (tot 64TB ipv 4GB) en het feit dat geheugen steeds goedkoper wordt steeds minder een probleem.
Maar waar extra rekening mee gehouden moet worden is bij het printen. Er zijn weinig omgevingen waar niet wordt geprint dus dit zal wellicht ook gelden voor jouw omgeving. Zodra een 32 bit process toegang wil tot de print spooler zal er per sessie een conversie proces worden gestart. Dit proces is splwow64.exe. Waarbij spl = spooler, wow = windows on windows en 64 is uiteraard het 64 bit kenmerk. Dit betekent dus een overhead voor elke sessie die gebruik maakt van de print spooler (en dat is vrijwel elke gebruiker). Okay zou je zeggen, dat kan ik eenvoudig berekenen door het aantal sessies maal het aantal benodigde geheugen voor een splwow64.exe proces. Helaas blijkt dit anders te werken.
Bij het aanroepen van de spooler, via het splwow64.exe proces, zal de print job hierin worden verstuurd en groeit het proces afhankelijk van de grootte van de job. Nu is er nagedacht over dit proces en is de gedachte dat het efficient is als dit proces wat langer blijft bestaan, voor het geval er weer wordt geprint en het proces weer moet worden gestart. Dit voorkomt dat het proces (ik heb het over splwow64.exe) wordt gestart, gestopt en weer gestart.
Echter als er grote printjobs worden verstuurd, zoals een PDF waarin afbeeldingen zitten verwerkt dan blijft het proces splwow64.exe (per gebruiker, per printjob) groeien. En doordat het proces blijft wachten. voor het geval dat…, blijven de processen groeien en groeien… en groeien… en ja, tot deze groot wordt. In een omgeving waar veel met Excel en PDF wordt gewerkt zijn waarden gevonden tussen de 30 en 300MB per sessie (!).
Okay, er spelen nu twee vragen in mijn hoofd.
1) Is dit een memory leak? Waarom blijft het proces splwow64.exe steeds verder groeien en laat hij de vorige jobs niet ‘los’?
2) Waarom blijft het splwow64.exe proces actief en waarom verkorten we deze tijd niet naar laten we zeggen 1 minuut?
Het is mogelijk om de waarde aan te passen zodat het splwow64.exe proces actief blijft (na het uitvoeren van de printjob) in het register. In de key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlPrint kan een DWORD sleutel SplWOW64TimeOut worden toegevoegd.
Deze waarde geeft het aantal minuten weer dat er wordt gewacht nadat de laatste printjob is voltooid.
Let op : Bij het afmelden van een sessie kan het voorkomen dat het splwow64.exe voorkomt dat de sessie goed afsluiten.
Als je gebruik maakt van RES PowerFuse dan wordt dit verhoplen in PowerFuse 2008 SR3, en als je (nog) geen gebruik maakt van RES PowerFuse (2008) dan is dit zeker een aandachtspunt.
Kort samengevat: 64 bit machines hebben hun voordelen, en absoluut de toekomst, maar het toepassen van 64 bit machines voor een Citrix / Terminal server? Ik ben nog niet overtuigd, de tijd zal het leren.
Ingmar Verheij
Nederlands 
English