Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 27EAD9F9AD7 for ; Mon, 20 Nov 2006 02:43:53 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 35875-01 for ; Mon, 20 Nov 2006 02:43:49 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from 66-226-76-106.dedicated.abac.net (66-226-76-106.dedicated.abac.net [66.226.76.106]) by postgresql.org (Postfix) with ESMTP id 454419F94F3 for ; Mon, 20 Nov 2006 02:43:49 -0400 (AST) Received: (qmail 18305 invoked by uid 2020); 19 Nov 2006 23:45:07 -0800 Received: from wsip-70-167-125-69.sd.sd.cox.net (HELO ?192.168.0.3?) (70.167.125.69) by 66-226-76-106.dedicated.abac.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Nov 2006 23:45:07 -0800 Message-ID: <45614E3F.4080008@modgraph-usa.com> Date: Sun, 19 Nov 2006 22:42:07 -0800 From: "Craig A. James" User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Bruno Wolff III , "Craig A. James" , pgsql-performance@postgresql.org, mstone+postgres@mathom.us Subject: Re: Postgres server crash References: <19583.1163700841@sss.pgh.pa.us> <20061119184105.GC2366@mathom.us> <4560D6B1.8060306@modgraph-usa.com> <20061120015952.GA10935@wolff.to> In-Reply-To: <20061120015952.GA10935@wolff.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.853 tagged_above=0 required=5 tests=AWL, BAYES_50, HELO_DYNAMIC_IPADDR2 X-Spam-Level: ** X-Archive-Number: 200611/168 X-Sequence-Number: 21938 We're getting off-topic for this group except that this is *why* we're plagued with this problem, so I'll make one more observation. Bruno Wolff III wrote: >> They would allocate >> 100's of GB of swap space rather than taking the time to design proper data >> structures. If the program crashed every week or two, no big deal -- just >> run it again. Overallocating memory is a valuable technique for such >> applications. > > I don't think the above applies generally. Programmers need to be aware of > the working set of CPU bound apps. If the program is constantly paging, > the performance is going to be abysmal. You're doing planetary number crunching, so you allocate an (x,y,z) space with 10^6 points on every axis, or 10^18 points, for roughly 2^60 64-bit floating-point numbers, or 2^68 bytes. But your space is mostly empty (just like real space). Where there's a planet or star, you're actually using memory, everywhere else, the memory is never referenced. So you're using just an ordinary amount of memory, but you can access your planet's data by simply referencing a three-dimensional array in FORTRAN. Just allow infinite overcommit, let the OS do the rest, and it actually works. A lot of molecular modeling works this way too. This is how these applications were/are actually written. I'm not defending the method, just point out that it's real and it's one of the reasons virtual swap was invented. Craig