Date: Fri, 10 Jun 2016 15:14:28 -0400 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <tim@kientzle.com> Cc: Gergely Imreh <imrehg@gmail.com>, FreeBSD ARM <freebsd-arm@freebsd.org> Subject: Re: RPi2 i/o blocking and SD card performance Message-ID: <CANCZdfqkgRke7MUq2GfQhQg%2BR5VJ_dz=VM1%2BURGEga1%2B_PgxFA@mail.gmail.com> In-Reply-To: <3AA7AD8C-E6E9-4E8E-96D2-5A712EBD8D52@kientzle.com> References: <CAJ3iQcoc5nVSFz3JKMG_Y9Q9k4PFizmp2rf3vfA7nv=u_12nBQ@mail.gmail.com> <3AA7AD8C-E6E9-4E8E-96D2-5A712EBD8D52@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 10, 2016 at 11:38 AM, Tim Kientzle <tim@kientzle.com> wrote: > >> On Jun 9, 2016, at 2:37 AM, Gergely Imreh <imrehg@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. F= or >> 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 ve= ry >> slow. Once the ports compilation or any other i/o-related task is finish= ed, >> it's snappy again. >> >> Any idea why it could be to have such big latency/lag even though the CP= U >> is idle? Is there anything I could test? > > Watch vmstat output for a while during these periods. In the past, I=E2= =80=99ve > noticed the CPU alternating between being completely busy and completely > idle. When I last asked about this, I recall someone pointing to the dis= k buffer > management as the culprit =E2=80=94 apparently, with slow devices such as= SD cards > it tends to accumulate pending writes, then everything blocks while the d= isk > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqkgRke7MUq2GfQhQg%2BR5VJ_dz=VM1%2BURGEga1%2B_PgxFA>