Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Vraag


  • michaelbar
  • Registratie: april 2008
  • Laatst online: 16-02 17:30
Beste mede Tweakers,

Ik maak al langere tijd gebruik van de 'Data Deduplication' van Windows Server 2012 R2 op 2 servers, en heb al langere tijd het vermoede dat het niet goed werkt op 1 van die 2. Laten we de werkende :) noemen, en de niet werkende :(.

Mijn vermoede was laatst bevestigd doordat ik een hele grote map (met software builds) van de :) server, syncde naar de :(, op de :) server is deze map zo een 19 GB, terwijl er ca 1 TB aan data in zit, maar op de :( server is die map niet 19 GB, maar die daadwerkelijke 1 TB. Zo lijkt het alsof data dedupe er niks mee heeft gedaan (ook na de wacht periode van 3 dagen).

Het is identieke Dell hardware, en de RAID is aan beide kanten op de zelfde manier opgezet, dus ook de cluster sizes voor de volumes in Windows.

Wat kan er dus mis zijn?

Overigens heb ik al geprobeerd om talloze commandos uit te voeren zoals ik heb gelezen op internet, dat waren commandos die te maken hadden met handmatige 'optimalisatie' runs en 'scrubbing' runs, zowel de 'volledige' als 'niet-volledige' dmv. de -full flags. Maar niks blijkt te werken.

Op die builds na, zitten er ook talloze 'full-system-image' windows server backups op, die zouden ook flink kleiner moeten zijn aan de hand van data dedupe, maar ook dat werkt niet (dat is waar mijn oorspronkelijke idee vandaan kwam dat data dedupe op server :( het niet deed). Dit heb ik ook kunnen bevestigen door een andere (kleinere) build map te kopieren van :( naar :), en op :) wordt deze netjes kleiner gemaakt (ik moet zeggen dat ik net pas op kwam om dit te testen -- bij het schrijven van deze post -- dus nu weet absoluut en zeker dat er iets niet pluis is).

Er is genoeg ruimte om een data-dedupe terug te draaien, en deze weer aan te zetten, dus is dat een optie en zodoende de beste uitkomst, of heeft iemand anders nog ideeen?

Zie screenshots voor meer info.

Alvorens hartelijk dank allen :)

Met vriendelijke groeten,

Michael Barton





Beste antwoord (via rens-br op 12-02-2018 11:19)


  • michaelbar
  • Registratie: april 2008
  • Laatst online: 16-02 17:30
Ik ben er intussen achter dat het door een gebrek aan RAM geheugen komt.

Vooralsnog bedankt allen.

Met vriendelijke groeten,

Michael Barton

Alle reacties


  • Gomez12
  • Registratie: maart 2001
  • Nu online
Is het niet simpelweg de sync die je deduplication om zeep helpt.

De-duplication moet over het algemeen onzichtbaar zijn, oftewel elk synch programma zal denken dat er wel 19GB aan data in staat en dus ook 19GB synchen, waarna je "foute" server wellicht weer gaat de-dupliceren. Waarna je synch weer wijzigingen ziet en wellicht opnieuw gaat synchen?

Of omgekeerd, je synch-software ziet niets van de de-duplication en ziet enkel maar wat kleine bestandjes (waarvan in de ntfs metadata staat dat het gededuped is), je synch software synched alleen maar de kleine bestandjes en niet de ntfs-metadata en dan houd je dus maar 1 TB over.

