time - while your move to ssd is certainly a good one - our newest web
server has a 500GB raid10 array with hot spare and it's a screamer - i
don't think this is the problem. what we're seeing is sporadic
instances of huge write volumes, and restarting, whenever we've had to
do it, is almost instantaneous.
david camm
advanced web systems
keller, tx
On 3/18/2016 3:11 PM, Tim Meyer wrote:
> May be a bit off topic, but I was having huge slowdowns due to disc activity
> running 100%. Would re-start and Surgemail was taking over 10 minutes to
> come up and fully running. We would have to do these re-starts about 4 or 5
> times a week. We have slightly over 1,000 accounts and 500GB storage
> (Windows).
>
> 2 weeks ago we replaced the system drive with Surgemail on it with a Samsung
> Evo 850 1T SSD ($307.00US). System now comes up in under 20 seconds to full
> running. Have had NO slow downs. When monitoring, sys drive very seldom hits
> 100%, and only for a second. I would have to say this is the biggest
> improvement I have seen in system performance on Surge since we started
> using Surge some 8 years ago. System runs a lot cooler too.
>
>
> ------------------------------------------------------------
> Tim Meyer
> CEO, JTM MultiMedia, Inc.
> 515.277.1990
> http://JTMWeb.com
>
> -----Original Message-----
> From: Jim Lohiser [mailtoHIDDEN@2net.net]
> Sent: Friday, March 18, 2016 2:52 PM
> To: surgemailHIDDEN@etwinsite.com
> Subject: RE: [SurgeMail List] huge io spikes lead to huge load average
>
> 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
>>
>>
>>
>>
>
>
>
>
|
