MRU, MFU don't adapt to their targets #16521
Labels
Type: Defect
Incorrect behavior (e.g. crash, hang)
Comments
|
Another example worth noting. MFU size kept decreasing instead of growing to its target. My guess is that L2ARC hits got brought into MRU and kept MRU growing instead of shrinking to its target. Stats also got updated every 10 minutes with zfs-2.2.4-pve1 , zfs-kmod-2.2.4-pve1 . |
|
I think you may misunderstand how MRU/MFU balance works. It is based not on amount of hits or misses for the specific states, but the amount of hits for respective ghost states. I.e. if some ghost state hits predict that bigger size of respective state may be beneficial -- it will be increased. But in the first example a new file write does not produce any ghost hits, since nothing is read, so the balance is not adjusted. In the second example you may see that mfusz is decreasing, despite mfudat growing. You haven't shown mfumet column (and you haven't added a column for total target mru/mfu, if it makes sense at all), but if we assume one also growing, then it might be that system just has not enough mfu data at all to cache, for example due to previous being evicted due to file deletion or overwrite, while all new data are mru and never have hit to promote to mfu. |
|
Thank you for the detailed reply. I incorrectly assumed that MRU & MFU would change to their target sizes without needing any additional ghost hits. However, I am still seeing a strangely shrinking MFU size despite having a growing MFU target and some ghost hits. There're no file deletions or overwrites during the whole period. Would not having enough MFU data explain the shrinking size? The stats're updated every 10 minutes. |
|
I have no explanation for it. Either, as I have said before, something deletes the MFU data and the system just has no more of it left to cache, or it is |
|
The fact that mfudt value is growing should mean there are some MFU data ghost hits, which should mean there are some MFU data to cache. It may mean that problem is in |
I've upgraded from zfs-2.2.4-pve1 , zfs-kmod-2.2.4-pve1 to zfs-2.2.6-pve1 , zfs-kmod-2.2.6-pve1 and still seeing similar results. Also, mfued got evected to only a few MB, while mrued remained around 40 GB.
Thank you for looking into this problem. However, I have no idea how to trace a kernel function. ^^" If it's not too difficult and you could point me to some tutorials on how to do that, I should be able to produce the trace. |
|
I meant using |
tkittich
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Describe the problem you're observing
MRU and MFU don't change to their target sizes, especially when ARC is near its target size. It seems that
arc_evict()scales the amount to get evicted proportionally to the difference between ARC's target size and current size. So when ARC is close to its target size, only a small amount of memory gets evicted. Maybe that's why MRU and MFU cannot reach their target sizes. Perhaps all the MINs inarc_evict()should be MAXs instead?Describe how to reproduce the problem
The text was updated successfully, but these errors were encountered: