Well - to each his own I guess - we did extensive testing on 1.4, and
it refused to allocate much past 1gig on both Linux x86/x86-64 and
Windows.
AlexOn 10/11/05, Alan Stange <[EMAIL PROTECTED]> wrote:
Alex Turner wrote:> Perhaps this is true for 1.5 on x86-32 (I've only used it on x86-64)> but I
Alex Turner wrote:
Perhaps this is true for 1.5 on x86-32 (I've only used it on x86-64)
but I was more thinking 1.4 which many folks are still using.
The 1.4.x JVM's will also work just fine with much more than 1GB of
memory. Perhaps you'd like to try again?
-- Alan
On 10/11/05, *Alan
Perhaps this is true for 1.5 on x86-32 (I've only used it on x86-64)
but I was more thinking 1.4 which many folks are still using.
AlexOn 10/11/05, Alan Stange <[EMAIL PROTECTED]> wrote:
Alex Turner wrote:> Realise also that unless you are running the 1.5 x86-64 build, java> will not use more than
Alex Turner wrote:
Realise also that unless you are running the 1.5 x86-64 build, java
will not use more than 1Gig, and if the app server requests more than
1gig, Java will die (I've been there) with an out of memory error,
even though there is plenty of free mem available. This can easily be
Realise also that unless you are running the 1.5 x86-64 build, java
will not use more than 1Gig, and if the app server requests more than
1gig, Java will die (I've been there) with an out of memory error, even
though there is plenty of free mem available. This can easily be
cause by a lazy GC thre
On Tue, 2005-10-11 at 09:41 +0200, Claus Guttesen wrote:
> I have a postgresql 7.4.8-server with 4 GB ram.
>
> > #effective_cache_size = 1000# typically 8KB each
>
> This is computed by sysctl -n vfs.hibufspace / 8192 (on FreeBSD). So I
> changed it to:
>
> effective_cache_size = 27462
I have a postgresql 7.4.8-server with 4 GB ram.
> #max_fsm_pages = 2 # min max_fsm_relations*16, 6 bytes each
> #max_fsm_relations = 1000 # min 100, ~50 bytes each
If you do a vacuum verbose (when it's convenient) the last couple of
lines will tell you something like this:
INF
Jon Brisbin <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If you're not swapping then you do not have a problem.
> Except for the fact that my Java App server crashes when all the
> available memory is being used by caching and not reclaimed :-)
That's a kernel bug (or possibly a Java bug ;-)
Jon Brisbin wrote:
> Tom Lane wrote:
> >
> >Are you sure it's not cached data pages, rather than cached inodes?
> >If so, the above behavior is *good*.
> >
> >People often have a mistaken notion that having near-zero free RAM means
> >they have a problem. In point of fact, that is the way it is su
More info:
apps:/home/jbrisbin # free -mo
total used free sharedbufferscached
Mem: 8116 5078 3038 0 92 4330
Swap: 1031 0 1031
apps:/home/jbrisbin # cat /proc/meminfo
MemTotal: 8311188 kB
Tom Lane wrote:
Are you sure it's not cached data pages, rather than cached inodes?
If so, the above behavior is *good*.
People often have a mistaken notion that having near-zero free RAM means
they have a problem. In point of fact, that is the way it is supposed
to be (at least on Unix-like s
Jon,
> Any help you can give in this would be extrememly helpful as I'm very
> far from an expert on Linux filesystems and postgres tuning.
See Tom's response; it may be that you don't have an issue at all.
If you do, it's probably the kernel, not the FS. 2.6.8 and a few other
2.6.single-digit
Jon Brisbin <[EMAIL PROTECTED]> writes:
> I have a SUSE 9 box that is running Postgres 8.0.1 compiled from source.
> Over time, I see the memory usage of the box go way way up (it's got
> 8GBs in it and by the end of the day, it'll be all used up) with what
> looks like cached inodes relating to
> I have a SUSE 9 box that is running Postgres 8.0.1 compiled from source.
> Over time, I see the memory usage of the box go way way up (it's got
> 8GBs in it and by the end of the day, it'll be all used up) with what
> looks like cached inodes relating to the extreme IO generated by
>
> I was wond
I have a SUSE 9 box that is running Postgres 8.0.1 compiled from source.
Over time, I see the memory usage of the box go way way up (it's got
8GBs in it and by the end of the day, it'll be all used up) with what
looks like cached inodes relating to the extreme IO generated by
postgres. We repli
15 matches
Mail list logo
