[Dovecot] IO rate quotas?

[Robert Schetterer]

Am 09.04.2011 00:25, schrieb Stan Hoeppner:
> Eric Shubert put forth on 4/8/2011 12:03 PM:
>> On 04/08/2011 08:58 AM, Stan Hoeppner wrote:
>>> Eric Shubert put forth on 4/7/2011 9:54 PM:
>>>
>>>> Thanks for the great explanation, Stan.
>>>>
>>>> Just to clarify, did you mean to say that the former is cheaper in $$?
>>>
>>> Yes.  I just noticed that error and cringed.  :(  I did indeed mean to
>>> say FORMER.  With a caveat however:  only if the necessary traffic
>>> shaping can be accomplished with FOSS running on the Dovecot server and
>>> the man hours to implement and test it are relatively low.
>>>
>>> If total man hours are more than a couple of days, or you end up needing
>>> another box for shaping duty, or worse a commercial vendor solution,
>>> then simply adding spindles to the current server may be cheaper
>>> overall, and would offer additional benefits (speed/capacity increase)
>>> for all users as well.
>>>
>>
>> I would hope that traffic shaping could be done in an affordable manner,
>> like you say with FOSS on the Dovecot server.
> 
>>From Javier's post it would seem this solution will indeed be man hour
> intensive. :(
> 
>> As Timo pointed out, there might be some other tuning that needs to be
>> addressed as well. This could be as simple as changing the elevator, or
>> doing some of the other 4 things you mentioned previously.
> 
> Choice of elevator is as much dependent upon the block path hardware as
> the workload, maybe more so.  Deadline works well for single disks and
> mdraid, but with many caching hardware RAID controllers and with FC or
> iSCSI SAN controllers, noop will often outperform deadline. 

just for info not to flame

however deadline sometimes is recommended for performance on some
3ware raid controllers, be aware you can run into troubles

https://www.3ware.com/3warekb/article.aspx?id=10889

try carefully !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

i recent found that with drbd ocfs2 and 3ware
quiet nohz=off cpufreq=no elevator=deadline
in grub is needed, by buggy 3ware
( elevator is optional but raises performance )

info

http://kerneltrap.org/mailarchive/linux-kernel/2010/9/21/4622280/thread

it took me weeks of debugging. so definite dont recommend
some 3ware controllers at present


 I think
> everyone "in the know" would agree that CFQ sucks pretty much across the
> board.  Thus, always test each elevator in a production setting and
> gather real metrics.  Then select the overall best performer.  In some
> cases all of them may perform equally well.  The greater the load, the
> more dramatic the differences.
> 
>> BL, one client should not be able to bring a server to its knees. ;)
> 
> I don't believe this is what is happening.  It appears to me that the
> OP's Dovecot server is likely "close to the edge", and when the
> described scenario occurs, the rouge IMAP client is simply pushing the
> host off the cliff, causing _everything_ to come to a crawl: the server,
> the clients, and the rogue client.  Given that he's seeing load of 50
> there's probably more going on than what we've been told.  The host is
> likely going heavily into swap, and/or the disk subsystem is simply not
> sized to carry the extra IOPS demanded.  If both are true you have a
> "perfect storm" hitting the block IO hardware.

i found dovecot isnt so much in trouble with io as one might think
with 3000 mailboxes on drbd ocfs2 3ware raid without deadline and heavy
traffic
but apache squirrelmail was nearly unusable
without deadline having vhost and logging on drbd

> 
> To playfully (respectfully) contradict the notion that one client should
> not be able to bring a server to its knees, take one client and perform
> a full text search for "sualcatnas" of a 5GB shared IMAP folder and sub
> folders residing on maildir storage.  Do this on a dual core production
> server w/4GB RAM and 4 disks in hardware RAID10, i.e. a low end system
> that normally serves 50-150 users, during peak normal usage--first thing
> in the morning or right after lunch.

agree never noticed one client getting the server into troubles

> 
> I think you'll find that this one client operation can definitely bring
> the server's IO subsystem to its knees for a short time, or at minimum
> increase response times of other clients to a very conspicuous degree.
> FTS causes massive head seeking with maildir storage, and if the disk
> subsystem isn't sized accordingly, knees hit the pavement.
> 
> Anyway, I think we really need more data from the OP to enable us to
> give definitive advice.
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria