roger that.... i'll just sit here 24/7 watching top :-)
david
On 3/18/2016 4:44 PM, surgemail-support wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
|
