Date: Wed, 04 Mar 2015 14:38:17 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-geom@freebsd.org Subject: Re: Trim on gmirrored SSDs is slow and results in inresponsive system Message-ID: <54F718D9.1080201@multiplay.co.uk> In-Reply-To: <54F7147F.8070206@bytecamp.net> References: <54F6FE2E.60303@bytecamp.net> <54F707CC.6070105@multiplay.co.uk> <54F7147F.8070206@bytecamp.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/03/2015 14:19, Robert Schulze wrote: > Hi, > > Am 04.03.2015 um 14:25 schrieb Steven Hartland: >> Do you have one disk which has really slow TRIM? >> > please note, it does not depend on the disk, it is related to gmirror. Yes but gmirror will wait for all disks to complete the delete before the top level delete is marked as complete, so if you have an issue with one of the underlying devices, be that cabling issue or disk on the way out, this could be your issue. >> Also how does gstat -d -p compare between gmirror and none gmirror >> installs on the same machine? > Deleting on a non-mirrored UFS does not influence the system, because > the BIO_DELETE calls are processed extremely fast (~ 1 sec with 1GB > file), with a high number of d/s (~ 100k). Can you get snapshot of both in action please > >> Do you see high kernel CPU when the deletes are happening? > no. Here are the top system processes after deleting a 5GB file: > > 0:40 144.87% cam > 0:22 77.59% g_mirror var > 0:14 62.79% bufdaemon > 0:14 0.88% intr > 0:13 0.59% geom > 0:01 0.00% rand_harvestq > 0:00 0.00% kernel 144% in cam is very high and g_mirror is high too. What OS build is this? http://svnweb.freebsd.org/changeset/base/267118 could well be the cause of high CAM CPU, this was one of main reasons why the original bypass or sorting was added. Regards Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54F718D9.1080201>