so...
stop surge
cd /var
mkdir work
chmod 700 work
chown mail:mail work
edit surgemail.ini and change g_work
start surge
should do it.
i guess it's something we can try.
david camm
advanced web systems
keller, tx
On 3/18/2016 2:52 PM, Jim Lohiser wrote:
> David,
>
> You might want to trying moving the SurgeMail work directory onto the same partition as the mailstore and then setting g_work to that path. If your server gets a large influx of mail, it will need to copy the files from one partition to the other if work and mailstore are on different partitions. If they are on the same partition, then the filesystem should just need to update the indexes and not actually move the data, which is a lost faster and uses a lot less IO.
>
> Jim Lohiser
> N2Net
>
> -----Original Message-----
> From: David Camm [mailtoHIDDEN@advwebsys.com]
> Sent: Friday, March 18, 2016 3:47 PM
> To: surgemailHIDDEN@etwinsite.com
> Subject: Re: [SurgeMail List] huge io spikes lead to huge load average
>
> On 3/18/2016 2:39 PM, Jim Lohiser wrote:
>> David,
>>
>> Is all of SurgeMail on the same partition in Linux?
> the code is in the / partition and the mailstore is in a different one.
> we've been running like that since the dmail days.
>> Do you have any users with 10s of thousands of emails in one folder?
> well, i actually discovered one today. in fact, there may be more, but
> why would that cause huge amounts of write activity?
>> Jim Lohiser
>> N2Net
>>
>> -----Original Message-----
>> From: David Camm [mailtoHIDDEN@advwebsys.com]
>> Sent: Friday, March 18, 2016 3:37 PM
>> To: SurgeMail List
>> Subject: [SurgeMail List] huge io spikes lead to huge load average
>>
>> 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
>>
>>
>>
>>
>
|