Alhoewel ik wel moet zeggen dat ik het volgende niet echt kan volgen, ik zie niet waarom de dedup op :( niet zou werken. Die is of wel gedaan of de metadata is niet meegekomen, maar je hebt nu feitelijk 1TB aan data op :) en op :( dat lijkt me dus gewoon te kloppen, alleen je metadata klopt niet op server :(
quote:
michaelbar schreef op donderdag 1 februari 2018 @ 13:00:
Mijn vermoede was laatst bevestigd doordat ik een hele grote map (met software builds) van de :) server, syncde naar de :(, op de :) server is deze map zo een 19 GB, terwijl er ca 1 TB aan data in zit, maar op de :( server is die map niet 19 GB, maar die daadwerkelijke 1 TB. Zo lijkt het alsof data dedupe er niks mee heeft gedaan (ook na de wacht periode van 3 dagen).

  • michaelbar
  • Registratie: april 2008
  • Laatst online: 16-02 17:30
quote:
Gomez12 schreef op vrijdag 2 februari 2018 @ 01:40:
Is het niet simpelweg de sync die je deduplication om zeep helpt.

De-duplication moet over het algemeen onzichtbaar zijn, oftewel elk synch programma zal denken dat er wel 19GB aan data in staat en dus ook 19GB synchen, waarna je "foute" server wellicht weer gaat de-dupliceren. Waarna je synch weer wijzigingen ziet en wellicht opnieuw gaat synchen?

Of omgekeerd, je synch-software ziet niets van de de-duplication en ziet enkel maar wat kleine bestandjes (waarvan in de ntfs metadata staat dat het gededuped is), je synch software synched alleen maar de kleine bestandjes en niet de ntfs-metadata en dan houd je dus maar 1 TB over.

Alhoewel ik wel moet zeggen dat ik het volgende niet echt kan volgen, ik zie niet waarom de dedup op :( niet zou werken. Die is of wel gedaan of de metadata is niet meegekomen, maar je hebt nu feitelijk 1TB aan data op :) en op :( dat lijkt me dus gewoon te kloppen, alleen je metadata klopt niet op server :(


[...]
Beste Gomez,

Ik overwoog, wat jij net benoemde, toen der tijd alsnog toe te voegen, maar vond echter dat het dan evt. teveel info werd. De sync breekt de data-dedupe niet, dat weet ik daar er een andere build map vanuit :( naar :) wordt gekopieerd, en dat is al langere tijd zo, en dat gaat goed. Zie screenshots.

Dus kan ik zonder veel moeite de dedupe terug draaien? Het gaat om ca. 700 GB (dat is naar mijn weten redelijk snel weer terug gekopieert) mits dat dus een optie is. Of raad je aan om verder te debuggen?

Alvorens dank voor je reactie.

Server :( = master


Server :) = slave

Acties:
  • Beste antwoord
  • 0Henk 'm!

  • michaelbar
  • Registratie: april 2008
  • Laatst online: 16-02 17:30
Ik ben er intussen achter dat het door een gebrek aan RAM geheugen komt.

Vooralsnog bedankt allen.

Met vriendelijke groeten,

Michael Barton

  • bigfoot1942
  • Registratie: juni 2003
  • Niet online
you sure?
Ik heb wat ervaring met de W2016 dedupe functionaliteit op WIndows 10 (welke je met een hack kan inschakelen) en dat liep prima met 4GB ram.

Ik kan met voorstellen dat de sync tool de timestamps 'last written' en/of 'last touched' aanraakt waardoor deze niet gededupt worden - default dedup schedule werkt alleen op bestanden welke niet recent beschreven zijn - kijk eens naar de parameter
code:
1
-MinimumFileAgeDays


  • MrMonkE
  • Registratie: december 2009
  • Laatst online: 09:14

MrMonkE

rise up fallen fighters

quote:
michaelbar schreef op vrijdag 2 februari 2018 @ 12:09:
Ik ben er intussen achter dat het door een gebrek aan RAM geheugen komt.

Vooralsnog bedankt allen.

Met vriendelijke groeten,

Michael Barton
Als ik zo nieuwsgierig mag zijn, hoe ben je er achter gekomen?

Someone call 911. Quakelive murdered by Bethesda and Steam.


  • michaelbar
  • Registratie: april 2008
  • Laatst online: 16-02 17:30
Hi, allen. Ik ben er inderdaad achtergekomen doordat de Windows logs in event viewer, constant zeiden dat er meer ram dan was toegewezen noodzakelijk was. Toen ik de hoeveelheid ram die gebruikt mocht worden verhoogde, bleef het probleem zich voort doen. Uit eindelijk vond ik dmv. googlen dat er een registry setting was voor de low ram. Het systeem heeft 8 gig, het is een fileserver, dus had naar mijn weten ook niet veel nodig. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings\WlmMemoryOverPercentThreshold -> 1000. Ongetwijfeld zorgt dit voor vele malen meer paging, maar de zaken worden deduplicated. 1/3e schijfruimte vrijgemaakt :)
Pagina: 1


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*