[Bug 207022] stat() 4 to 16 times slower on FreeBSD/UFS than on Linux/Ext4

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207022

            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 at FreeBSD.org
          Reporter: fabianosidler at swissonline.ch
                CC: freebsd-amd64 at FreeBSD.org
                CC: freebsd-amd64 at 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=104857600
vfs.ufs.dirhash_reclaimage=600
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:
=== snip ===
BEGIN
{
        self->ts = timestamp;
}

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

dtrace -qs teststat.d -c ./cstat | sort -nk4 | less
=== snip ===
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
=== snap ===

./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

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