[win2008] Kleine files kopiëren is traag

[_Thanatos_]

Windows 2008 x64 met SP1 is de server en de client is Windows 7 x64 SP1.

Als ik relatief kleine files ga kopiëren, van zeg 1MB groot, dan zie ik dat de server af en toe even wacht tussen de files, wat de effectieve doorvoersnelheid drastisch omlaag trekt. Delays dus.

De CPU van beide is ergens rond de 50% op één van de cores. Server heeft dualcore dus doet 25% en client is quadcore en zit daarmee rond de 10%. En dat is hoog ingeschat. De harddisks van beide zijn bijna idle, alleen als tussen de delays door wat wordt geschreven/gelezen doen ze wat. Ook het geheugen is plenty beschikbaar op beide.

Server heeft een 3ware 9650SE controller met daaraan 5x2TB in RAID5. De laatste keer dat ik het heb kunnen meten, trok die zomaar 200MB/s. Met iperf heb ik ook een meting gedaan. Op de server opgestart met default options, en op de client:

code:

M:\>iperf -c 192.168.10.1
------------------------------------------------------------
Client connecting to 192.168.10.1, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 192.168.10.13 port 58873 connected with 192.168.10.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[156]  0.0-10.0 sec   348 MBytes   292 Mbits/sec

M:\>iperf -c 192.168.10.1 -l 100K
------------------------------------------------------------
Client connecting to 192.168.10.1, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 192.168.10.13 port 58874 connected with 192.168.10.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[156]  0.0-10.0 sec   997 MBytes   836 Mbits/sec

Ik weet niet wat ik hiervan moet denken... Het is wel reproduceerbaar, dat met en zonder "-l 100K", dat geeft iedere keer rond de 300Mb/s en rond de 850Mb/s.

Server en client zijn dus allebei gigabit, en ik denk dat deze 836Mb/s wel aangeeft dat de netwerkkaarten een prima snelheid kunnen halen. Ik *denk* dus daar ik daar niet hoef te zoeken naar een oplossing. Wel zou het kunnen zijn dat filesharing op de eerst gehaalde snelheid doet en daar dus wat parameters niet goed staan, maar ik zou bij god niet weten waar ik dat moet, uhm, doen.

Verder heeft server geen antivirus, geen firewall en geen andere software die inhaakt op netwerkverkeer. Client ook niet.

Wie helpt me verder?

[OK13]

Een heleboel kleine files kopieren duurt langer dan 1 groot bestand. Dat is normaal. Bij kleine bestanden moet er iedere keer een write sessie geopend worden en gesloten. Bij een groot bestand heb je dat niet.

Kortom het is normaal dat het met kleine bestanden allemaal wat langer duurt.

[_Thanatos_]

Dat klopt op zich wel, maar *deze* traagheid is zeker niet normaal. Soms staat ie 1~2 seconden helemaal *niets* te doen. Delays dus. Soms doet ie er 20 per seconde, en soms maar 2, zonder verschil in grootte. Dat klopt niet. Het zou op z'n allerminst consequent moeten zijn.

Bovendien had ik het over bestanden van zo'n 1MB, maar ditzelfde fenomeen blijft als de bestanden 5MB zijn, of zelfs 10MB.

[ Voor 21% gewijzigd door _Thanatos_ op 01-05-2011 19:17 ]

[degroot]

_Thanatos_ schreef op zondag 01 mei 2011 @ 19:16:
Bovendien had ik het over bestanden van zo'n 1MB, maar ditzelfde fenomeen blijft als de bestanden 5MB zijn, of zelfs 10MB.

Lijkt er dan dus toch weer op dat hij bij ieder bestand nieuwe sessions moet openen en dat gewoon de traagheid oplevert.

[_Thanatos_]

Niet bij ieder bestand. En het is niet gewoon! Ik heb het nooit eerder meegemaakt. Daarbij duurt het openen van een sessie toch geen 2 seconden? Kom op hey, m'n server is wel sneller dan dat.

Daarbij, heb ik gemerkt, verergert het effect exponentieel als er meer bestanden tegelijk gekopiëerd worden. 4 tegelijk en hij blijft rustig een minuut wachten. En dan doet ie weer 100 files, en dan weer es een minuutje niets.

[Razwer]

firmware van je controller al naar laatste versie gebracht? klinkt namelijk dat hij zn cache heel langzaam schrijft. kan een controller firmware issue zijn. let op dat als je firmware upgrade je vaak eerst je driver moet updaten.

[_H_G_]

