<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
Searching on this more, I find <A HREF="http://www.westnet.com/~gsmith/content/linux-pdflush.htm">http://www.westnet.com/~gsmith/content/linux-pdflush.htm</A> <BR>
<BR>
How is this for a working hypothesis:&nbsp; <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's 3X the amount of dirty accumulated. <BR>
<BR>
According to /proc/meminfo, I'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.&nbsp;&nbsp; It's not that the system is slow, it'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.&nbsp;&nbsp; <BR>
    <BR>
    This replaced older Dell servers running I don't remember what. <BR>
    <BR>
    Both old and new servers ran about 200,000 web service queries a day using Tomcat6 and Progress OpenEdge.&nbsp;&nbsp;&nbsp;&nbsp; <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.&nbsp;&nbsp; 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. <BR>
    <BR>
    The older servers, while not as fast, didn't exhibit this behavior.&nbsp; <BR>
    <BR>
    I may be wrong about the sync being the culprit; that'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>
</BODY>
</HTML>