Date: Mon, 30 Jul 2012 12:18:42 +0100 (BST) From: Anton Shterenlikht <mexas@bristol.ac.uk> To: freebsd-ports@freebsd.org, mandree@freebsd.org Subject: Re: mutt 1.5 much slower than mutt 1.4 Message-ID: <201207301118.q6UBIgqk038035@mech-cluster241.men.bris.ac.uk> In-Reply-To: <5011C6CD.3040409@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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'll need to read up on this.
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.
ok, thanks, I'll ask in ia64 list.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207301118.q6UBIgqk038035>