experiencing Out of memory errors

2011-01-26 Thread John Deighan

We have an Apache/mod_perl application running under Windows Server 2003
that periodically experiences
"Out of memory" errors (they appear in the Apache error logs) which
forces Apache to restart. Our application does, in fact, use a lot of
memory, and we believe that this is not due to a bug or memory leak.
What we would like is to run this application in a 64 bit environment, thus
allowing us to use more than the 2 GB memory that the Apache process ('httpd')
is limited to (the "Out of memory" errors always occur as the memory usage
of the httpd process approaches this 2 GB limit).

We know that we will need to run a 64 bit version of Windows on 64 bit
hardware to accomplish this. Furthermore, we know that ActiveState has a
binary Perl install of a 64 bit Perl. However, we're not aware of either a
64 bit Apache (though recently I found the blackdot site -
http://www.blackdot.be/ - that provides a Windows compatible binary build
of 64 bit apache, though I know very little about it) or a 64 bit mod_perl.
However, we're also not sure if either of these are needed to escape the
2 GB memory limitation. E.g., can 64 bit Perl be used with a 32 bit
Apache and/or mod_perl?

Any help with accomplishing what we need would be greatly appreciated,
including the possibility of hiring someone on a contract basis to
help us.



OS: Microsoft Windows Server 2003
Perl: v 5.8.9 ActiveState build 826
Apache 2.2.11
mod_perl 2 (not sure of the exact version, but very recent)


Re: experiencing Out of memory errors

2011-01-27 Thread John Deighan
I'd forgotten about Strawberry Perl (came across it about a year ago, but never got around to trying 
it). One question, though: I'm thinking there's not much point to using a 64-bit version of mod_perl 
unless I'm using it with a 64-bit version of Apache. Where can I get a 64-bit version of Apache that 
will with with the mod_perl below?


On 1/27/2011 6:57 AM, Michiel Beijen wrote:

Hi John,

... etc.

If you would want to switch to StrawberryPerl 5.12.x 64-bit, you can use
this pre-compiled mod_perl:
http://strawberryperl.com/package/kmx/mod_perl/

--
Mike


Re: HTTP and MPM support

2019-01-29 Thread John Deighan
We also use threads without any problem in production. Main use is sharing
caches so that multiple mod_perl interpreters don'teach store the same
cached information. Following a few simple and documented rules, we've had
no issues with using threads.

On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman  wrote:

>
>
> > On 28 Jan 2019, at 23:00, Paul B. Henson  wrote:
> >
> > On 1/28/2019 1:53 PM, Mark Blackman wrote:
> >> https://perldoc.perl.org/threads.html#WARNING  Threads are discouraged
> in Perl these days
> >
> > Yes, that is indeed what the documentation says; however, there is a far
> cry between "Perl is single-threaded by design and history and has no
> reliable support for threading" and "use of threads is discouraged in perl".
> >
> > Looking back to the original discussion that led to that caveat
> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
> a good summary of why it is there is:
> >
> > "The patch came about because unmanaged expectations of support are
> causing social problems"
> >
> > And further discussion about it
> https://www.perlmonks.org/?node_id=1107534 has a similar insight:
> >
> > "that this particular formulation is just smoke and mirrors to repel
> 'annoying newbies"
> >
> > Then in this bug discussing the verbiage
> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer
> comments:
> >
> > "The fact is that threads work, they are maintained, and they currently
> do not have any bugs preventing their use."
> >
> > Basically, perl threads are heavyweight, not lightweight, and use of
> non-thread safe Perl code whether your own or in third-party modules will
> cause potentially nondeterministic problems. The warning is basically there
> to scare away people who don't have sufficient expertise to make it work
> and will likely come complain and ask for help with something the
> developers don't want to have to explain over and over again.
> >
> > Back when I was running DCE/DFS and maintaining the perl modules on top
> of that, I used threaded perl heavily with no issues. As long as the
> mechanism of and caveats regarding Perl threads are understood, and there
> is a justifiable reason to be using them rather than some other construct,
> discouraged is not deprecated nor unavailable/unreliable.
>
> "Threads are implemented in a way that make them easy to misuse." ==
> "single threaded by design” in my book, but your mileage may vary. I
> believe threads were retrofitted to Perl and I see very little use of
> threads in the wild myself. Relying on threads in Perl with real-world
> third-party XS modules that aren’t thread-safe is equivalent to unreliable.
> Base Perl might be safe enough, but nobody runs real-world apps with pure
> Perl alone IME.
>
> I am glad you made threads work well in production, but I suspect you’re
> in a minority.
>
> - Mark
>
>
>
>