Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id A31B540DB0E for ; Wed, 28 Mar 2012 15:37:53 -0300 (ADT) Received: from smtp.01.com ([199.36.142.181]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SCxkm-0002r6-O8 for pgsql-performance@postgresql.org; Wed, 28 Mar 2012 18:37:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8490F4F5B52 for ; Wed, 28 Mar 2012 13:37:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZvGzoUIIhza for ; Wed, 28 Mar 2012 13:37:39 -0500 (CDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 638CA4F523E for ; Wed, 28 Mar 2012 13:37:39 -0500 (CDT) Received: from mail-1.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id F38C84F5B5D; Wed, 28 Mar 2012 13:37:38 -0500 (CDT) Date: Wed, 28 Mar 2012 13:37:38 -0500 (CDT) From: Joshua Berkus To: Dave Crooke Cc: postgres performance list Message-ID: <807948699.229132.1332959858793.JavaMail.root@mail-1.01.com> In-Reply-To: Subject: Re: Linux machine aggressively clearing cache MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.134.147.113] X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - FF3.0 (Linux)/7.1.3_GA_3346) X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201203/176 X-Sequence-Number: 46626 > This may just be a typo, but if you really did create write (dirty) > block device cache by writing the pg_dump file somewhere, then that > is what it's supposed to do ;) The pgdump was across the network. So the only caching on the machine was read caching. > Read cache of course does not need to be flushed and can simply be > dumped when the memory is needed, and so Linux will keep more or > less unlimited amounts of read cache until it needs the memory for > something else .... Right, that's the normal behavior. Except not on this machine. --Josh