Giuseppe,
1) In my mind, if other applications on the same network as the QMT
accessing the cloud slow down, you might have a bandwidth problem. If
not, your clients could have a bandwidth problem. If the QMT is not on
the users network but over the cloud, then, it is difficult to pin the
problem on your QMT host. It could be anywhere on the cloud.
During these peak hours is it possible to test speeds of IMAP, POP3,
SMTP, Submission, HTTP, HTTPS, and other protocols the QMT host offers
from within the same subnet. In other words connect to its services but
not over the cloud.
2) As far as duplicates, your host may be overloaded which could be the
cause of everything.
Per Eric Shubert: "Duplicates are often the result of the QMT host being
overloaded, and scanning taking too long (the sending server times out
during scan, and resends later). "
Duplicate Email from Mailing List
* It may happen because low memory on server. Make sure you enough
memory on the server. You can:
o add more memory on server
o stop unused service on server
o disable some of SpamAssassin plugins
o disable some of unofficial ClamAV dat.
o decrease the value of Concurrencyincoming
<http://wiki.qmailtoaster.com/index.php/Concurrencyincoming>,
Concurrencyremote
<http://wiki.qmailtoaster.com/index.php/Concurrencyremote> and
Concurrencylocal
<http://wiki.qmailtoaster.com/index.php/Concurrencylocal>
* If you use spamdyke, increase the value of idle-timeout
* Problem with SpamAssassin auto expiration function. create below
script and added to your crontab
# cat /etc/cron.daily/sa-bayes-expire
#!/bin/sh
# written 11/17/06 by Eric 'shubes' <[email protected]>
# force journal sync and expiration of spamassassin bayes database
#
sa-learn -u vpopmail --force-expire
chown vpopmail:vchkpw /home/vpopmail/.spamassassin/bayes_toks
#
EricB.
On 7/9/2015 1:46 PM, Giuseppe Perna wrote:
> hello, thanks for your reply.
> QMT are not on the same network, the server is a data center and
> clients scattered around Italy.
> The problem of duplicate emails, tripled and cc is found constantmente,
> The server fills local queues during peak connections between 9:00 AM
> and 12:00 AM,
> there are other applications that slow.
> thanks
>
> 2015-07-09 19:08 GMT+02:00 Eric Broch <[email protected]>:
>> Giuseppe,
>>
>> I'm as new to this as you are as I've never experienced what you're
>> experiencing presently. I'll have to do a little investigation and get
>> back to you. But, let me ask a few more questions. If anyone else on the
>> list has any suggestions for Giuseppe it would be GREATLY appreciated.
>>
>> 1) Is the QMT/QMT'S on the same private network as the users?
>> 2) At these peak hours, is it ONLY the mail server that slows or are
>> other internet applications slow as well, like web browsing, etc...?
>>
>> EricB.
>>
>>
>> On 7/9/2015 9:30 AM, Giuseppe Perna wrote:
>>> in this moment:
>>> even now come duplicate emails and there 'full queue.
>>> I would be inclined to upgrade spamdyke and verify disk access,
>>> you can give me the info about? you find it because of these two elements?
>>>
>>> # qmHandle -L
>>> Messages in local queue: 57
>>> Messages in remote queue: 1
>>>
>>>
>>> Cpu(s): 3.7% us, 9.6% sy, 0.0% ni, 12.0% id, 74.4% wa, 0.3% hi, 0.0% si
>>> Mem: 8308652k total, 1989556k used, 6319096k free, 115716k buffers
>>>
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>> 4973 apache 17 0 27524 9524 4676 S 3.0 0.1 0:03.00 httpd
>>> 5456 vpopmail 15 0 40948 36m 2628 S 3.0 0.4 0:12.31 spamd
>>> 10384 vpopmail 18 0 4604 976 696 D 3.0 0.0 0:04.56 imapd
>>> 133 root 16 0 0 0 0 S 2.7 0.0 0:02.50 pdflush
>>> 6113 apache 17 0 33508 14m 4684 S 2.7 0.2 0:02.27 httpd
>>> 6515 apache 16 0 33500 15m 4932 S 2.0 0.2 0:02.69 httpd
>>> 637 root 15 0 0 0 0 D 1.7 0.0 0:22.43 kjournald
>>> 9125 vpopmail 18 0 4308 1020 696 D 1.7 0.0 0:06.00 imapd
>>> 3 root 34 19 0 0 0 S 1.3 0.0 0:00.37 ksoftirqd/0
>>> 11013 vpopmail 18 0 4000 1052 684 D 1.0 0.0 0:00.63 imapd
>>> 3976 mysql 16 0 149m 24m 5068 S 0.7 0.3 0:07.28 mysqld
>>> 10575 root 16 0 3908 1248 772 R 0.7 0.0 0:00.60 top
>>> 11372 vpopmail 15 0 3900 1648 1296 S 0.7 0.0 0:00.02 spamdyke
>>> 109 root 5 -10 0 0 0 S 0.3 0.0 0:00.87 kblockd/2
>>> 3579 dnscache 15 0 4824 1500 280 S 0.3 0.0 0:03.48 dnscache
>>> 3693 qmailq 16 0 1980 320 256 S 0.3 0.0 0:00.22 qmail-clean
>>> 4216 vpopmail 16 0 39800 35m 2632 S 0.3 0.4 0:12.71 spamd
>>>
>>> 2015-07-09 17:22 GMT+02:00 Eric Broch <[email protected]>:
>>>> On 7/9/2015 9:10 AM, Giuseppe Perna wrote:
>>>>> strangely a few minutes ago it was corrupt table session roundcube
>>>>> webmail and was sheltered from the command line.
>>>> I'm not sure what you mean by the ^^^above^^^ statement.
>>>>
>>>> If you run 'top' what kind of resource usage are you getting.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> --
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
