Bug 15242 - Performance regression with getattr tests
Summary: Performance regression with getattr tests
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.17.1
Hardware: All All
: P5 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-15 21:37 UTC by Paul Cerqua
Modified: 2022-11-22 00:31 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Cerqua 2022-11-15 21:37:20 UTC
We've been discussing the following issue with some samba team members and I've been requested to formalize this with a bug report.

We have performance test suites that we run on samba releases.  We've seen a performance regression (when compared to samba 4.12) when performing a large number of getattr operations (specifically, to retrieve the last modified time).

The setup is that we create about 400,000 files and then use SMB to get the last modified time on those files at a controlled rate.

We have graphs that show the regression, but here are the number of syscalls that we see in 4.12 vs 4.17 (hopefully, this formats correctly):


Name                              samba 4.12     samba 4.17

syscall_asys_pread_count                1152           1152
syscall_asys_pwrite_count                832            832
syscall_chdir_count                     4362      281514403
syscall_closedir_count                   102      140758607
syscall_fcntl_count                     3264           3264
syscall_fdopendir_count                   32      140758607
syscall_fntimes_count                      0            832
syscall_fstat_count                150095249      985313737
syscall_ftruncate_count                  416            416
syscall_get_alloc_size_count               0      281517638
syscall_getwd_count                      797             56
syscall_openat_count                       0      844552242
syscall_readdir_count                   1712     2746633627
syscall_realpath_count             150095079      281517622
syscall_stat_count                1050658924      844541884
syscall_telldir_count                   1476     2465116381



(I don't want to break the "one bug per case" rule, but in case it's relevant to this, I'll mention in passing that we see a similar regression when running a performance suite that concentrates on directory listings, but we don't have a comparative list of syscalls for that case yet.  I can file a separate case for that once we collect our data.)

Thanks,
  Paul
Comment 1 Ralph Böhme 2022-11-16 09:32:53 UTC
Hello Paul,

thanks for logging the bugreport!

I really wonder why there's such an increase for syscalls like chdir, readdir and telldir. As dicussed, this likely requires some largish and dedicated engineering resources.
Comment 2 Jeremy Allison 2022-11-17 00:32:23 UTC
Backing up Ralph here. We really need to understand *exactly* what your performance test suite is doing in order to work on specifics.