<p dir="ltr">I would also make sure the disk io scheduler is set to deadline.</p>
<p dir="ltr">-Erik-</p>
<div class="gmail_quote">On Jan 21, 2014 9:18 PM, &quot;Neal Rhodes&quot; &lt;<a href="mailto:neal@mnopltd.com">neal@mnopltd.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>


  
  

<div>
Searching on this more, I find <a href="http://www.westnet.com/~gsmith/content/linux-pdflush.htm" target="_blank">http://www.westnet.com/~gsmith/content/linux-pdflush.htm</a> <br>
<br>
How is this for a working hypothesis:  <br>
<br>
Old Dell servers were 8GB, and I think our DB buffering might have used 2GB of that. <br>
<br>
New Dell servers are 24GB, and Progress OpenEdge is 64 bit, and uses a good bit more buffer space. <br>
<br>
<b>/proc/sys/vm/dirty_background_ratio</b> is the same 10%, but that&#39;s 3X the amount of dirty accumulated. <br>
<br>
According to /proc/meminfo, I&#39;ve seen Dirty: over 3013kB. <br>
<br>
It would seem that dropping <b>/proc/sys/vm/dirty_background_ratio</b> to 6% might be worth a stab to see if it evens out the peak sync times.   It&#39;s not that the system is slow, it&#39;s just when we bust through a 3 second SLA the client goes bat-crazy. <br>

<br>
On Tue, 2014-01-21 at 20:57 -0500, Neal Rhodes wrote:<br>
<blockquote type="CITE">
    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.   <br>
    <br>
    This replaced older Dell servers running I don&#39;t remember what. <br>
    <br>
    Both old and new servers ran about 200,000 web service queries a day using Tomcat6 and Progress OpenEdge.     <br>
    <br>
    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&#39;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. <br>

    <br>
    The older servers, while not as fast, didn&#39;t exhibit this behavior.  <br>
    <br>
    I may be wrong about the sync being the culprit; that&#39;s what the timings in the DB logs seem to indicate. <br>
    <br>
    Is there any tuning parameters which would affect the amount of time for a sync to complete on a busy server? <br>
    <br>
    Neal Rhodes<br>
    MNOP Ltd. <br>
    <br>
    <br>
</blockquote>
<br>
</div>

<br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div>