Jarrett Peterson

We did a run a day or so after our last successful run (at 150 threads) which took approx 30 hours this time at 32 threads as recommended above and it's approx 24 hours in and 4% into the first pass after the read in so seems significantly slower

The server is sitting in compare at a single entry for hours but it's at 70% cpu. could our groups just be that big?

It seems like it must be something environmental and not sure why. We have another server that ran at 450 threads and made it past the same error point the new server fails at with 450 threads. Not sure how we determine why we have networking teamlooking. The major difference he saw was that one server sent 5-10gb of data during various packet capture periods and the other never went over 1

or if there's some extra debug we could do possibly?

we have the java memory set at 40/40 right now not sure if we need some specific gc settings

Entries identified so far: 73514000. An error occurred while attempting to identify the set of entries to examine in the source server: The attempt to search for applicable entries failed with result SearchResult(resultCode=84 (decoding error), diagnosticMessage='Invalid protocol op type 84 encountered in an LDAP message.', entriesReturned=0, referencesReturned=0). PS E:\unboundid-ldapsdk-6.0.6\unboundid-ldapsdk-6.0.6\tools>