Hi all,
I have a problem with segmentation faults which I've been unsuccessful
at solving so far. These only occure when running the handler+filter in
a threaded worker-mpm setup, a preforked environment does not have any
problems.
First, the environment. I am running on Debian Etch, with Ap
Perrin Harkins wrote:
Are you sure about that? On Linux, prefork is likely to perform
better. Threads will use up a lot more memory, and be slow to spawn.
I think you should try a little benchmarking before you put a lot more
time into using threads.
You are correct in that performance (cpu u
Perrin Harkins wrote:
No, it's just the opposite. Using prefork won't save CPU, but it will
save memory, meaning you can run more perl interpreters.
I'm sorry, but I have to disagree here - especially with the
configuration I need. Let's take the server with 1 GB of memory as an
example.
W
Torsten Foertsch wrote:
These figures match my observations. It also means that you are not using big
content generators in the response phase like Catalyst.
Correct. Response content is generated by backend servers, which is then
delivered to clients either from the local cache, or via mod_pr
Perrin Harkins wrote:
If what you're saying is that you can't separate out the mod_perl bits
with a proxy because they do things like authentication, you might be
That's unfortunately exactly the problem. It's not authentication, but
the mod_perl bits are still required before proxying can be
Perrin Harkins wrote:
> Honestly, the person who has done the most work on debugging thread
> crashes is Torsten. His advice on how to debug it will be better than
> mine. It does seem like people usually solve them by using backtrace
> analysis though.
Getting back to this, I've now had time t
Try "PerlInterpScope request" and see if the coredumps disappear. Further
check if it's always this place.
PerlInterpScope request did not help. I just tested, and still got a
segfault.
As far as I have seen, all the segfaults seem to be mgv related, but not
at the exact same spot.
One odd
Reif Peter wrote:
Unfortunately you cannot tell $r->read to read just all of the data, you
must provide a length.
How do I solve this problems.
$r->read will return 0 when no more data is available. I have been using
the following simple code with success:
my $postdata = "";
while ($r->read
Jani M. wrote:
As far as I have seen, all the segfaults seem to be mgv related, but not
at the exact same spot.
I've still been trying to identify the root cause of the crashes, but
unfortunately haven't had success yet. Some of the things I've tried so far:
- Different
Jani M. wrote:
I've still been trying to identify the root cause of the crashes, but
unfortunately haven't had success yet.
Looks like success at last. I managed to tune my test environment server
load from <30 requests/s to 500+ requests/s. This in turn started
producing seg
Torsten Foertsch wrote:
Try $r->push_handlers(PerlFixupHandler => 'My::fixup_handler').
Doesn't make any difference unfortunately. Strange though, when I use
the hard reference \&fixup_handler, the lookup-errors (which are
sometimes corrupted) in the log still display as My::fixup_handler.
11 matches
Mail list logo