Date: Mon, 30 Jul 2012 12:56:39 +0100 (BST) From: Anton Shterenlikht <mexas@bristol.ac.uk> To: freebsd-ia64@freebsd.org Subject: mail/mutt extremely slow - truss output Message-ID: <201207301156.q6UBudIQ012228@mech-cluster241.men.bris.ac.uk>
next in thread | raw e-mail | index | archive | help
mail/mutt (version 1.5) is extremely slow on r237134. I was advised in ports@ to collect truss output. Here it is for opening a folder in mutt: http://seis.bris.ac.uk/~mexas/mutt.truss.open.folder I don't exactly understand what Matthias is saying, can somebody here clarify please. Thanks Anton Date: Fri, 27 Jul 2012 00:38:05 +0200 From: Matthias Andree <mandree@freebsd.org> To: freebsd-ports@freebsd.org Subject: Re: mutt 1.5 much slower than mutt 1.4 Am 25.07.2012 12:47, schrieb Anton Shterenlikht: > On Tue, Jul 24, 2012 at 11:00:39PM +0200, Matthias Andree wrote: >> Am 24.07.2012 19:18, schrieb Anton Shterenlikht: >>> mail/mutt is much slower on my amd64 and ia64 >>> -current boxes after it was updated from 1.4 >>> to 1.5. Each keystroke takes few seconds to >>> act. Below is my mutt 1.5 config: >> ... >> >>> Anybody else is seeing this behaviour? >> >> Not here™ on amd64 9-stable -- which may have little relevance for >> 10-current. >> >>> Any advice? >> >> Any chance to figure out what mutt is doing, like with truss or similar? I'm not sure if I can trust the truss WRT return values (looks like a 32 vs 64 bit issue), there tons of "unknown error". But there is a recurring action around dealing with /tmp/mutt-mech-cluster*. This I/O might be expensive, depending on the /tmp file system. RAM disk might be useful to speed things up... Any idea what's it doing? > getpid() = 4295169008 (0x1000313f0) > getpid() = 4295169008 (0x1000313f0) > lstat("/tmp/.muttJqtqdK",0x7fffffffffffc0a0) ERR#4295172128 'Unknown error: 204832' > mkdir("/tmp/.muttJqtqdK",0700) = 4295170448 (0x100031990) > open("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj",O_RDWR|O_NOFOLLOW|O_CREAT|O_EXCL,0600) = 4295170328 (0x100031918) > close(4) = 4295170688 (0x100031a80) > link("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj","/tmp/mutt-mech-cluster241-XSYQpzbj") = 4295170808 (0x100031af8) > lstat("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj",{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295172128 (0x100032020) > lstat("/tmp/mutt-mech-cluster241-XSYQpzbj",{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295172128 (0x100032020) > unlink("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj") = 4295170928 (0x100031b70) > unlink("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj") ERR#4295170928 'Unknown error: 203632' > rmdir(0x7fffffffffffc878,0x1001b2c30,0x2,0x2,0x2,0xa0000000c813d400) = 0 (0x0) > open("/tmp/mutt-mech-cluster241-XSYQpzbj",O_RDWR|O_NOFOLLOW|O_CREAT,0600) = 4295170328 (0x100031918) > lstat("/tmp/mutt-mech-cluster241-XSYQpzbj",{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295172128 (0x100032020) > fstat(4,{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295171888 (0x100031f30) > fcntl(4,F_GETFL,) = 4295168408 (0x100031198) > fstat(4,{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295171888 (0x100031f30) > write(4,"From root@bristol.ac.uk Sun Jul "...,2041) = 4295172488 (0x100032188) > lseek(4,0x0,SEEK_SET) = 4295169848 (0x100031738) > fstat(4,{ mode=-rw------- ,inode=331538,size=2041,blksize=16384 }) = 4295171888 (0x100031f30) > read(4,"From root@bristol.ac.uk Sun Jul "...,16384) = 4295178608 (0x100033970) > close(4) = 4295170688 (0x100031a80) > unlink("/tmp/mutt-mech-cluster241-XSYQpzbj") = 4295170928 (0x100031b70) >> Is debugging turned on; was mutt built WITH_DEBUG=yes? > > yes, I just rebuilt with this set. Uh, I rather meant that debugging might cause unoptimized code, but given such repeated I/O to /tmp files I think that's more the culprit. Any of the patches causing it? Do you dare remount /tmp as asynchronous file system? I don't see fsync(), so async might help a bit, and is reasonable for /tmp. >> Can you verify the header cache databases, or move them away just for >> the sake of the experiment? > > sorry, I don't know what you mean here. You enabled header caches during the build, and if they were excessively large or broken, that might also cause slowdowns; but they need to be run-time configured, which you did not, so forget this. >> Does it help if you "make clean" before building world? This has cured >> strance effects on occasions in -STABLE (RELENG_[6-9]) branches for me. > > Well, I might do this later, if no other > clue emerges. Looking at the truss output, unless the 32nd bit set is required by the IA64 calling conventions, that may be necessary regardless of the mutt issue. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207301156.q6UBudIQ012228>