Toon posts:

Vreemd snelheidsprobleem met Windows2003 server

Pagina: 1
Acties:

Verwijderd

Topicstarter
Vreemd snelheidsprobleem met Windows 2003 server

Ik zoek een verklaring voor het volgende vreemde probleem dat ik ondervind met onze Windows 2003 server. De situatie die hieronder beschreven wordt, doet zich altijd voor, dus ook wanneer de server volledig onbelast is.

Als ik één bestand van 200MB van een werkstation naar de server kopier, dan duurt dat +/- 40seconden. Als ik een bestand van 200MB van de server naar een werkstation kopieert duurt dat ook +/- 40 seconden...

Als ik 100 bestanden van 2MB van de server naar een werkstation kopieer, dan duurt dat dat ook ongeveer +/-40 seconden. Als ik 100 bestanden van 2MB van een workstation naar de server kopieer dan duurt dat +/- 170 seconden.

Sterker nog: als ik 100 bestandjes van +/- 4K van de server naar een workstation kopieer, dan duurt dan +/- 4 seconden. Als ik diezelfde 100 bestandjes van een workstation naar de server kopieer, dan duurt dat 2 minuten.

Ik heb de indruk dat van zodra er informatie van een workstation naar de server wordt geschreven, de initialisatie (of hoe je dat ook noemt) abnormaal lang duurt (ongeveer iets minder dan een seconde) voor de datatransfer werkelijk start en dit voor elk bestand opnieuw. Bij grote bestanden valt dat niet op omdat eenmaal de transfer op gang is, alles aan de normale snelheid verloopt. Indien je echter zeer veel kleinere bestanden kopieert, dan wordt dit soms onwerkbaar omdat er per bestand een 'initialisatietijd' nodig is van +/- 1 seconde. Als je 120 kleine bestandjes kopieert, die eigenlijk op enkele seconden zouden moeten zijn overgezet, zit je dus toch twee minuten te wachten. Soms moeten wij echt duizenden kleine bestanden overzetten (kopieren) naar de server, en dan loopt dat op tot verschillende uren wachten.
Het vreemde is dat dit enkel gebeurt wanneer informatie wordt gekopieerd van een workstation naar de server en niet wanneer het verkeer in de ander richting loopt (van de server naar het workstation).

Is er iemand die hier enige verklaring of oplossing voor heeft ?

  • GrimaceODespair
  • Registratie: December 2002
  • Laatst online: 08-05 14:44

GrimaceODespair

eens een tettenman, altijd ...

Heb je enige vorm van raid?

Wij onderbreken deze thread voor reclame:
http://kalders.be


Verwijderd

Topicstarter
Ja, de dataschijf draait in mirror mode.
Raidcontroller (Sata) zit onboard op het Intel serverboard...

  • DaRealRenzel
  • Registratie: November 2000
  • Laatst online: 16:25

DaRealRenzel

Overtuigd Dipsomaan

Is eigenlijk best redelijk te verklaren.

(wil wel effe weten welk OS je op je Client draait).

Als je 100 bestanden naar de Server kopieert, moet de Server voor elk bestand dat je kopieert checken of jij op die plek wel mag schrijven, zo ja, een file handle openen etc. etc. Dan aan de schijf vragen om schrijfruimte (die defragmented kan zijn), blok zoeken ed.

Op je Client hoeft de PC alleen in de local SAM te kijken (niet in AD). Op de Serve rmoet de Server echter bij elke bestandsopening in de AD kijken wie jij bent.

Zelfde issue treedt op bij Backup, backup van 1000 kleine files van 1 MB duurt veel langer dan 1 file van 1 GB.

Nothing is a problem once you've debugged the code


Verwijderd

Topicstarter
DaRealRenzel schreef op dinsdag 25 januari 2005 @ 17:54:
Is eigenlijk best redelijk te verklaren.

(wil wel effe weten welk OS je op je Client draait).
Client: Windows XP Pro, SP1
Als je 100 bestanden naar de Server kopieert, moet de Server voor elk bestand dat je kopieert checken of jij op die plek wel mag schrijven, zo ja, een file handle openen etc. etc. Dan aan de schijf vragen om schrijfruimte (die defragmented kan zijn), blok zoeken ed.

Op je Client hoeft de PC alleen in de local SAM te kijken (niet in AD). Op de Serve rmoet de Server echter bij elke bestandsopening in de AD kijken wie jij bent.

Zelfde issue treedt op bij Backup, backup van 1000 kleine files van 1 MB duurt veel langer dan 1 file van 1 GB.
Bedoel je dan dat dit probleem inherent is aan Active Directory ? Is hier geen weg rond ?
Trouwens ik kan nog begrijpen dat de server telkens in AD moet gaan kijken voor de rechten, maar dat dit 1seconde per bestand moet duren, dat lijkt mij zeer lang.
En waarom gebeurt het dan niet in de andere richting. Telkens je een bestand opent op de server om te lezen (kopieren naar workstation dus), moet de server toch ook in AD gaan kijken of je wel de toestemming hebt om die bestanden te lezen ?

Op deze manier kom je voor totaal onwerkbare situtaties te staan: zo wilde ik een email folder kopieren (duizenden kleine bestandjes) van een workstation naar de server. Dat ging gewoon niet, want dat nam ettelijke uren in beslag, terwijl diezelfde operatie op onze oude NT4 server op enkele minuten geklaard was.

Kan iemand trouwens dezelfde test eens uitvoeren: een 100 -tal kleine (4KB) bestandjes kopieren van een workstation naar een Windows 2003 server. En dan ook in de andere richting en mij even laten weten of daar ook zo'n groot snelheidsverschil op zit ?

  • DaRealRenzel
  • Registratie: November 2000
  • Laatst online: 16:25

DaRealRenzel

Overtuigd Dipsomaan

Verwijderd schreef op dinsdag 25 januari 2005 @ 18:12:


En waarom gebeurt het dan niet in de andere richting. Telkens je een bestand opent op de server om te lezen (kopieren naar workstation dus), moet de server toch ook in AD gaan kijken of je wel de toestemming hebt om die bestanden te lezen ?
Dat is dus niet het geval. Als je een bestand leest, zal de Server slechts aan de hand van het bestand bepalen of je leesrechten hebt. Als je al in de folder kunt komen heb je in principe al leesrechten, dus hoeft slechts op bestandsniveau bepaald te worden of je SID leesrechten heeft. Als het bestand zelf geen extra ACL heeft, mag je gewoon lezen.

Voor schrijven is dat wat anders, zoals ik al eerder aangaf.

Het zou echter wel kunnen dat je toch ergens een configuratiefoutje hebt. Bijv. dat je Write actie eerst een ACK moet hebben van de hardware vooraleer de Client een 'actie successvol' terug krijgt. Dat kan e.e.a. flink vertragen (vooral als je grote SATA schijven gebruikt).

Heb zelf ff een testje uitgevoerd met een aantal MP3's (ca 2 MB per bestand) en die gaan beide kanten even snel op.

[ Voor 7% gewijzigd door DaRealRenzel op 25-01-2005 20:37 ]

Nothing is a problem once you've debugged the code


Verwijderd

Topicstarter
DaRealRenzel schreef op dinsdag 25 januari 2005 @ 20:36:
[...]

Het zou echter wel kunnen dat je toch ergens een configuratiefoutje hebt. Bijv. dat je Write actie eerst een ACK moet hebben van de hardware vooraleer de Client een 'actie successvol' terug krijgt. Dat kan e.e.a. flink vertragen (vooral als je grote SATA schijven gebruikt).
Waar kan ik dat instellen of controleren ?

  • DaRealRenzel
  • Registratie: November 2000
  • Laatst online: 16:25

DaRealRenzel

Overtuigd Dipsomaan

Zoek eens in de Microsoft Knoledgebase naar 'Opportunistic Locking'
Kijk in de properties van je disk / volumes naar aprameters als 'Write Combining', 'Write Caching' etc.

Is je RAID controller trouwens ook Caching ? ZO nee, dan kan dat je probleem veroorzaken. Het kan nl. zo zijn dat de controller van beide disks een 'Write OK' moet hebben gehad alvorens de controller aan het OS terugmeldt dat de actie geslaagd is. Effectief daaalt dan je 'Write' performance.