_Thanatos_ schreef op zondag 01 mei 2011 @ 16:05:
De CPU van beide is ergens rond de 50% op één van de cores. Server heeft dualcore dus doet 25% en client is quadcore en zit daarmee rond de 10%. En dat is hoog ingeschat.

Dit getal zegt niet zo veel, zonder te weten wat er draait. Zover we weten kan het net zo goed je backup programma zijn die de HDDs bezig houdt (je zegt dat ze idle zijn, maar meet je met Performance Monitor of op gevoel?).

Verder kan je nog kijken of je raid gezond is. RAID5 performance zal redelijk instorten als ie aan het rebuilden is (en kan ook laaaang duren met 2TB schijven).

edit: ik snap je iperf opmerking trouwens niet. Was het de bedoeling om iperf te starten vanuit client en server en dat er een verschil was? Of bedoel je enkel het verschil i.v.m. die bufferlengte (al zou ik niet eens weten waarom je met 100k test).

[ Voor 21% gewijzigd door _H_G_ op 02-05-2011 09:15 ]

[alt-92]

Wat voor disken zijn dat?

[The Eagle]

Gebruik je windows explorer om te kopieren of een command line?
De eerste wil nogal eens wat vetraging opleveren ivm filerights etc.
Makkelijkste manier hiervoor:
Command line openen, drivemapping aanmaken en xcopy gebruiken.

[Verwijderd]

zitten er shortcuts naar obsolete paden tussen? heb hier een gelijkaardig probleem gehad, zelfs tijdens het openen van de mappenlijst was er zelfs een delay daardoor, vista/seven/server 2008 doen daar erg vies over... na verwijderen van de ghost shortcuts was de traagheid opgelost.

[_Thanatos_]

Het probleem duikt weer eens op, maar nu (ook) in een andere vorm. Het kopiëren van grote files geeft vaak ook grote delays. Delays van makkelijk een minuut soms. Het duurt niet een minuut om een verbinding op te zetten, en tijdens die minuut kan ik dan ook op normale snelheid via RDP inloggen op de server en kijken wat er aan de hand is. Maar niets: 0% CPU-verbruik, 0% HDD-belasting en bijna 0% netwerkbelasting.

Wat voor disken zijn dat?

Disken die met elkaar makkelijk een gigabit-verbinding voltrekken. Zowel up als down (niet tegelijk natuurlijk).

Gebruik je windows explorer om te kopieren of een command line?

Total Commander, en die checkt dat soort dingen niet. Bovendien is het geen browsing probleem, waar dat soort problemen juist voorkomen. Niet *tijdens* het kopiëren van dingen. Maar met explorer is er geen verschil bij mij.

zitten er shortcuts naar obsolete paden tussen?

Nope, geen shortcuts/symlinks/hardlinks in de directories die ik gebruik.

Ik heb nog even geprobeerd om alle "offload" achtige opties in de netwerkkaarten uit te zetten. En subjectief lijkt het wel te helpen voor de snelheid (lolwut? ik zou verwachten dat acceleratie de boel niet trager maakt?), maar de problemen met delays tijdens kopiëren, tussen files door en bij het browsen blijven. Minutenlang nog steeds soms. En een paar seconden mag, eens in het kwartier ofzo. Een paar seconden elke paar seconden is een kapot iets, en een minuut is gewoon achterlijk. Sorry dat ik zo bot klink, maar op internet wordt er vaak geroepen "dat is normaal", terwijl het juist hartstikke abnormaal is.

Ik heb ook geprobeerd de firewalls uit te zetten. Nou stonden ze dat al, maar nu de windows service ook uitgeknald. Ik las ergens dat netwerkverkeer *altijd* door de firewall heen gaat, ook voor verbindingen waarvoor de firewall uitstaat. Ja het voelt lekker schoon, maar het helpt geen zak

Iemand nog suggesties?

[elevator]

Heeft lokaal kopieeren ditzelfde probleem (dus van de server naar de server)?
Als je Resource Monitor opentrekt tijdens de gehele copieeractie, zie je dan verschil in je disk-performance tijdens de stalls (zowel queue length als throughput)?

Vermoedelijk heb je gewoon te maken met cache flushes van je raid controller - als dat kan zou je voor de grap je raid controller eens op 'write through' ipv 'write back' moeten zetten en zien of je performance dan niet stabieler is (dat heeft wel weer andere nadelen)

[Verwijderd]

