disParity » General Discussion

remove is very slow

(10 posts)
  1. ge
    Member

    is there any way the cpu overhead on remove can be reduced? it looks like the remove function is completely processor bound and very slow. on a 4 core machine it is pegged at 25% cpu. On a 6 core it is pegged at 16% cpu. this disk IO is under 10%. the time to remove a 100gb disk image is running into days on the 6 core machine. and if I reboot in between, it starts back at the beginning. If the cpu overhead could be reduce so the process was IO bound, we might see a 10 time increase in speed.

    Posted 8 months ago #
  2. Roland
    Roland

    The numbers you are reporting are bizarrely slow. On my relatively new 4 core machine (running Windows 7), the CPU usage of the disparity process as reported by Task Manager hovers at around 7% while processing deletes. This is with an 8 drive array. I'm honestly not sure why you are seeing such poor performance. 25% CPU means that it is completely maxing out 2 different threads, which doesn't make sense. Processing deleted files is slower than adds because more data must be read from disk, but it should still be disk IO bound overall.

    I just removed 14 GB worth of files and it took 3 minutes 20 seconds. At that speed 100gb would take about 24 minutes. For it to take days, something strange must be going on.

    Any guesses as to why your systems would be so different from mine?

    Posted 8 months ago #
  3. ge
    Member

    Thanks Roland.

    That gives me a place to start. I was wondering if it was in the XOR logic, if you were perhaps going a byte at a time, rather than using he full register size.

    I'm seeing the same thing on two machines. One AMD one Intel. The AMD is 6 core with clock at 2.8, and the Intel is 4 core with clock at 4.2.

    The most obvious suspicion is that I going through mount points, using network shares so that the drive bender structure does not increase the path/file name length. This would increase the processing somewhat, but I'm surprised it could be that much.

    I get very high I/O bandwidth on some of the DB operations. Upwards of 400 MB/s across the array as reported by resource monitor. I write down which ones next time as I'm testing, so it doesn't appear to be the IO subsystem.

    However, during removes I rarely if ever see much above 10 MB/s. The IO pattern on the parity drive is consistent, a very sharp sawtooth sort of pattern. None of the drives are anywhere near 100% utlization, but the cpu's are 100% maxed out on a single core.

    Posted 8 months ago #
  4. ge
    Member

    correction: I'm getting very high IO bandwidth on some of the disparity operations. upwards of 400 MB/s.

    Posted 8 months ago #
  5. Roland
    Roland

    I doubt it's the XOR operation. That is done 64 bits at a time and modern CPUs barely break a sweat doing that. The only other potential culprits are either some kind of odd CPU overhead in your disk I/O, or else the UI updating itself during the operation. That's all that is going on during the update.

    Posted 8 months ago #
  6. ge
    Member

    Hi Roland,

    It is something to do with the mount points I used to get around the 260 path limit. I Installed snapraid and defined the disks normally, using drive letters. I benchmarked before and after, while leaving everything else unchanged. 20 MB/sec before 400 MB/sec after.

    I like disparity a lot more, but from what I can see the oath limitations are a show stopper unless I find another method, because diskbender used a GUID as a directory name to identify and contain the array.

    Any thoughts how else I might get around the path limits? The problem is that on the pool drive:

    d:\a.b

    appears as

    E:\{CCE2AB08-E576-47B6-94DD-6F18FD86A511}\a.b

    on the individual drives, which means that lots of file names are too long for disparity when using a drivebender pool. thanks

    Posted 8 months ago #
  7. ge
    Member

    ps: the 20mb and 400mb were both using snapraid. before = network shares via mount points. after = direct using disk d1 = E:\{CCE2AB08-E576-47B6-94DD-6F18FD86A511}\

    Posted 8 months ago #
  8. Roland
    Roland

    Yeah, the .NET/Windows path limit is a major pain. Fixing it in disParity itself would require a substantial rewrite, not something I'm able to contemplate right now.

    How are you currently creating the mount points? Do they have to be done as network shares?

    What happens if you just map the longer folder names to a new drive letter, using the subst command?

    Posted 8 months ago #
  9. ge
    Member

    subst is next on my list.

    Posted 8 months ago #
  10. ge
    Member

    no joy Roland. I tried many different approaches but was unable to improve significantly on performance. I'll check back time to time but for now it looks like there is no reasonable way around the path limit when using drive bender.

    Posted 8 months ago #

RSS feed for this topic

Reply

You must log in to post.