Slow defrag, high CPU usage and low IO due to defraggler

[sArkar]

I have been noticing from last few days that my defraggler is malfunctioning a lot. Let me tell you first that I have a huge hard drive of some 1.5 TB with huge number of small files in it.

Now the issue is whenever I start to defrag, the first negative point is that it takes almost 1 second for it to defrag each individual file, while defragging is somehow using lot of CPU effectively pegging one core. Also the IO is too low. Please help me out; I am not aware of this issue completely as its happening the first time with me.

[BillieJ]

According to me slow file transfer due to the high CPU usage or CPU interruption could indicate the IDE controller in the operating in PIO mode or the hard drive pending failure. I would better suggest you to first check your driver’s SMART status with the help of the speccy or HD Tune and then looking into it that there is no such thing that is suspicious, I mean to say that the reallocated sector count should be greater than 0. And if possible also try to run the profiler on it.

[sArkar]

My dear I thing the driver is completely running fine. I have already ran procmon.exe and guess what, it looks like one of the defraggler’s threads that is actually pegging the CPU is somehow after each and every file doing a GET_VOLUME_BITMAP. Let me also tell you that almost all the CPU time is completely taken inside the defraggler64.exe code, i.e. it's not in kernel or other DLLs. But it still seems that there are two threads which can actually take turns attaching the core.

Also what i did was ran it under xperf tool and then I what I saw was that I was unable to get anything helpful out of xPerf due to lack of symbols.

[Alfons]

But it still seems that there are two threads which can actually take turns attaching the core.

I guess there is one thread that looks like to spend a large amount of time in looping through the items in the 'file types' dialog. Seems like it is doing it in an very much inefficient manner. the 'lock xadd' in the loop is actually causing the CPU to clean cache & sync in a tight loop. Maybe the thing is that it is getting called for every file on the disk, for all the types in the types dialog. I think moving the lock to a higher level will definitely be a good start.

[Gania]

Yeah in the other thread that is pegging the CPU is somehow loading thought the following list of file types. However it is a different piece of code, but anyhow it has got the dreaded lock in a tight loop:

000000013F63E819 jne 000000013F63E826
000000013F63E81B lea r12,[rdi-18h]
000000013F63E81F lock add dword ptr [rdi-8],1
000000013F63E824 jmp 000000013F63E866

[Abhiroopa]

As according to my knowledge, as same as your case on a large drive with huge number of small fragmented files the following code somehow approximately give you 0% CPU usage:

df64.exe e:

And the following pegs 1 core:

df64.exe e: /Large .arj 0 /Large .tar 0 /Large .rar 0 /Large .zip 0 /Large .cab 0 /Large .tar.gz 0 /Large .tgz 0 /Large .arj 0 /Large .lzh 0 /Large .7z 0 /Large .gzip 0 /Large .gz 0 /Large .uue 0 /Large .bz2 0 /Large .img 0 /Large .mig 0 /Large .mp3 0 /Large .wav 0 /Large .aiff 0 /Large .rm 0 /Large .ra 0 /Large .flac 0 /Large .bin 0 /Large .iso 0 /Large .mdf 0 /Large .dmg 0 /Large .vxd 0 /Large .avi 0 /Large .mkv 0 /Large .mpg 0 /Large .mov 0 /Large .mp4 0 /Large .m4v 0 /Large .mpeg 0 /Large .wmv 0 /Large .bup 0 /Large .ifo 0 /Large .vob 0 /Large .msi 0 /Large .msp 0 /Large .msu 0 /Large .wim 0

[KanthaBEN]

I am also having the same issue but with the most recent and the latest release of defraggler. In my case the defraggler approximates more than 1 day for defragmenting my 500 GB of drive. With this latest version I think I am facing an unwanted slowness which actually should not happen as we all know that the option of quick defrag looks to be more faster than the older version release.

I am not sure whether this is happening with the other 2.9 release but definitely I believe that it’s a bug and should be somehow fixed as soon as possible. Till now I have never seen a defrag application which is CPU-bound instead of io-bound.