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 r...@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 r...@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-unsubscr...@freebsd.org"
