RPi2 i/o blocking and SD card performance

[Warner Losh]

On Fri, Jun 10, 2016 at 11:38 AM, Tim Kientzle <tim at kientzle.com> wrote:
>
>> On Jun 9, 2016, at 2:37 AM, Gergely Imreh <imrehg at gmail.com> wrote:
>>
>> Hi,
>>
>> I've been testing FreeBSD 11.0-CURRENT on a RaspberryPi2. I'm relatively
>> new to FreeBSD, and wondering if there's any advice for improving the
>> performance a bit.
>>
>> First, it looks like there's a lot of i/o blocking behaviour going on. For
>> example running MediaWiki on the board, if I compile any ports, the site
>> itself is pretty much unusable (the PHP scripts time out even with 180s
>> timeouts). The strangest thing is that the CPU usage is not at 100% all the
>> way, can be that all 4 cores are ~99% idle, and still everything goes very
>> slow. Once the ports compilation or any other i/o-related task is finished,
>> it's snappy again.
>>
>> Any idea why it could be to have such big latency/lag even though the CPU
>> is idle? Is there anything I could test?
>
> Watch vmstat output for a while during these periods.  In the past, I’ve
> noticed the CPU alternating between being completely busy and completely
> idle.  When I last asked about this, I recall someone pointing to the disk buffer
> management as the culprit — apparently, with slow devices such as SD cards
> it tends to accumulate pending writes, then everything blocks while the disk
> cache drains.

Runningbufs may well be the issue.

vfs.hirunningspace: 16777216
vfs.lorunningspace: 11206656
vfs.runningbufspace: 0

runningbufspace is the number of bytes currently pending in the
device. When runningbufspace is higher than hirunningspace, all writes
are blocked until runningbufspace drops below lorunningspace. This
could be the source of problems with write performance, but read
performance won't be affected by this. You can monitor runningbufspace
in a script while you are testing, but that can be quite hit or miss.
Sadly, there's no sysctl that tells you how many writes were stalled
because of this...

Warner