kolin wrote:
Yes, it's dedup and compression enabled, and 500MB/s it's the limit that we found experimentally, at that limit all other volumes not affected with big bulk writes on that VV.
Cpu load not higher than 50%,might that be due dedup slowness?
Are you looking at total CPU or per core? Not everything multithreads perfectly.
Also, that 500MB/s limit... Did you account for the following bits in the works that led to that number:
1. One frontend read IO equals one backend IO. (frontend is host ports, backend is SSDs)
2. One frontend write IO equals 4 backend IOs with RAID5 and ~6 1/2 backend IOs with RAID6
3. With dedupe, one frontend write IO that dedupes equals one backend IO (read to do block compare)
4. With dedupe, one frontend write IO that doesn't dedupe = one frontend write IO without dedupe.
5. 500MB/s with 4kB IO size = 125.000 IOPS, 500MB/s with 64kB IO size = ~8.000 IOPS
Considering that you don't measure the read/write ratio, you can't define dedupe hit ratio and you don't know if your limit is bandwidth or IOPS (or a combination) .... setting a max bandwidth sounds pretty risky.... I would probably rather use latency goals or similar to priortize everything else with the limited information provided here.