[ale] thoughts on reducing Sync time for 2.6.32 System?

[Neal Rhodes]

Searching on this more, I find
http://www.westnet.com/~gsmith/content/linux-pdflush.htm 

How is this for a working hypothesis:  

Old Dell servers were 8GB, and I think our DB buffering might have used
2GB of that. 

New Dell servers are 24GB, and Progress OpenEdge is 64 bit, and uses a
good bit more buffer space. 

/proc/sys/vm/dirty_background_ratio is the same 10%, but that's 3X the
amount of dirty accumulated. 

According to /proc/meminfo, I've seen Dirty: over 3013kB. 

It would seem that dropping /proc/sys/vm/dirty_background_ratio to 6%
might be worth a stab to see if it evens out the peak sync times.   It's
not that the system is slow, it's just when we bust through a 3 second
SLA the client goes bat-crazy. 

On Tue, 2014-01-21 at 20:57 -0500, Neal Rhodes wrote:

> So, the context is a pair of new Dell 24 core servers installed this
> year, running 2.6.32-431.1.2.0.1.el6.x86_64.   
> 
> This replaced older Dell servers running I don't remember what. 
> 
> Both old and new servers ran about 200,000 web service queries a day
> using Tomcat6 and Progress OpenEdge.     
> 
> The new servers, while faster at DB updates, will several times a
> month, usually during prime high volumes in early afternoon, exhibit a
> period of 3 seconds of all DB updates being frozen.   When we've
> chased it down, it seems the DB has completed a checkpoint, and issued
> a sync call afterwards, and that freezes everyone until it completes. 
> 
> The older servers, while not as fast, didn't exhibit this behavior.  
> 
> I may be wrong about the sync being the culprit; that's what the
> timings in the DB logs seem to indicate. 
> 
> Is there any tuning parameters which would affect the amount of time
> for a sync to complete on a busy server? 
> 
> Neal Rhodes
> MNOP Ltd. 
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140121/6b8a43dc/attachment.html>