Re: filesystem slowdown with backports kernel
- Date: Wed, 17 Oct 2018 19:47:18 +0300
- From: Reco <recoverym4n@xxxxxxxxxxxx>
- Subject: Re: filesystem slowdown with backports kernel
On Wed, Oct 17, 2018 at 04:44:25PM +0200, Support (Jens) wrote:
> >> we have a NAS system acting as a place to store our server's backups
> >> (via rsync with link-dest). On that NAS we switched from the stable
> >> kernel (4.9) to the one provided by backports (4.18) because of an
> >> unrelated problem. When we do that, we see a slowdown of our backup
> >> process, from the backup via rsync itself to deleting old backup
> >> directories. The slowdown seems to be connected to the number of
> >> files/directories as backups of systems with less files seem less
> >> affected than the ones with many files.
> > I'd complete your tests with an invocation of 'perf record/perf top'
> > on NFS server side.
> > The reason being - you'll be able to point out at particular
> > kernel/userspace functions that are responsible for this slowdown.
> there is no NFS in play, everything was tested locally or did I
> misinterpret your suggestion.
No, it was a bad wording from me. Old habit - it's not a NAS unless it
has NFS, and all that. Disregard 'NFS' part.
You have a host that serves a role of a fileserver that experiences a
slowdown. You do tests on this host with assorted kernel versions trying
to locate problematic kernel versions.
Before doing these tests once more you run 'perf record' in a separate
shell, and terminate 'perf record' once a test is done. Next you copy
resulting 'perf.data' file for safekeeping.
Rinse and repeat for each kernel/filesystem tested.
Once all needed combinations of kernel/filesystem are tested once more,
you use 'perf report' and 'perf annonate' to show you actual
userspace/kernel functions that were in play at the time of tests.