Maak op de server eens een RAM disk aan en kopieer daar eens naartoe vanaf de client. Dan weet je meteen of het aan het (client of server) OS ligt of aan de I/O kaart (firmware, cache, RAID setup).

Als dat geen verschil maakt: Hoe is het netwerk opgezet? Wat voor kaarten zijn er in gebruik? Instelllingen hiervan? Gebruik je native drivers voor Win2008 en Win7? Koppel client en server eens middels een crossover kabel aan elkaar en opnieuw testen.

Zaken genoeg om te testen zou ik zo zeggen

[_Thanatos_]

Ik denk dat ik de oorzaak heb gevonden. Of een deel ervan. Nu nog de oplossing.

Ik merkte zojuist dat de bestanden die ik erheen ben wezen kopiëren, belachelijk hard fragmenteren. Een bestand van 300MB werd opgedeeld in 13.000 fragmenten (ja, dertien duizend, geen typfout dus)

Maar er is mééér dan voldoende aaneengeslote vrije ruimte op die schijf. Het is een softraid van 8TB met vervolgens 2 partities. Ongeveer 40% is in gebruik en de overige 60% is helemaal leeg (dwz zo goed als ononderbroken vrije blokken). Dat is met de defragger van Auslogics goed zichtbaar.

Maar waarom zouden bestanden zo onmenselijk keihard fragmenteren? Want dat bestand waar ik het over heb, is zeker niet de enige. Bijna alles wat ik ernaartoe kopiëer, fragmenteert zo. Dat heb ik nog nooit eerder gezien bij een netwerkschijf...

[_Thanatos_]

Iemand een idee over die fragmentatie? Dat hoort toch niet?

[_H_G_]

Weet niet veel van RAIDs, maar ik kan me voorstellen dat de kenners wat meer informatie nodig hebben. Zoals alignment, stripe size en of de RAID gezond is. Wat bedoel je eigenlijk met softraid? Je hebt toch een 9650SE?

(en tip: beantwoord andere vragen eens. Aantal van bovenstaande gasten weten wel waar ze het over hebben, maar zullen niet echt gemotiveerd zijn om nog te reageren als je niet aangeeft wat je met hun advies hebt gedaan).

[ Voor 33% gewijzigd door _H_G_ op 26-05-2011 08:36 ]

[Verwijderd]

_Thanatos_ schreef op zondag 15 mei 2011 @ 21:04:
[...]
Disken die met elkaar makkelijk een gigabit-verbinding voltrekken. Zowel up als down (niet tegelijk natuurlijk).

Goed antwoord. Jammer dat je niet gewoon zegt dat het om 5400 rpm SATA schijven gaat. Hint: er is een reden voor SAS schijven, die ondanks dat hun transferrate niet bijster veel hoger is tóch veel hogere performance leveren dan SATA schijven.

[_Thanatos_]

Jammer dat je niet gewoon zegt dat het om 5400 rpm SATA schijven gaat. Hint: er is een reden voor SAS schijven, die ondanks dat hun transferrate niet bijster veel hoger is tóch veel hogere performance leveren dan SATA schijven.

Nou zeg. Een beetje troosteloze reactie. Als je BMW niet meer wil lopen, ga je dan maar een Lambo kopen? Nee, die BMW moet ook gewoon snel gaan. En ATTO bewijst het:

Ik zei toch dat ie met het grootste gemak een gigabit-verbinding kan voltrekken. Zowel in writes als in reads. En mind you: dit probleem bestaat ook met grote bestanden, dus begint nu niet over seektimes. De harde schijven zijn gewoon dik in orde.

Wat bedoel je eigenlijk met softraid? Je hebt toch een 9650SE?

Die 9650SE doet RAID5 in hardware, maar deelt die array in stukken op voor de hypervisor (ESXi). Dit is "good practice" in ESXi i.c.m. volumes van >2TB en wordt ook overal als beste optie aangeraden. Je krijgt dan meerdere volumes die je in een VM weer samenvoegt dmv een softraid.

Maak op de server eens een RAM disk aan en kopieer daar eens naartoe vanaf de client.

RAM-disk gaat flitsend snel, want daarvoor is het RAM. Ik begrijp niet helemaal wat ik hiermee opschiet; het gaat om harde schijven, en die gedragen zich heel anders. Ik kan ook een andere harde schijf eraan hangen, dat is misschien realistischer. En waarempel: geen problemen van deze aard.

Heeft lokaal kopieeren ditzelfde probleem (dus van de server naar de server)?

