mail/mutt extremely slow - truss output

[Anton Shterenlikht]

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 at freebsd.org>
To: freebsd-ports at 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 at 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 at 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 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"