rep_srv causing high cpu

that did it. how can i avoid this issue if the target server becomes available? won't it just happen again?

sorry..... if the target server becomes UNavailable.

This is the way Replistor is designed... if the system cannot replicate to the target it has to be able to queue the changes being made to the file system until the target is unavailable, but sometimes when this condition occurs (particularly if you have quite a lot of changes taking place on your source server) the system becomes a bit overwhelmed!

If you do know that your target system will be offline for some reason then disable mirroring and forwarding and when it comes back run a sync again and put your mirroring and forwarding back. If not your system will just queue up many OC$ files and unless you have a system which does not change much it can be a difficult situation to get out of.

I guess an additional explanation will help here...

Replistor captures changes made to your file system and writes these file system changes both on the original and the target disk. In order to maintain integrity it has to apply these changes in the same order.

In normal operation Replistor will use a reserved part of memory called the kernel cache to capture these changes prior to them being forwarded to the target system. If however changes take place faster than the data can be forwarded (in this instance the target system is not accepting any data) then Replistor places this data in temporary OC$. Once it can forward the data it then reads the data from the OC$ on disk and continues to read OC$ files until they are all gone (in order to ensure data is being updated in order) at which time it will then resume using the kernel cache again. If you do get into a situation where you have a lot of these files build up all your changes rather than just pass through memory are being both written to local disk, then read, which is not the most efficient use of your processor.