Ja. Maar gek genoeg merk ik daarbij wel dat het alleen gebeurt op de partitie waar het nou juist om gaat. Een andere partitie geeft geen problemen, en kopiëert een dik vet bestand met een stabiele snelheid van zo'n 70MBps. Naar de partitie die wel problemen geeft, begint het goed, maar al snel komt de boel tot een grinding crawl waarbij de snelheid terugloopt tot minder dan 10MBps. Zelfde softraid, zelfde hardraid, zelfde fysieke schijven. Alleen een andere partitie. En ook nog es lokaal. Ra ra.

Partitie die geen problemen geeft = NTFS, 3.070.268 MB, 64K clusters
Partitie die wel problemen geeft = NTFS, 4.553.913 MB, 2K clusters
Beide geven geen problemen met een chkdsk/v.

Ik heb wel schijven gehad met clusters van 512 bytes... Dus dat zal de oorzaak toch niet kunnen zijn?

Na nog wat bestanden erheen pompen is weer eens duidelijk dat het toch echt niet aan de hardware ligt. bestanden worden ALLEMAAL opgedeeld in honderden zoniet duizenden fragmenten. Een bestand van slechts 6MB bestaat eventjes uit 1300 fragmenten, terwijl de volume zeker 2,5TB aan onafgebroken vrije ruimte heeft.

Net alsof je een vliegveld in de binnenstad probeert te wurmen, terwijl er iets verderop kilometers open ruimte is.

[ Voor 8% gewijzigd door _Thanatos_ op 28-05-2011 04:09 ]

[crizyz]

Nou zeg. Een beetje troosteloze reactie. Als je BMW niet meer wil lopen, ga je dan maar een Lambo kopen? Nee, die BMW moet ook gewoon snel gaan. En ATTO bewijst het:

offtopic:
Nee, maar als je vervolgens aan iemand vragen gaat stellen over die BMW en die vraagt wat voor een motor je er in hebt liggen, zeg je toch ook niet eentje die hard genoeg op moet kunnen trekken?

Ontopic: Overigens, heb je die schijf (waar die partitie op staat) op fouten/smart gecontroleerd? En dan bedoel ik niet met chkdsk, maar met iets als een HDTune? Aangezien chkdsk voor zover ik weet niet echt geweldig is om doodgaande harde schijven te detecteren.

Ik gooi maar een balletje op, weet nl niet of de smart info direct uitgelezen kan worden als de hdd aan een raid controller hangt (zelf geen raid ervaring).

[elevator]

_Thanatos_ schreef op zaterdag 28 mei 2011 @ 04:06:
Nou zeg. Een beetje troosteloze reactie. Als je BMW niet meer wil lopen, ga je dan maar een Lambo kopen?

Als mensen om informatie vragen is het gewoon erg handig om te reageren met die informatie, niet met jouw interpretatie

Die 9650SE doet RAID5 in hardware, maar deelt die array in stukken op voor de hypervisor (ESXi). Dit is "good practice" in ESXi i.c.m. volumes van >2TB en wordt ook overal als beste optie aangeraden. Je krijgt dan meerdere volumes die je in een VM weer samenvoegt dmv een softraid.

Je zei toch dat je OS Win2008R2 was, je hebt niets vermeld over ESXi in je topicstart?

Ja. Maar gek genoeg merk ik daarbij wel dat het alleen gebeurt op de partitie waar het nou juist om gaat. Een andere partitie geeft geen problemen, en kopiëert een dik vet bestand met een stabiele snelheid van zo'n 70MBps. Naar de partitie die wel problemen geeft, begint het goed, maar al snel komt de boel tot een grinding crawl waarbij de snelheid terugloopt tot minder dan 10MBps. Zelfde softraid, zelfde hardraid, zelfde fysieke schijven. Alleen een andere partitie. En ook nog es lokaal. Ra ra.

Aangezien je aangeeft dat er veel fragmentatie optreed - kan je eens met Sysinternals' contig kijken of je file echt zo gefragmenteerd is?

Daarnaast komt fragmentatie niet alleen van niet genoeg aansluitende vrije ruimte, maar ook door veel gelijktijdige I/O operaties.

Ik heb je al eerder gevraagd resource monitor open te trekken en te kijken of je daar informatie in zit, aangezien je de vraag om andere info daaruit en alle andere info van mensen ook vast gaat negeren ga ik hem niet eens stellen

[Verwijderd]

