|
Description
|
> With our Oracle test, we good quite a good boost (maybe 20%)
> by reducing the vq_max_pending from 35 to 5. The reason is
> that when the pool syncs the large max pending causes the I/O
> latency to me somewhat high and that impacts the reads. In
> a DB environment, we are not BW limited at all and so we can
> afford lower vq_max_pending. However, when a read shows up
> during a pool sync, it still must wait for a I/O slot to free
> up. So it will basically wait for part of one I/O latency to
> free up a slot, then occupy it's own slot. I guess this inflates
> the latency by 50%.
>
> I think we would gain some performance if we had a few
> reserved slots for reads and wouldn't have to wait for a
> slot to free up.
Bill M:
> Yeah, that makes sense. I think we could easily implement it by
> allowing reads to over-issue vq_max_pending by some fixed amount
> (vq_min_reads?). Does that seem acceptable?
>
Roch:
I kind of hovered toward
having slots per priority levels; the issue affects
zil commit in the same way as reads. Also the time-base
priority scheme is subject to breakdowns and I feel needs
some evolution as well. So maybe those 2 things can be tied.
|