Re: [Pan-users] Slowness with long discussion threads...

[Dave]

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.



-- 
Climate Change may be raising the sea levels, but the gene pool
seems to be drying up.