Casper Admin - *Very* slow distribution point replication since 9.93 upgrade?

Taylor_Armstron
Valued Contributor

I can't definitively say this started with the upgrade, but certainly right around the same time frame.

A couple of weeks ago, if I went to synch my distribution points, it would basically scan through quickly, pop up a progress bar as it copied whatever new files had gone to my master DP, and then done.

Now, it appears to be checking every file. I added a small package (latest FileZilla, so less than 10mb), and kicked off replication. After 40+ minutes, it has made it through my list in alphabetical order to "File OK - Install OS X El Capital.InstallESD.dmg". Going through each and every package, apparently verifying it. Seeing a fair bit of network traffic, seems like it may be validating checksums or something like that, but at this rate it is going to take me over an hour to replicate a 10mb file... and it has done this each of the last 3-4 times I've attempted to replicate recently.

FWIW, my master DP is an AFP share, I'm replicating to a SMB volume. Roughly 70gb of packages total on the share (yes, I need to do some housekeeping, but it does add up quickly).

Anyone else seeing similar issues before I dive too far down this rabbit hole?

9 REPLIES 9

mpermann
Valued Contributor II

@Taylor.Armstrong did the Replication preference get changed? If you look in Casper Admin -> Preferences -> Replication what setting are you on?

Taylor_Armstron
Valued Contributor

Thanks @mpermann .

No change that I'm aware of - setting is on Checksum.

FWIW, last replication job finally finished, so just as a test I hit "replicate" again, and immediately started over with my Acrobat packages, now Adobe Air... meanwhile I'm showing a steady flood of network traffic in Activity Monitor.

I suppose I could change the preference to File Size or Mod. Date, but I've never changed it since our jump start, and only seen the dramatic change in speed within the past couple of weeks.

May
Contributor III

I had a similar issue with replication where it would want to re-sync random items that had already synced previously, i changed the sync setting to modification date and this stopped it re-syncing the items, (after i changed the setting it needed to do a full re-sync but after that it was ok)

It was also helpful as i sometimes copy the local repository to a Thunderbolt drive so i can copy it to another machine rather than re-syncing it all down again.

Taylor_Armstron
Valued Contributor

FWIW, did some comparisons. Again, I've only seen this drastic spike in time over the past couple of weeks (loosely correlates to when we did the 9.93 upgrade, but I'm not sure that they're related).

With Replication set to:
Checksum: 48 minutes
File Modification timestamp: 38 seconds
Size: 28 seconds.

Pretty drastic spread there. FWIW, all packages are indexed, with checksums calculated as far as I can see in Casper admin.

mpermann
Valued Contributor II

@Taylor.Armstrong you should log a support request with your TAM. I'd be interested to hear whether it's a bug with Casper Admin or something else.

Taylor_Armstron
Valued Contributor

Will do @mpermann .. just wanted to see if anyone else was seeing similar behavior before I tackled it.

anniwayy
New Contributor III

@Taylor.Armstrong I have seen similar issues with SMB shares and casper admin sync. it resync packages again and again: Replication preference is set to filesize. and when i check the DPs i actually see different filesizes for the same package. also the date of the package shows 2.1.1980. i am kind of lost to why this is happening.

dstranathan
Valued Contributor II

I'm noticing this behavior for the first time in 9.93. Its syncing VERY slow. It may take all morining to sync my ~50 packages/images.

Looks like my Casper Admin 9.93 is set to Checksum. I don't recall if I set that manually or not. What is the JAMF default setting?

dgreening
Valued Contributor II

We kicked Admin out of bed a LONG time ago for replication duties out to our Mac Minis. Carbon Copy Cloner has been excellent. Not helpful on this issue, but just throwing it out there.