Date: Tue, 26 Jun 2007 00:37:02 +0200 From: Fluffles <etc@fluffles.net> To: freebsd-geom@freebsd.org Cc: Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: gjournal performance issues Message-ID: <4680438E.9030407@fluffles.net>
next in thread | raw e-mail | index | archive | help
Hello list, I'm testing gjournal present in -CURRENT as of 13 June 2007. So far i'm not really impressed with performance, i'm writing to the list for any suggestions and information regarding gjournal. First, my setup: 8 disks in RAID5 using geom_raid5, gjournal on top where both the journal (1GB) and the data is stored on the same consumer. Since gjournal uses both metadata and file/dir for journaling, this means that, theoretically, the write speed of sequential operations is doubled. Unfortunately, it appears to have crashed. My problems: - first, throughput appears to be only 8% of the throughput when not using gjournal at all. Whereas it should be close to 50%. - second, during the 'switch' (writing the journal to its final location and starting a new journal) it appears no read operations are possible to the .journal device. If the .journal is /usr, that means the whole system basically freezes for 3 to 5 seconds. Not really sexy. Why would it block read requests? - when using one consumer for both journal and data, it appears the journal is placed at the end of the device. Why? Normally, the beginning of a disk is the fastest and therefore preferable location for the journal. - when analysing graid5 sysctl statistics, it appears gjournal is causing non-contiguous I/O which causes a lot of 2-phase I/O's (involving both reading and writing for 1 write request), the performance difficulties are most probably related to this issue. Why doesn't gjournal read a chunk of journal (50MB) and then write it? And why doesn't it write contiguously? I've tried: - playing with graid5 tunables, including disabling write-back buffer - playing with journal tunables, including disabling optimization (combining), reducing parallel operations to 1, reducing journal switch time and more - kmem is 500MB, gjournal can use 250MB of kernel memory for it's cache (more than the default) - standard UFS2 using async option and without softupdates, newfs used with -J parameter Anyone has any input? I was hoping for at least 40MB/s throughput and no blocking I/O for read requests. Regards, - Veronica
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4680438E.9030407>