Fair enough, but It's a relatively painless quick upgrade between those
versions. Anyway grab a status first as we then might be able to
identify the issue and advise if the upgrade will help.
ChrisP.
On 19/03/2016 10:30 a.m., David Camm wrote:
> we're currently on 6.7b-41. i guess we need to upgrade the code to get
> erec_show. that's something i'm a bit reluctant to do right now :-)
>
> david camm
> advanced web systems
> keller, tx
>
>
> On 3/18/2016 4:12 PM, surgemail-support wrote:
>> The primary thing to grab is
>> tellmail status
>> while the load is occurring, a couple of them would be good and send
>> along for me to look at.
>>
>> The other command in recent builds that can be useful is:
>>
>> tellmail erec_show
>>
>> which gives some useful information on which imap users are causing
>> the most 'load'. this can help to identify an account that is
>> sending out thrashing
>> imap commands (sometimes a bad client will just send the same request
>> endlessly)
>>
>> ChrisP.
>>
>>
>> On 19/03/2016 8:37 a.m., David Camm wrote:
>>> we're running on a 4-core, 4G, raid5 machine running open suse linux.
>>>
>>> the kernel thinks we have 8 cores.
>>>
>>> under most circumstances, surgemail just hums along with a load
>>> average anywhere from .5 to 4, which is just fine.
>>>
>>> several times lately, we've seen the load average spike to 10 or
>>> more and remain there for several minutes, at which point i stop
>>> surgemail, wait a bit and restart.
>>>
>>> what we've determined is that there's a HUGE amount of io activity
>>> occurring when this happens and the system becomes io-bound.
>>>
>>> we've tried running iotop, but that only tells us surgemail is
>>> writing a gazillion kb per second. not very helpful. examining the
>>> logs hasn't proved to be useful either.
>>>
>>> so.......
>>>
>>> is there any diagnostic we can run to determine what's happening and
>>> why there's such a huge io load?
>>>
>>> and, can anyone give some insight as to what situation might cause
>>> this to happen in the first place?
>>>
>>> btw - we're very conservative and limit email size to 20MB, so it
>>> can't be someone trying to receive a file with a 1GB attachment. it
>>> also can't be hackers attempting to log in, as that would just
>>> generate small writes to mail.err.
>>>
>>> david camm
>>> advanced web systems
>>> keller, tx
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
|