Check dus eens de settings voor je disks, je controller etc. etc.

Nothing is a problem once you've debugged the code


Verwijderd

Topicstarter
Heb net even iets nieuw geprobeerd:
Naast de dataschijf die in raid mirror mode werkt zit er ook nog een extra schijf in de server die niet in raid mode werkt. Ik heb daar even hetzelfde geprobeerd en dat geeft net hetzelfde probleem, dus ik denk niet dat het iets met de raid controller te maken heeft.

Trouwens, wanneer ik gewoon bestanden wil wissen van de server, gebeurt net hetzelfde: als ik 100 kleine bestandjes tegelijk selecteer en deze wis, dan duurt dat bijna twee volle minuten voor de gebeurt is (wat tergend traag is). Je ziet hem dan per seconde 1 bestand wissen.

  • redfoxert
  • Registratie: December 2000
  • Niet online
Heb je toevallig nog een virusscanner draaien op die server ? Eentje die een on-access scanner geactiveerd heeft. Dit wil namelijk ook nogal eens heel erg vertragend werken, zeker in combinatie met de LSASS.exe. Moet je maar eens op letten, die zal behoorlijk staan stampen wanneer je files aanspreekt. Wat dat ding doet kan je op de knowledge base van Microsoft opzoeken.

https://discord.com/invite/tweakers


Verwijderd

Topicstarter
Toch niet, er draait geen virusscanner.

Verwijderd

Topicstarter
Ik heb hier net de oorzaak van het probleem gevonden denk ik, althans die beschrijving voor een server 2000 probleem is identiek aan wat ik hier vaststel. Ik heb het met Xcopy geprobeerd, en inderdaad, dan heb je die delay niet. Tenzij je tegelijk met Xcopy ook een Windows Explorer venster naar die share hebt openstaan, dan heb je de delay weer wel. Ik vind het echt wel bizar dat ze dit probleem nog steeds niet hebben opgelost in Server 2003.
Aangezien wij maar 1 server hebben die dus ook Domaincontroller is, kan ik de share niet naar een andere server verplaatsen. Voor zover ik kan zien is er geen oplossing voor dit probleem, buiten met fundamentele netwerkparameters te gaan knoeien en daar voel ik me nu niet meteen toe geroepen.
De link naar het betreffende MS Knowledgebase artikel is::
http://support.microsoft.com/default.aspx?scid=kb;en-us;321098

Als iemand nog een andere suggestie heeft dan hoor ik het graag....

  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

Verwijderd schreef op dinsdag 25 januari 2005 @ 21:22:
... Voor zover ik kan zien is er geen oplossing voor dit probleem, buiten met fundamentele netwerkparameters te gaan knoeien en daar voel ik me nu niet meteen toe geroepen...
Als het voor jou zo belangrijk is omhonderden bestanden te kopiëren dan moet je of die TcpDelAckTicks op 0 zetten of je moet ze via xcopy of robocopy kopiëren of je pakt ze met WinZip in één groot bestand

QnJhaGlld2FoaWV3YQ==


  • richard_kraal
  • Registratie: September 2001
  • Laatst online: 24-03-2025
let op 2 dingenn

-SMB signing, dat maakt copy acties vreselijk irritant, en dan bedoel ik echt HEEEL irritant

-Raid controller, cheap ass raid controllers zijn gewoon altijd traag, normale hebben alleen read cache, en is schrijven dus traag, dure raid controllers hebben read/write cache, zowel lezen als schrijven snel.


howto disable SMB signing

 Edit de GPO van de domain controllers, computer config -> windows settings -> security settings -> local policies -> security options. Verander de volgende settings:

o Domain member: Digitally encrypt or sign secure channel data (always) -> Disabled
o Domain member: Digitally encrypt secure channel data (when possible) -> Disabled
o Domain member: Digitally sign secure channel data (when possible) -> Disabled
o Microsoft network server: Digitally sign communications (always) -> Disabled
o Microsoft network client: Digitally sign communications (if server agrees) -> Disabled
o Microsoft network server: Digitally sign communications (always) -> Disabled
o Microsoft network server: Digitally sign communications (if client agrees) -> Disabled
Pagina: 1