-------- Message initial -------- De: Dave <p...@dgmm.net> Reply-to: pan-users@nongnu.org À: pan-users@nongnu.org Objet: Re: [Pan-users] Slowness with long discussion threads... Date: Tue, 4 Oct 2016 09:55:21 +0000 (UTC)
On Mon, 03 Oct 2016 14:01:32 +0200, i443chu8-GANU6spQydw wrote: > > Hi, > > On Ubuntu 16.04, I upgraded to version 0.140 using Klaus Worweg's > binary. http://ppa.launchpad.net/klaus-vormweg/pan/ubuntu/dists/ > > I marked a thread containing 328 posts as not read. > The first post of the thread is accessed almost instantly. > But to reach a post in the middle of the thread, with a large answer > depth, pan used 48 second of intel i3 1.3Ghz processor time. > > PID UTIL. PR NI VIRT RES SHR S %CPU %MEM TEMPS+ > COM. > 3980 pa 20 0 270716 149884 29644 S 0,3 8,4 6:10.81 > pan > 3985 pa 20 0 270716 149884 29644 S 0,0 8,4 0:00.00 > dconf > worker 3986 pa 20 0 270716 149884 29644 S 0,0 8,4 > 0:00.00 gmain 3987 pa 20 0 270716 149884 29644 > S 0,0 8,4 > 0:04.47 gdbus 3990 pa 20 0 270716 149884 29644 > S 0,0 8,4 > 0:00.00 pool 3991 pa 20 0 270716 149884 29644 > S 0,0 8,4 > 0:00.00 pool 3992 pa 20 0 270716 149884 29644 > S 0,0 8,4 > 0:00.00 pool > > The more a post is indented, the longer it takes to display it. > > Any idea? > > The fact it's doing the same as with 0.139 for you and not for a range of > other people does seem to indicate that it's not Pan but some other > library on your system which Pan depends upon. > It could also be a hardware problem, an iffy sector on the hard disk > where Pan is maintaining its database or a file system error. > I have, on occasion, had odd errors where fsck didn't find anything, but > running a full fsck without -y (yes to fix automatically, yes to use > journal to fix) did then find errors which it then fixed. > Likewise, try smartctl to check the SMART status of the HDD, and maybe > run the full surface test to make sure there are no bad sectors or other > errors, Wikepedia has a good description of the SMART data points and > what they mean. This can take well over an hour for the full scan. > If you've never done either of the above, it's probably a good idea to do > those tests anyway. > Also, a couple of years ago I had issues with Pan threading, ie not > threading properly or at all if the thread depth was more than 2 or 3. > We eventually narrowed it down to FreeBSD still using an older version of > gmime. This may be a complete red herring, my problem was quite > different but it was a threading issue caused by gmime and using an older > version fixed it until the latest version was made available in the > FreeBSD ports system. Thank you for your answer. Pan is not the only application involved, but it is the more affected. As it appeared to be a local display problem, I tried to access pan from another workstation over ssh: no delay. I then tried to access pan on the same machine over ssh again (ssh -X localhost pan): no delay. Pan is not at the origin of the problem. Many thanks for your replies again. PA _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
