Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 08 Feb 2016 15:57:36 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-amd64@FreeBSD.org
Subject:   [Bug 207022] stat() 4 to 16 times slower on FreeBSD/UFS than on Linux/Ext4
Message-ID:  <bug-207022-6@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207022

            Bug ID: 207022
           Summary: stat() 4 to 16 times slower on FreeBSD/UFS than on
                    Linux/Ext4
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: fabianosidler@swissonline.ch
                CC: freebsd-amd64@FreeBSD.org
                CC: freebsd-amd64@FreeBSD.org

I happen a TYPO3 instance under FreeBSD/UFS running 4 to 16 times slower
than on Linux/Ext4. Using XDebug I've found out that it's the stat() syscall
spending the biggest part of the time.
I've already tweaked
vfs.ufs.dirhash_maxmem=3D104857600
vfs.ufs.dirhash_reclaimage=3D600
The UFS dirhash memory always has plenty space left so this can't be the
bottleneck. I further found out with the following Dtrace script that inside
the Kernel, the spinlock_exit and rdtsc functions take a huge part of the
time:
=3D=3D=3D snip =3D=3D=3D
BEGIN
{
        self->ts =3D timestamp;
}

fbt:::entry
{
        printf("fbt enter %s\t%d\n", probefunc, timestamp-self->ts);
        self->ts =3D timestamp;
}
=3D=3D=3D snap =3D=3D=3D

dtrace -qs teststat.d -c ./cstat | sort -nk4 | less
=3D=3D=3D snip =3D=3D=3D
fbt enter rdtsc 11744696324432
fbt enter rdtsc 11744696324802
fbt enter rdtsc 11744696324810
fbt enter rdtsc 11744696325033
fbt enter rdtsc 11744696325155
fbt enter rdtsc 11744696428364
fbt enter spinlock_exit 11744696510486
fbt enter spinlock_exit 11744697160417
fbt enter spinlock_exit 11744697807952
fbt enter spinlock_exit 11744704378856
fbt enter spinlock_exit 11744704699253
fbt enter spinlock_exit 11744716098379
fbt enter spinlock_exit 11744718145218
fbt enter spinlock_exit 11744750135790
fbt enter spinlock_exit 11744751498167
fbt enter spinlock_exit 11744767477782
fbt enter spinlock_exit 11744771142875
fbt enter spinlock_exit 11744784852745
fbt enter spinlock_exit 11744797873176
fbt enter spinlock_exit 11744804495582
fbt enter spinlock_exit 11744912093185
fbt enter spinlock_exit 11744981165023
=3D=3D=3D snap =3D=3D=3D

./cstat is a C program simply stat()ing some 1000 of existing files.
Is this on purpose? What can I do to close the gap on Linux? Also, it's
important to say that this is not an academic exercise! There is a client
announcing to leave for a Linux-based server.
The Linux tests were of course taken on absolutely identical hardware.

Hopeful greetings
Fabiano

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207022-6>