20 *concurrent*, logged in users? Are some disconnected?

Terminal server is not a typical Thunderbird user environment, and therefore not well tested. There have been very few reports of performance issues in the last decade - most in the first half, so pretty quiet the few years.

I would suggest concentrating on the following:

• make sure system has enough memory to support each open TS at 500MB memory
• run 32 bit thunderbird, not 64bit
• time settings for auto saving drafts and checking for new mail should be modest, eg left at default (no values of 1, 2, 3 minutes)
• no settings of "check this folder for new message" except the default, i.e. for the Inbox
• antivirus software MUST exclude thunderbird.exe and the thunderbird profile directories - perhaps even the temp directory
• You probably want to encourage smallish Inbox sizes, eg less than 2-3k messages
• make sure your users routinely empty trash and junk folders, and drafts is relatively small
• set highish value for automatic compact (default is 10mb, suggest 20mb or more) and that automatic compact is working

I'd be interested what you find. If there are still problems Some old reports worth checking are https://bugzilla.mozilla.org/show_bug.cgi?id=670933 https://bugzilla.mozilla.org/show_bug.cgi?id=574669 https://bugzilla.mozilla.org/show_bug.cgi?id=533501

And, which OS are you running - 2008, 2012?

Oh, and Thunderbird profile is each user's default location - %APPDATA% ??

Thanks for the prompt replies.

It does not matter how many people are logged into the server. This behavior occurs when there is only one user. There's plenty of memory.

While having Windows Task Manager open so that I can see the I/O stats in real time, an email with a modest attachment (around 2MB) is sent and immediately the I/O jumps up to 50,000 (as there are no units stated next to the number, I'm not really sure what they are). Once the email is sent out and Thunderbird should be idle again, this number remains. If the user sends another one, this number is increased with a similar amount and once again, it remains even after the email is sent. In other words, the hard drive activity is not built up over time by various settings here and there. It is only built up by sending emails with attachments of a fair size, and very easy to reproduce and monitor using the archaic method described above.

The only way to make Thunderbird go back to "normal" is by closing and opening it again.

No anit-virus is installed on this computer (It is handled elsewhere on various other devices)

The profiles are located at the default location defined by Thunderbird. App Data - Thunderbird - Profiles

I'm running Windows 2003 Server

Thunderbird 32-bit is running (the OS is 32 bit)

You know Server 2003 is no longer supported by MS?  :)

Interesting issue you have. I hope we can put it to good use :)

Two more things: - it happens in safe mode? https://support.mozilla.org/en-US/kb/safe-mode - disable "keep messages synced" in the account settings, sync and storage tab (I doubt will help, but it will simplify further testing)

After disabling that it will help to collect some, or even better all, of the following a) use system internals procmon to determine which files are being hammered with IO b) a profile URL from https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Thunderbird_Performance_Problem_with_G which will show the code being hammered c) a debug log with msgdb:5,timestamp per https://wiki.mozilla.org/MailNews:Logging

FWIW, attachment performance bug reports: http://mzl.la/1Qa4Rak

Hehe, I'm painstakingly aware of the legacy OS we're running at this site and migration from Outlook to Thunderbird is a part of the move to something a little more up to date. Whether that will be Linux or Microsoft's' latest offerings is still up for debate.

- Safe Mode....This did not change anything. Same behavior

- System Internals Procmon... I spent a few hours getting to know this tool as I have never used it in the past. I fail to figure out how to isolate something specific in order to monitor it, as the processes in the list are many and comes rapidly. Furthermore, I can't seem to find the Read/Write activity of the hard drive is listed for any given process.

- A profile URL seem to require the latest build, something I simply can't install on the server. I'm assuming this can't be run side by side, and anything installed on a TS will be available to all users in order for it to run properly.

- I made two log files. One SMTP and one POP3. Both were run exactly the same, namely: Thunderbird was run, an email was composed with an attachment, email was sent, application closed. As soon as the send dialog box was closed, 50,000 was added to the process for Thunderbird in Task Manager.

These log files can be found here: https://www.dropbox.com/s/ebipy3hywn4h4ox/pop3.log?dl=0 https://www.dropbox.com/s/9j34noe3vq6za0k/smtp.log?dl=0

I should change that documentation. Please try the profiler using a current version.

Thanks for the logs, but it's not what I need -- msgdb:5,timestamp

Sorry, I misunderstood, and probably still am, but I added msgdb:5,timestamp to the end instead of pop3/smtp, and what was produced can be found here: https://www.dropbox.com/s/zlt524iwvd8zukh/msgdb.log?dl=0

Furthermore, here is the report created using Gecko Profiler http://people.mozilla.org/~bgirard/cleopatra/?1444405691461#report=e5a9a8082ee94a7ef01a0cc0e5f4933e7a5abe3b

Interesting stuff.

So was the profile was taken during and after sending a message?

Is Server 2003 running 32bit or 64?

What details can you give about the backing disk/array? Write buffering enabled or disabled?

MockY said

Sorry, I misunderstood, and probably still am, but I added msgdb:5,timestamp to the end instead of pop3/smtp, and what was produced can be found here: https://www.dropbox.com/s/zlt524iwvd8zukh/msgdb.log?dl=0 Furthermore, here is the report created using Gecko Profiler http://people.mozilla.org/~bgirard/cleopatra/?1444405691461#report=e5a9a8082ee94a7ef01a0cc0e5f4933e7a5abe3b

p.s. 1. please screen shot and post tools | addons | plugins 2. the profile shows read access against TS.Guidepdf - can you speculate where that is coming from? 3. can you test to determine roughly but a bit more precisely where the break point is that the IO never stops - is it size M of one attachment, or is it aggregate size of N attachments? 4. When did this start happening - version 38.?.? 3.

I started Thunderbird and installed the plugin. I did not restart Thunderbird. Once installed, I started the recording and proceeded with sending an email with a 2.4mb attachment. I noticed that it took longer for it to complete than usual, but the end result was the same. I then ended the recording.

I'm running Windows 2003 32bit.

The server is running 2 disks in RAID 1. And since I have to reboot the server in order to figure out whether write buffering is on or not (unless you know of a different method), I can't give you an answer whether this is enable or disable.

Wayne Mery said

MockY said

Sorry, I misunderstood, and probably still am, but I added msgdb:5,timestamp to the end instead of pop3/smtp, and what was produced can be found here: https://www.dropbox.com/s/zlt524iwvd8zukh/msgdb.log?dl=0 Furthermore, here is the report created using Gecko Profiler http://people.mozilla.org/~bgirard/cleopatra/?1444405691461#report=e5a9a8082ee94a7ef01a0cc0e5f4933e7a5abe3b

1. please screen shot and post tools | addons | plugins 2. the profile shows read access against TS.Guidepdf - can you speculate where that is coming from? 3. can you test to determine roughly but a bit more precisely where the break point is that the IO never stops - is it size M of one attachment, or is it aggregate size of N attachments? 4. When did this start happening - version 38.?.?

1. http://s28.postimg.org/eownpyy0r/screen.png 2. TS Guide.pdf is the name of the attachment I'm sending 3. I tried different types of files as well as different sizes, and it does not seem to matter what type of file it is. However, the I/O Writes seem to be proportional to the size of the file that is attached. A small .txt file barely made a difference (though it did increase), and a larger .mp3 file resulted in more I/O activity than the 2.5MB file I've been testing with. So yeah, the larger the file, the more lingering I/O Writes. 4. I wish I could tell you with what version this started to happen. This issue was just discovered, but we have not been running Thunderbird on this server for a long time, so it's safe to say it "started" with a later version, though things could have been an issue all along. However, this was just brought to my attention so it could be the current version.

On a much less technical level, can you try attachments of say text and png as well.

I assume in this corporate environment with TS that some form of anti virus is de jure. What sort of protection is running? Is there a resident module?

That the attachment is being flagged for excessive I/O may indicate two processes battling for control, or denying it to one another. Recent issues with Avast and the locking of nsemail.html come to mind as an issue caused by anti virus but not appearing to have any involvement at all.

.

per http://people.mozilla.org/~bgirard/cleopatra/?1444405691461#report=e5a9a8082ee94a7ef01a0cc0e5f4933e7a5abe3b all the writes are happening to the Sent folder.

So what would be interesting is a profile say 5 minutes after the message has been sent, unless that's what http://people.mozilla.org/~bgirard/cleopatra/?1444405691461#report=e5a9a8082ee94a7ef01a0cc0e5f4933e7a5abe3b was.

No Anti-virus software is running on this machine. All this is handled by other devices on the network. I do manually run CCleaner and Malwarebytes just as a little safetyguard. It may not sound very bizarre, but that is the environment nonetheless. Neither software has services running.

I've tried PDF, TXT, JPG, and PNG of varying sizes, and it does not matter what the file type is. The usage left in use after the message is sent is dependent on the size of the file. The larger the file, the more I/O is lingering.

Waiting 5 minutes does not change anything, though you probably meant "behind the scenes" during that period.

> Neither software has services running. So they are not running "real time", that is good.

> Waiting 5 minutes does not change anything, though you probably meant "behind the scenes" during that period.

What a really mean by that, I'd like the profile to be from a period that is long after the message was sent.

And I hate to ask more, but I think a log of

imap:5,ImapAutoSync:5,msgdb:5,timestamp

We do know that file writes are not buffered, so if there simply a matter of slow IO we wouldn't need to look further. But if the IO continues until THundbird is shut down, then there is either really weird IO happening, or some protocol problem.

The Log File

https://www.dropbox.com/s/hxkf86324bobkp7/thunderlog.log?dl=0

The 5 Minute test. Opened Thunderbird, sent an email with attachment within 30 seconds, let Thunderbird run for another 5 minutes

http://people.mozilla.org/~bgirard/cleopatra/?1444755661024#report=a008ad7e368bbe20e2d37559683cb67503a28508

Due to the silence, I assume that none of you have the slightest idea why this is an issue. Thanks for the responses.