wat zijn de totale specs van je machine.
welke netwerk kaart heb je in esxi gekozen? de e1000 of de andere 2 vm opties?
verbaasd me dat niemand vraagt naar de totale specs maar blind gaan vragen onder het overzicht te hebben?
daarnaast waarom raid 5 en niet raid 10? de kosten van de 2tb schijven zelf lijkt mij het probleem niet gezien je sata gebruikt en geen 15k sas.

de delays komen omdat je hardware raid 5 nog een keer softraid over heen gooit.
raid 5 en kleine files is al geen monster, welke softraid instelling heb je gemaakt?
in dit soort gevallen kun je beter dfs gbruiken en je volumes koppelen dan softraid op hardware raid zetten.

[ Voor 150% gewijzigd door Verwijderd op 28-05-2011 09:25 ]

[elevator]

Verwijderd schreef op zaterdag 28 mei 2011 @ 09:03:
de delays komen omdat je hardware raid 5 nog een keer softraid over heen gooit.

Waar baseer je dat op? Softraid - en zeker striping - hoeft helemaal geen grote performance impact te hebben, sterker nog, er zijn genoeg aanwijzigingen dat software raid performanter is dan hardware raid (denk bv. aan ZFS)

in dit soort gevallen kun je beter dfs gbruiken en je volumes koppelen dan softraid op hardware raid zetten.

DFS? Gewoon mountpoints

[_Thanatos_]

Jamaar, het probleem zit em in de fragmentatie... Dat komt toch niet op hardware-niveau

Sorry maar als bestanden in duizenden fragmenten worden opgedeeld, dan is mij volledig duidelijk waarom het zo traag werkt. Dat zit em in het guest OS, en daarmee in het filesystem. En omdat één van de twee partities op de softraid het probleem niet heeft, ligt het ook niet aan de softraid.

Het zit em dus in het filesystem. Alles wat ernaast hangt, is dan toch niet relevant meer? Dus welke type harde schijven is niet relevant, want harde schijven zorgen niet voor fragmentatie. Netwerkkaarten zijn ook niet relevant, want ik kan het lokaal reproduceren. Raidcontroller is ook niet relevant, want maar 1 partitie geeft het probleem. Softraid-configuratie heel misschien. Iets met de stripe-size, maar die heb ik default gelaten (kan ik ergens opvragen wat die is?).

[Verwijderd]

_Thanatos_ schreef op zaterdag 28 mei 2011 @ 16:10:
Jamaar, het probleem zit em in de fragmentatie... Dat komt toch niet op hardware-niveau

Sorry maar als bestanden in duizenden fragmenten worden opgedeeld, dan is mij volledig duidelijk waarom het zo traag werkt. Dat zit em in het guest OS, en daarmee in het filesystem. En omdat één van de twee partities op de softraid het probleem niet heeft, ligt het ook niet aan de softraid.

Het zit em dus in het filesystem. Alles wat ernaast hangt, is dan toch niet relevant meer? Dus welke type harde schijven is niet relevant, want harde schijven zorgen niet voor fragmentatie. Netwerkkaarten zijn ook niet relevant, want ik kan het lokaal reproduceren. Raidcontroller is ook niet relevant, want maar 1 partitie geeft het probleem. Softraid-configuratie heel misschien. Iets met de stripe-size, maar die heb ik default gelaten (kan ik ergens opvragen wat die is?).

Kijk, we hebben natuulijk geen glazen bol, dus in principe weten we niks over je setup tenzij je het ons vertelt. Het feit dat je in de openingspost 'vergeet' te vermelden dat er virtualisatie in het spel is, vind ik vreemd.

Er worden hier een hele hoop tips gegeven die in mijn ogen perfect relevant kunnen zijn. Jij vindt misschien van niet, maar als je essentiële informatie niet vermeldt, is dat niet zo vreemd.

Kleine anekdote die ik onlangs meemaakte: Een ESX server (met in principe meer dan voldoende resources), en plots van de ene op de andere moment liepen geen enkele guest nog voor een meter (onmoemelijk traag, deadlocks, etc). Mix van besturingssystemen, dus niet echt een lijn in te trekken. Ik was natuulijk ook onmiddellijk aan hardwareproblemen aan het denken. Tot ik plots opmerkte dat ik 1 VM per ongeluk 512GB RAM had toegewezen ipv 512MB. Na dit gecorrigeerd te hebben, liep alles terug als een zonnetje.

offtopic:
Ik denk dat je hier nog weinig reacties gaat krijgen, want alle opmerkingen die hier geplaatst worden, negeer je en verder lijk je alleen een monoloog met jezelf te voeren. Misschien kan je dit beter in stilte doen.