Fred,
> Andreas: Are you also running PostgreSQL as Jonathan and I are?
Yes, I am running the current 8.1.4 with current DBI 1.52 and DBD::Pg 1.49.
> Andreas & Jonathan: Are either of you running reiserfs? (Perhaps it is
> the filesystem causing this.)
The machine which crashes every 14 days be
IIRC, didn't we track this to Postgresql ? If so, we should
relocate to the postgresql lists.
Not officially/definitively, though i've already posted it to the
pgsql lists. ( and ruled out bsd as being the cause thanks to some
friends with NYC BSD UG )
Fred Tyler wrote:
> Linux 2.6.12.6
> Apache 1.3.33
> Postgresql 7.4.9
> mod_perl 1.29
> 350-400 viritual hosted domains, all running a mod_perl/postgres backed
> CMS.
IIRC, didn't we track this to Postgresql ? If so, we should relocate to the
postgresql lists.
--
--
> after booting a redhat enterprise linux 3 machine with apache 2.0.58,
> perl 5.8.8 and mod_perl 2.0.2,
> it runs well using about 300 M of 1 G physical RAM.
> However, the remaining RAM decreases day by day, and after 2 or 3
> weeks, the machine crashes because swapping takes too much time.
> Ho
On Wed, 6 Sep 2006 19:09:15 -0400
Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> On Sep 6, 2006, at 6:41 PM, Frank Wiles wrote:
>
> >Is that 500MB that "vanished" in used, buffers, or cached? Just
> >because it isn't listed in "free" doesn't mean it isn't "free"
> > from a "Available memo
On Sep 6, 2006, at 6:41 PM, Frank Wiles wrote:
Is that 500MB that "vanished" in used, buffers, or cached? Just
because it isn't listed in "free" doesn't mean it isn't "free" from
a "Available memory I can use" standpoint. For example, your
system
will reclaim memory from cached
On Wed, 6 Sep 2006 18:26:46 -0400
Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
>
> On Sep 6, 2006, at 6:01 PM, Frank Wiles wrote:
>
> >It didn't disappear, and it isn't "shared" like the type of
> > sharing we talk about with mod_perl/Apache. It's not CoW sharing.
> I know.
>
> >The shar
On Sep 6, 2006, at 6:01 PM, Frank Wiles wrote:
It didn't disappear, and it isn't "shared" like the type of sharing
we talk about with mod_perl/Apache. It's not CoW sharing.
I know.
The shared memory you're talking about here is held by the
postmaster
daemon and is used to store
On Wed, 6 Sep 2006 17:36:50 -0400
Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> From what I can tell, this is happening:
> bootup: ( pg ) 861 Free
> apache start: ( apache , pg , 3x pg clients ) 785 Free
> apache stop:( pg, 3x pg clients ) 840 Free
> apache start:
On Aug 18, 2006, at 6:24 AM, Andreas Rieke wrote:
Hi,
after booting a redhat enterprise linux 3 machine with apache 2.0.58,
perl 5.8.8 and mod_perl 2.0.2,
it runs well using about 300 M of 1 G physical RAM.
However, the remaining RAM decreases day by day, and after 2 or 3
weeks, the machine cra
On Fri, 2006-08-18 at 19:35 +0200, Andreas Rieke wrote:
> as the memory is even gone after apache with mod_perl has been stopped,
> I do not think that this really helps. I do know that the kernel should
> recover all the memory when processes stop even if these did not free
> the memory, thus it s
Perrin Harkins wrote:
>On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
>
>
>>it runs well using about 300 M of 1 G physical RAM.
>>However, the remaining RAM decreases day by day, and after 2 or 3
>>weeks, the machine crashes because swapping takes too much time.
>>However, all processes
Clinton Gormley wrote:
>On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
>
>
>>Hi,
>>
>>
>>
>
>
>
>>The strange thing is that all the memory is gone even after stopping all
>>apache processes.
>>The only thing which helps is to reboot the machine.
>>
>>
>>
>
>Hi Andreas
>
>Not m
Are you using the RH / SuSE versions of mp/apache and postgres ? Or
did you compile your own?
I my experience, on those systems its best to compile your own. The
packages are often way out of date and have issues that have been
solved.
I've found that running Postgres and MP on the same
Perrin Harkins wrote:
On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
it runs well using about 300 M of 1 G physical RAM.
However, the remaining RAM decreases day by day, and after 2 or 3
weeks, the machine crashes because swapping takes too much time.
However, all processes together tak
On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
> it runs well using about 300 M of 1 G physical RAM.
> However, the remaining RAM decreases day by day, and after 2 or 3
> weeks, the machine crashes because swapping takes too much time.
> However, all processes together take about 250 MByte
On Fri, 2006-08-18 at 12:24 +0200, Andreas Rieke wrote:
> Hi,
>
> The strange thing is that all the memory is gone even after stopping all
> apache processes.
> The only thing which helps is to reboot the machine.
>
Hi Andreas
Not my field of expertise, but this sounds like a kernel problem, o
> > rev 1.61
>
> "Switch to perlmalloc by
> default, unless threaded perl is built, to improve performance."
>
> > rev 1.49
>
> "WITH_PERL_MALLOC - to compile with perl's own malloc, as opposed to
>the freebsd system malloc. Some might find this useful, since perl's
>malloc is marginally
Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>> Philip M. Gollucci wrote:
>>> Philippe M. Chiasson wrote:
>>>
>> Poking [EMAIL PROTECTED] about this issue could possibly help,
>> especially if
>> the reason this was done can be shown not to apply anymore.
>>
> http://www.freebsd.org/c
Philippe M. Chiasson wrote:
Philip M. Gollucci wrote:
Philippe M. Chiasson wrote:
Poking [EMAIL PROTECTED] about this issue could possibly help, especially if
the reason this was done can be shown not to apply anymore.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/Makefi
Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>
>> I've encouontered this problem before on FreeBSD and have had some
>> success
>> working around it. One of the main problems seems to be with FreeBSD's
>> Perl
>> build picking Perl's malloc instead of the native FreeBSD malloc().
>> You
Philippe M. Chiasson wrote:
I've encouontered this problem before on FreeBSD and have had some success
working around it. One of the main problems seems to be with FreeBSD's Perl
build picking Perl's malloc instead of the native FreeBSD malloc(). You can see
how your perl is configured like this
snacktime wrote:
> Before I spend a whole lot of time on this I'm curious if someone else
> has run across this. This is mod perl 1.29.
>
> We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
> 5.8.7. This included reinstalling around 50 perl modules (some to new
> versions) from th
snacktime wrote:
Before I spend a whole lot of time on this I'm curious if someone else
has run across this. This is mod perl 1.29.
We upgraded perl on one of our freebsd 5.4 servers from 5.6.1 to
5.8.7. This included reinstalling around 50 perl modules (some to new
versions) from the freebsd
Pringle, Chris (HP-PSG) wrote:
Hi All,
Anyone experience problems with filters and large files?
I tried to download a 650MB ISO image through my proxy with a filter
enabled and it caused the box to run out of memory, thrash and
eventually panic.
Its a stream based output filter that sits in a loo
25 matches
Mail list logo
