This is not a complaint.
I'm very happy with 400MB/sec through a cheapXXXX power efficient system.
I'm trying to deduplicate some of my 10,000,000+ files.

Top reports spin (mostly on CPU0) up to 10%.
I'm curious which resource is being competed for.

If a waterfall graph would answer my question
any pointers to instructions would be gratefully taken.

Running 3 instances of
   find <a disk> -type f -exec cksum {} + > <resultfile>
each searching a different physical drive and resultfile is on
yet another physical drive.
CPU is AMD 5600G w/6 cores & 64MB

top says:
                                                  ---------
CPU00 states: 15.9% user,  0.0% nice,  5.5% sys,  3.4% spin,  3.0% intr, 72.1% idle CPU01 states: 16.8% user,  0.0% nice,  4.5% sys,  1.3% spin,  0.0% intr, 77.4% idle CPU02 states: 17.3% user,  0.0% nice,  5.9% sys,  0.5% spin,  0.0% intr, 76.3% idle CPU03 states: 11.9% user,  0.0% nice,  4.9% sys,  0.3% spin,  0.0% intr, 82.9% idle CPU04 states:  9.1% user,  0.0% nice,  2.4% sys,  0.5% spin,  0.0% intr, 88.1% idle CPU05 states:  5.5% user,  0.0% nice,  1.2% sys,  0.2% spin,  0.0% intr, 93.1% idle

iostat says:

     tty                sd2                 sd3 sd4                cpu
 tin tout  KB/t  t/s    MB/s   KB/t  t/s    MB/s   KB/t  t/s MB/s  us ni sy sp in id  519   89 64.00 2496  156.00  64.00 1991  124.44  64.00 2061 128.81  12  0  4  0  1 83  519  267 64.00 2551  159.44  64.00 2087  130.44  64.00 2142 133.88  13  0  4  1  0 82

Secondary question:
This scenario hits some transfer rate limit.
It's not obviously a chipset/memory system limit.
I think that combination can deliver above 1GB/sec to the SATA controller.
All of the drives can transfer at least 140MB/sec, some as high as 180.
I believe that sd3 and sd4 can transfer faster than sd2.
Is it likely that the kernel services interrupts, etc. in drive # order?
(Reading the Source doesn't give an obvious answer.
There are interactions with scheduling)

   thanks
   Geoff Steckel

Reply via email to