nikolam schrieb:
I also observed that disk lockups on Seamonkey and Thunderbird happen
periodically and that also hangup like that with large disk access is
Always triggered in the moment when going from offline to online network
state in SM/TB.
First: I've noticed no such troublesome behavior on Mac OS X with SM,
but my structures in messenger are rather small (3 email accounts, 2 of
which are tiny; local folder archive; couple of feeds; 2 newsgroups).
Second: Without being a SM/TB developer, just guestimating from things
I've seen on systems in general:
"At going online" and "periodically" sounds very much after running
refresh cycles (i.e. polling all feeds, mails accounts, etc. pp.).
Generally speaking: Often such things work pretty well on small systems
even when not done in a smart way, and can get bogged down on large a
installation.
If you can nail down "periodically" to the poll intervals you've set for
the different account types, then the trouble shooting likely can only
happen with insights into the code.
Do you have "new messages" after the slow down finishes?
If you have this "proof" of correlation between poll cycles and slow
down, then the best you can do is:
- describe the dependency, and
- describe your system as accurately as you can:
#accounts, #folders, #number messages, #size of folders, ...
- and finally note any specialties about your system.
Especially if (disk) IO could be impacted.
(E.g. if user home directory is local file system or network
filesystem; maybe even filesystem type; RAID; etc. pp.)
Without knowing the code, it's hard to tell, where the time/IO is used up.
Sometimes you find easy things, which were just not coded to scale and
can be changed in the code itself.
Sometimes you don't (when you already have efficient code).
Then something as easy as de-coupling the poll cycles of all the
accounts may already help.
Example: I've noticed during 2011, that SM upon restart + session
restore (windows + tabs of browser component) first sets up all tabs
"from memory" and then iterates through the tabs with actually
refreshing them. Beforehand it refreshed them all at once, which might
make it unresponsive upon first startup.
So you could have a scheduler for refresh "per account / folder", which
might seem overkill for systems with only a few of these (where a
single/synchronous counter for all works perfectly well and is very
efficient).
Just my 5 cents, that might be worlds off the real problem. ;-)
Best regards
Philipp
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
