>
>> Dual AMD 2400 + MP cpu
>> Apache 2.0.53
>> UW Imap 2004e
>> SM 1.4.4
>> PHP 4.3.9 - 32 b memory allocation - 30 sec timeout.
>
> Is the Apache 2/PHP considered production stable yet?
The problems I whined about in the "me to" mail happened with a Redhat 8,
which I do not have the opportunity
>
> Lars Kristiansen reportedly babbled:
>>>
Dual AMD 2400 + MP cpu
Apache 2.0.53
UW Imap 2004e
SM 1.4.4
PHP 4.3.9 - 32 b memory allocation - 30 sec timeout.
>>>
>>> Is the Apache 2/PHP considered production stable yet?
>>
>> The problems I whined about in the "me to" mail
David wrote:
Dual AMD 2400 + MP cpu
Apache 2.0.53
UW Imap 2004e
SM 1.4.4
PHP 4.3.9 - 32 b memory allocation - 30 sec timeout.
Is the Apache 2/PHP considered production stable yet?
There was a big /. thread about that recently. There is some argument
about it, but there are a LOT of people who
>
>> Dual AMD 2400 + MP cpu
>> Apache 2.0.53
>> UW Imap 2004e
>> SM 1.4.4
>> PHP 4.3.9 - 32 b memory allocation - 30 sec timeout.
>
> Is the Apache 2/PHP considered production stable yet?
The problems I whined about in the "me to" mail happened with a Redhat 8,
which I do not have the opportunity
Hello Rich,
On Tuesday, March 15, 2005, Rich Hall wrote...
Have seen something similar when php hit its limits for execution-time
or memory.
[..]
>> I believe I missed the beginning of this thread, so I'm jumping in
>> mid-way, and will probably cover a few things. Have you tried
>> se
> Dual AMD 2400 + MP cpu
> Apache 2.0.53
> UW Imap 2004e
> SM 1.4.4
> PHP 4.3.9 - 32 b memory allocation - 30 sec timeout.
Is the Apache 2/PHP considered production stable yet?
David.
> No shell accounts
> Gobs of memory (4 gb)
> Server side sorting on
>
> I just have not had a lot of time to d
Hi Jonathan,
Jonathan Angliss reportedly babbled:
>
>>> Have seen something similar when php hit its limits for execution-time
>>> or memory.
>
>>> To provoce it: search all mailboxes or upload a too big file.
>>> Sorry for the little informative "me to" posting. It needs more
>>> investigating.
>> Have seen something similar when php hit its limits for execution-time
>> or memory.
>> To provoce it: search all mailboxes or upload a too big file.
>> Sorry for the little informative "me to" posting. It needs more
>> investigating.
>> For what its worth: Could more or less avoid it by givi
Rich Hall wrote:
Hi, Lars,
Lars Kristiansen reportedly babbled:
Have seen something similar when php hit its limits for execution-time or
memory.
To provoce it: search all mailboxes or upload a too big file.
Sorry for the little informative "me to" posting. It needs more
investigating.
For what it
Hi, Lars,
Lars Kristiansen reportedly babbled:
>
> Have seen something similar when php hit its limits for execution-time or
> memory.
> To provoce it: search all mailboxes or upload a too big file.
> Sorry for the little informative "me to" posting. It needs more
> investigating.
> For what its
>
> Paul Lesneiwski reportedly babbled:
>>
>> [EMAIL PROTECTED] wrote:
>>> Hi SM users,
>>>
>>> The problem:
>>>
>>> Intermittently SM would grab 100% of cpu. This was on a 4 processor
>>> machine,
>>> so /usr/bin/sar would show user-level cpu stepping up and down by 25%.
>>> Sometimes reaching al
Paul Lesneiwski reportedly babbled:
>
> [EMAIL PROTECTED] wrote:
>> Hi SM users,
>>
>> The problem:
>>
>> Intermittently SM would grab 100% of cpu. This was on a 4 processor machine,
>> so /usr/bin/sar would show user-level cpu stepping up and down by 25%.
>> Sometimes reaching all 4 cpus (100%).
[EMAIL PROTECTED] wrote:
Hi SM users,
The problem:
Intermittently SM would grab 100% of cpu. This was on a 4 processor machine,
so /usr/bin/sar would show user-level cpu stepping up and down by 25%.
Sometimes reaching all 4 cpus (100%). Systems staff would usually have to
kill the runaway process
Hi SM users,
The problem:
Intermittently SM would grab 100% of cpu. This was on a 4 processor machine,
so /usr/bin/sar would show user-level cpu stepping up and down by 25%.
Sometimes reaching all 4 cpus (100%). Systems staff would usually have to
kill the runaway process ids on Monday morning
14 matches
Mail list logo
