-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dir/file metadata consumes enourmous amount of ARC #13925
Comments
interesting - crawling through 1mio cached empty dirs from ARC is an order of magnitude (about 25 times) slower then crawling trough 1mio files (all dirs and files are contained in one dir)
|
Are you sure that the 2.2GB are in ARC, not dbuf cache? dbuf cache unlike ARC is not compressed and micro zap structures used for small directories use 128KB blocks. dbuf cache is limited to only 3% of ARC, but you haven't specified how much ARC do you have for the beginning, so 2.2GB may or may not be within the 3%, in which case it is a correct behavior. |
i didn't know that dbuf cache is being separate from arc and uncompressed. for me, directory entries are metadata. so are filenames, file acl's, timestamps etc.... the system is freshly booted. after a directory crawl with "find /dir..." (and nothing more) , arc_summary looks like this
|
i increased zfs_arc_meta_limit_percent and zfs_arc_dnode_limit_percent just to make sure, there is enough ram available for directory information |
with zfs_arc_dnode_limit_percent removed from the boot options, it looks weird. how can dnode current cache size surpass the hard limit ?
|
for my own interest, i set VMs ram down to 4gb, did warm up the arc again so that it contains 2,2gb of dir information , did a hibernate of the VM and tried to compress the resulting hibernation file. as we can see, the ram contents are very well compressible. ok, this type of compression test may not really be valid, as we need to take the data structures' blocksize into account, but we see there may perhaps be room for improvement.
|
As I see arc_dnode_size_limit limit is respected only during ARC data eviction phase. If your system has enough RAM, it does not apply. |
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
Bad bot. |
Distribution Name | debian
Distribution Version | 11.5
Kernel Version | 5.10.0-18-amd64
Architecture | x86_64
OpenZFS Version | zfs-2.1.5-1~bpo11+1
Describe the problem you're observing
is it normal/expected that 1 mio empty dirs/files , which consume 161/136 Mb on disk (uncompressed) inflate to 2,2Gb of ARC in memory when you do a "find /zfs/dirs|files" across those ?
looks weird to me, thats more then 2kb of ram for each empty dir/file, especially as ARC is compressed, too - so why does caching of dirs/files expand by a factor of nearly 14 when in ram ?
Describe how to reproduce the problem
The text was updated successfully, but these errors were encountered: