You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to high CPU usage i have just come across an interesting behaviour:
If an external pop3 account has many mails (in this case 17000+), the server seems to be busy for ~2 minutes just for comparing the UIDs, with one CPU core at maximum load (on an Xeon 3060 Dualcore). Since the user had the fetch interval at 7 minutes, the load was clearly noticeable.
I guess the code at https://github.com/hmailserver/hmailserver/blob/master/hmailserver/source/Server/ExternalFetcher/FetchAccountUIDList.cpp is doing this check.
Server Log:
"POP3C" 2916 7039 "2015-03-16 22:04:55.432" "IPXXX" "RECEIVED: +OK password required for user "XXXXXXXXXX""
"POP3C" 2916 7039 "2015-03-16 22:04:55.432" "IPXXX" "SENT: (password)"
"POP3C" 2924 7039 "2015-03-16 22:04:55.556" "IPXXX" "RECEIVED: +OK mailbox "XXXXXXXXXX" has 17402 messages (1007106996 octets) H XXXXXXXXXX"
"POP3C" 2924 7039 "2015-03-16 22:04:55.556" "IPXXX" "SENT: UIDL"
[..]
"POP3C" 2948 7039 "2015-03-16 22:06:34.258" "IPXXX" "RECEIVED: +OK[nl]1 [...]
what follows is a line of ~512kb length with UIDs.
Windows Performance Counters look like this during the fetch:
Im not sure why the page faults rise after some seconds into the fetch. The Server has lots of free Ram.
Of course this was an extreme case, but optimizing this algorithm could maybe improve the performance, especially if this feature is heavily used by more than one user :-)
I increased the fetch interval and asked the user to think about enabling the automatic deletion, but in some scenarios this may not be an option.
The text was updated successfully, but these errors were encountered:
Due to high CPU usage i have just come across an interesting behaviour:
If an external pop3 account has many mails (in this case 17000+), the server seems to be busy for ~2 minutes just for comparing the UIDs, with one CPU core at maximum load (on an Xeon 3060 Dualcore). Since the user had the fetch interval at 7 minutes, the load was clearly noticeable.
I guess the code at https://github.com/hmailserver/hmailserver/blob/master/hmailserver/source/Server/ExternalFetcher/FetchAccountUIDList.cpp is doing this check.
Server Log:
"POP3C" 2916 7039 "2015-03-16 22:04:55.432" "IPXXX" "RECEIVED: +OK password required for user "XXXXXXXXXX""
"POP3C" 2916 7039 "2015-03-16 22:04:55.432" "IPXXX" "SENT: (password)"
"POP3C" 2924 7039 "2015-03-16 22:04:55.556" "IPXXX" "RECEIVED: +OK mailbox "XXXXXXXXXX" has 17402 messages (1007106996 octets) H XXXXXXXXXX"
"POP3C" 2924 7039 "2015-03-16 22:04:55.556" "IPXXX" "SENT: UIDL"
[..]
"POP3C" 2948 7039 "2015-03-16 22:06:34.258" "IPXXX" "RECEIVED: +OK[nl]1 [...]
what follows is a line of ~512kb length with UIDs.
Windows Performance Counters look like this during the fetch:
Im not sure why the page faults rise after some seconds into the fetch. The Server has lots of free Ram.
Of course this was an extreme case, but optimizing this algorithm could maybe improve the performance, especially if this feature is heavily used by more than one user :-)
I increased the fetch interval and asked the user to think about enabling the automatic deletion, but in some scenarios this may not be an option.
The text was updated successfully, but these errors were encountered: