RDP belast server 100%

[Verwijderd]

Beste bezoekers,

Ik zit met een vrij irritant probleem en ik kom er zelf niet echt goed uit. Heb uiteraard gezocht via google en zelfs Microsoft gebeld echter niet zo makkelijk om een tech aan te lijn te krijgen.

We hebben een migratie gedaan van Server 2003 naar Server 2008 R2 alles volgens boekje gedaan software etc erop.

op de ouder server hadden we Terminal Service geïnstalleerd waarbij we users laten inloggen op de server om een programma te starten in dit geval Profit.

Nu op de nieuwe server heb je geen terminal server meer in de vorm zoals we gewend waren maar, je moet cals aanschaffen per device of per user wat voor heen gratis was moeten we dus nu ervoor betalen.

gelukkig hebben we een desktop client van die software die connectie maakt met de database (andere server) die kunnen we dus helpen.

Het probleem is dat de CPU te veel belast word als er meer mensen inloggen via RDP belasting is redelijk continue 100%. hoe kunnen we ervoor zorgen dat de belasting verlaagd?

[_Arthur]

Verwijderd schreef op donderdag 22 januari 2015 @ 12:38:
Nu op de nieuwe server heb je geen terminal server meer in de vorm zoals we gewend waren maar, je moet cals aanschaffen per device of per user wat voor heen gratis was moeten we dus nu ervoor betalen.

Met 2003 moest je daar ook al voor betalen; alleen werden de licenties niet ge-enforced zoals in 2008 (en hoger). In 2008 (en hoger) heb je RDS.

Om je belasting te verlagen, moet je eerst weten wat voor die belasting zorgt.

Dus slinger perfmon en/of je taskmanager eens aan en bekijk wat die belasting veroorzaakt.

[Verwijderd]

De meeste belasting zie ik nu dat het door acrobat reader komt. deze word door verschillende mensen opgestart waardoor je een lijst aan users heb die acrobat opstarten.

[Question Mark]

• Hoeveel cpu-load genereert Acrobat Reader dan per user?
• Welke versie Acrobat Reader, en heb je al eens andere versies geprobeerd
• Wat is de sizing van je Terminal Server (is deze fysiek of virtueel)
• Hoeveel users praten we over
• etc.

Kortom, vertel eens iets meer over je omgeving en de zaken die je zelf al geprobeerd hebt.

Het klinkt gewoon alsof je RDS te licht is voor de load die geleverd moet worden. Eventueel zou je met de Windows System Resource Manager het Acrobat Reader proces iets kunnen "knijpen". Maar dat is eigenlijk meer symptoombestrijding.

En als laatste vraag, waarom migreer je nu nog in hemelsnaam naar Windows 2008R2 en niet naar Windows 2012R2?

[SirDarkAngel]

Verwijderd schreef op donderdag 22 januari 2015 @ 12:51:
De meeste belasting zie ik nu dat het door acrobat reader komt. deze word door verschillende mensen opgestart waardoor je een lijst aan users heb die acrobat opstarten.

Iets zegt me dat het handig is een specialist in te huren om je configuratie na te laten kijken. Als ik je teksten lees krijg ik het gevoel dat je RDS kennis onvoldoende is. Dat terzijde, trekken de Adobe processen allemaal een core vol? Dat is een bekend probleem op terminal servers. Even deze keys importeren via GPO preferences of een login script:

HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\IPM
bShowMsgAtLaunch (REG_DWORD) set to 0
bDontShowMsgWhenViewingDoc (REG_DWORD) set to 0

(Let even of het versie nummer "10.0" overseen komt met de versie welke je draait, anders gaat het niet werken)

Deze keys unchecken de volgende opties in adobe:

• Show me messages when I launch Reader
• Don’t show messages while viewing a document

Lost hopelijk je probleem op, success!

[Killah_Priest]

Het wordt mij nav de OP ook niet duidelijk of de RDP connectie wordt opgezet naar de 2008R2 server OF naar de desktop.
Wat zijn overigens de specificaties van de machine waarop de problemen spelen? Op welke manier hebben jullie gemigreerd?

[Verwijderd]

bedankt voor de reacties tot nu toe.

Ondertussen is er veel gebeurd en gesleuteld aan de server.

Om even aantal vragen te beantwoorden

wat is er gemigreerd? : eigen me woorden keus verkeerd want we hebben niks gemigreerd alles is nieuw opgezet op een virtueel machine VMWare based.

Specs

Platform VMWare
Server 2008 Standaard R2
8 Gb geheugen
120 GB SCSI SSD
2 CPU

We zijn sinds kort naar een IAAS omgeving gemigreerd met allemaal nieuwe ESX hosts en hardware daarbij ook nieuwe disks voor de datastores. Hardware of VMWare laag gezien kan dit geen vertragings factor zijn waarom processen traag draaien.

Op de server draaien we een P&O systeem Profit van AFAS waarbij aantal collega's gebruik maken van RDP om taken uit te voeren op het systeem. Het volgende hebben we afgelopen weken gedaan alle gebruikers die via RDP binnen kwamen overgezet naar een lokale client die met de database verbind op een andere server. Hierdoor hebben we eigenlijk het probleem voor RDP opgelost maar, de belasting blijft vreemd genoeg op de server gelijk en lijkt meer verplaatst te zijn naar excel.

