Slowness with long discussion threads...

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Slowness with long discussion threads...

i443chu8
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?

PA



_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slowness with long discussion threads...

Dave-58
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.


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slowness with long discussion threads...

Duncan-42
Dave posted on Tue, 04 Oct 2016 09:55:21 +0000 as excerpted:

> 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.

I can confirm threading issues with older gmime, tho the ones I saw and
which Dave may be referencing were bad posting behavior, improper
"folding" (RFC term, aka wrapping aka splitting) of the references
header, breaking it so an affected post would generally appear in the
right thread (the first few reference IDs were intact) but in the wrong
place (later IDs were missing or parsed incorrectly due to bad folding/
wrapping/splitting of the header).  It was bad posting, breaking the RFCs
so many standards compliant clients would get the threading wrong.

For reference, I'm currently running gmime-2.6.20 here, without issues
that I'm aware of (tho actual installed version is gmime-2.6.20-r3, the
-r3 indicating three distro-specific version bumps, possibly including
patches for other bugs but just as likely simply due to distro-specific
issues such as changes in dependencies).

IIRC the breakage was earlier in the 2.6 series, with I believe 2.6.17
and 2.6.18 broken (regression from 2.6.16 which was IIRC fine) and I
/think/ the fix in 2.6.19.

The gmime-2.4 series was unaffected by that particular bug, but of course
they may have had others.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slowness with long discussion threads...

i443chu8
In reply to this post by i443chu8


-------- Message initial --------
De: Dave <[hidden email]>
Reply-to: [hidden email]
À: [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Loading...