Ik heb een backup scriptje geklust dat dmv Rsync een hele hap files synchroniseert van een linux bak naar een windows bak. In huis ligt een 100MBit full duplex netwerk en tussen beide machines zit 1 switch.
Nu blijft de schrijf performance hangen op ongeveer 10-12MBit max, wat dus niet zo erg op schiet.
Ik ben wat gaan testen om te kijken waar het aan ligt, maar kom er niet echt uit.
De opstelling van mijn thuisnet is ongeveer als volgt:
Server (1ghz epia/debian) ---Switch(e-tech router/switch) ---Windows bak(XP/celeron 600/384MB)
\---Slaapkamercompu(2x 1GHz PIII/512MB/windows+linux)
De layout gooit de spaties hier weg zie ik, maar de slaapkamercompu hangt dus aan de switch.
-De server moet een backup van eigen data pushen naar Windows bak. De windows bak heeft 2 maxtor 20GB schijven die ALLEEN voor de backup gebruikt worden
-DMA etc staat overal aan
-De windows bak heeft een 3com 10/100MBit kaart die op zich prima werkt voor zover ik kan zien.
-Bij geen van de machines treedt een hoge processorbelasting op, alles blijft hangen binnen enkele tientallen procenten.
-Als ik met de slaapkamercompu in linux over NFS de share op de server mount en uit lees haal ik bijna de volle 100MBit via dezelfde switch, zowel lezen als schrijven.
-Als ik met de slaapkamercompu in windows dezelfde share mount (deze is ook gedeeld met samba) haal ik ook weer bijna 100Mbit
-Als ik vanuit windowsbak de data binnen trek haal ik 10-12MBit, net zoals bij de gepushte backup
-Als ik vanuit windowsbak data binnen trek over ftp (ook van de server) haal ik 20-25MBit, nu wel met volle processorbelasting. Dit met de aantekening dat de volumes waar de boel heengeschreven wordt NTFS geformatteerd zijn MET compressie.
Mijn conclusie is dus dat er *iets* mis is met de windows bak. Dat hij relatief hoge processorload heeft bij het compressen van 2 meg per seconde kan ik begrijpen, het is nu eenmaal een oud beestje. Maar bij het backuppen knijpt hij de boel af op 0.6-1MB per seconde zonder dat ik duidelijk kan aanwijzen waar een bottleneck zou kunnen liggen.
-De schijven ratelen niet hard, zijn bovendien ook volledig geleegd om uit te sluiten dat het aan fragmentatie zou kunnen liggen.
-Er is geen hoge processorbelasting
-Data van en naar de schijven verplaatsen binnen de compu gaat duidelijk vlotter dan over het net
-De 3com kaart heeft het in een andere machine ook altijd best goed gedaan.
-Mounten met cifs of smbfs maakt geen verschil
-Het uitzetten van compressie op een van de schijven maakt geen verschil
-Veel van de bestanden zijn relatief groot (1-2 MB komt veel voor), dus je zou ook niet verwachten dat het veel afgeknepen wordt doordat de bestanden klein zijn.
En op verzoek van GertJan
:
-Slaapkamercompu(XP)->Windowsbak: 30-35MBit
-Windowsbak-->Slaapkamercompu(XP): tot plm 50MBit
Beide NIET met volle processorbelasting
Waar kan het nog aan liggen?
Nu blijft de schrijf performance hangen op ongeveer 10-12MBit max, wat dus niet zo erg op schiet.
Ik ben wat gaan testen om te kijken waar het aan ligt, maar kom er niet echt uit.
De opstelling van mijn thuisnet is ongeveer als volgt:
Server (1ghz epia/debian) ---Switch(e-tech router/switch) ---Windows bak(XP/celeron 600/384MB)
\---Slaapkamercompu(2x 1GHz PIII/512MB/windows+linux)
De layout gooit de spaties hier weg zie ik, maar de slaapkamercompu hangt dus aan de switch.
-De server moet een backup van eigen data pushen naar Windows bak. De windows bak heeft 2 maxtor 20GB schijven die ALLEEN voor de backup gebruikt worden
-DMA etc staat overal aan
-De windows bak heeft een 3com 10/100MBit kaart die op zich prima werkt voor zover ik kan zien.
-Bij geen van de machines treedt een hoge processorbelasting op, alles blijft hangen binnen enkele tientallen procenten.
-Als ik met de slaapkamercompu in linux over NFS de share op de server mount en uit lees haal ik bijna de volle 100MBit via dezelfde switch, zowel lezen als schrijven.
-Als ik met de slaapkamercompu in windows dezelfde share mount (deze is ook gedeeld met samba) haal ik ook weer bijna 100Mbit
-Als ik vanuit windowsbak de data binnen trek haal ik 10-12MBit, net zoals bij de gepushte backup
-Als ik vanuit windowsbak data binnen trek over ftp (ook van de server) haal ik 20-25MBit, nu wel met volle processorbelasting. Dit met de aantekening dat de volumes waar de boel heengeschreven wordt NTFS geformatteerd zijn MET compressie.
Mijn conclusie is dus dat er *iets* mis is met de windows bak. Dat hij relatief hoge processorload heeft bij het compressen van 2 meg per seconde kan ik begrijpen, het is nu eenmaal een oud beestje. Maar bij het backuppen knijpt hij de boel af op 0.6-1MB per seconde zonder dat ik duidelijk kan aanwijzen waar een bottleneck zou kunnen liggen.
-De schijven ratelen niet hard, zijn bovendien ook volledig geleegd om uit te sluiten dat het aan fragmentatie zou kunnen liggen.
-Er is geen hoge processorbelasting
-Data van en naar de schijven verplaatsen binnen de compu gaat duidelijk vlotter dan over het net
-De 3com kaart heeft het in een andere machine ook altijd best goed gedaan.
-Mounten met cifs of smbfs maakt geen verschil
-Het uitzetten van compressie op een van de schijven maakt geen verschil
-Veel van de bestanden zijn relatief groot (1-2 MB komt veel voor), dus je zou ook niet verwachten dat het veel afgeknepen wordt doordat de bestanden klein zijn.
En op verzoek van GertJan
:-Slaapkamercompu(XP)->Windowsbak: 30-35MBit
-Windowsbak-->Slaapkamercompu(XP): tot plm 50MBit
Beide NIET met volle processorbelasting
Waar kan het nog aan liggen?
[ Voor 17% gewijzigd door VROEM! op 16-12-2005 10:20 ]
ieeeepppppp :P
:strip_exif()/u/37147/homerexcited.gif?f=community)