Momenteel zijn we bezig met support van Afas om dit op te pakken waarbij ik het vermoede heb dat sessies van processen blijven hangen op de server en niet goed afgesloten worden met als resultaat trage performance.

iemand idee hoe excel 2013 Multi sessies beperkt kan worden?

[Question Mark]

Verwijderd schreef op dinsdag 17 februari 2015 @ 16:40:
Hardware of VMWare laag gezien kan dit geen vertragings factor zijn waarom processen traag draaien.

Dappere uitspraak, die durf ik met al mijn ervaring zonder eerst te meten niet te doen. Ik zou echt flink gaan meten aan het systeem. Niet alleen met perfmon vanuit Windows, maar ook op Hypervisor laag. Let vooral even op het aantal contextswitches per seconde. Da's een belangrijke counter bij gevirtualiseerde RDS servers.

http://thomaskoetzing.de/...sk=view&id=196&Itemid=260

Momenteel zijn we bezig met support van Afas om dit op te pakken waarbij ik het vermoede heb dat sessies van processen blijven hangen op de server en niet goed afgesloten worden met als resultaat trage performance.

iemand idee hoe excel 2013 Multi sessies beperkt kan worden?

Wat bedoel je hier precies mee? Wat heeft Excel ineens met het verhaal te maken?

Ik heb even gezocht naar Afas Profit en het lijkt dat deze een SQL 2012 database gebruikt? Waar staat deze database, en hoe performed de database en databaseserver?

[lazybones]

Afas Profit belast een terminalserver inderdaad bovengemiddeld. Laat ik voorzichtig formuleren dat e.e.a. programmatechnisch een stuk efficienter geprogrammeerd zou kunnen worden. Veel voorkomende oorzaak van vertragingen is virusscanner in combinatie met Afas.

Maar buiten dat: hoe veel gebruikers zijn er tegelijkertijd op die server actief, draaien er nog andere applicaties behalve Afas? Voor een Remote Desktop server is 8GB geheugen ook niet echt ruim bemeten.

[ Voor 28% gewijzigd door lazybones op 19-02-2015 21:43 . Reden: aanvulling ]

[FREAKJAM]

Ik zou je toch adviseren om het probleem wat zich afspeelt op terminal server eerst proberen op te lossen. Afas brengt regelmatig updates en patches uit van het pakket en als je dat allemaal moet gaan onderhouden op fat client niveau word je daar echt niet vrolijk van. (de patches zijn niet in msi format, maar met batch scripting en de patchtool van Afas zelf kom je natuurlijk al een heel eind).

Ik heb op mijn werk een RDS farm ingericht met 24 servers (VMWare 5.1), Windows 2012R2 met "slechts" 12GB RAM. Hier draait Office 2010, de laatste Acrobat Reader XI, Profit en nog een flink aantal apps op. Al onze servers zijn vrijwel identiek; Ik rol de servers uit met MDT 2013. Er werken bij ons gemiddeld 15 tot 20 mensen op één terminal server. Gemiddeld neemt bij ons een terminal server 7 a 8GB van de 12GB in beslag.

De laatste Profit versie (2016 Build 1 Update 4) draait bij ons in ieder geval zonder problemen en neemt totaal niet veel geheugen in beslag. Kijk eerst eens simpelweg welk proces 100% cpu in beslag neemt op je terminal server met taakbeheer.

Hoeveel mensen staan er gemiddeld ingelogd op je terminal server? Zie je vreemde meldingen in je logfiles? (eventvwr).

Afas heeft trouwens ook een eigen plugin voor Office, Profit Office Connector (POC). Heb je hier de laatste versie van draaien? Ik weet toevallig uit eigen ervaring dat de versie van slechts een aantal weken terug buggy was; Excel 2013 (ik ben bezig met een migratieplan/testserver van onze omgeving naar Office 2013) crashte bij mij ook direct bij het openen van Excel 2013. Dit is opgelost in de meest recente versie van POC. In het configuratiescherm kun je het exacte versienummer zien van POC. Versie 2.9.600.300 is buggy; In versie 2.9.600.600 zijn de Excel 2013 crashes in ieder geval opgelost.

Verder denk ik trouwens dat de registry instellingen aangegeven door SirDarkAngel je probleem op gaat lossen; Ook wij hadden in het begin van ons nieuw RDS farm last van een hoge cpu usage op onze terminal server, welke werd veroorzaakt door Acrobat Reader. Nadat een gebruiker Acrobat Reader had afgesloten bleef deze op de achtergrond draaien op de server met een vrij hoog cpu. Log maar eens met een terminal server user in, open Acrobat Reader en sluit hem vervolgens af met het kruisje. Als het goed is, zie je bij taakbeheer dat het proces (AcroRd32.exe) van Acrobat Reader dan niet afgesloten is.

Er zijn in ieder geval genoeg blogjes over het probleem te vinden:

• Settings to Help Reduce Adobe Reader CPU Usage
• Adobe Reader X (AcroRd32.exe) process keeps using high cpu
• AcroRd32.exe hangs with high CPU usage when closing Adobe Reader

[ Voor 46% gewijzigd door FREAKJAM op 20-02-2015 00:13 ]