Skip site navigation (1) Skip section navigation (2)

Re: Which hardware ?

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Andrew Sullivan" <ajs(at)commandprompt(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Which hardware ?
Date: 2008-06-17 16:22:14
Message-ID: dcc563d10806170922m5983401ake7f70c9b88a9b9aa@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, Jun 17, 2008 at 9:42 AM, Andrew Sullivan <ajs(at)commandprompt(dot)com> wrote:
> On Tue, Jun 17, 2008 at 04:49:17PM +0200, Lionel wrote:
>> My tomcat webapp is well coded  and consumes nearly nothing.
>
> If I were ever inclined to say, "Nonsense," about code I've never
> seen, this is probably the occasion on which I'd do it.  A running JVM
> is necessarily going to use some memory, and that is memory use that
> you won't be able to factor out properly when developing models of
> your database system performance.

But if that amount of memory is 256 Megs and it only ever acts as a
control panel or data access point, it's probably not a huge issue.
If it's 2 Gig it's another issue.  It's all about scale.  The real
performance hog for me on all in one boxes has been perl / fastcgi
setups.

> The power of the system is hard to know about in the context (with
> only 8Go of memory, I don't consider this a powerful box at all,
> note).

I always think of main memory in terms of how high a cache hit rate it
can get me.  If 8G gets you a 50% hit rate, and 16G gets you a 95% hit
rate, then 16G is the way to go.  But if 8G gets you to 75% and 32G
gets you to 79% because of your usage patterns (the world isn't always
bell curve shaped) then 8G is plenty and it's time to work on faster
disk subsystems if you need more performance.

In response to

pgsql-performance by date

Next:From: Greg SmithDate: 2008-06-17 16:32:10
Subject: Re: Which hardware ?
Previous:From: Matthew WakelingDate: 2008-06-17 16:04:07
Subject: Re: Tsearch2 Initial Search Speed

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group