On 26.04.2010 23:12, Ferenc Kovacs wrote:
> You are so kind. I'm so proud of you!!
> But sticking with a real world scenario:
> you have to convert what they upload, and thats pretty random.
Yes.
And there is no way to fix it.
But that doesn't mean there MUST be any leaks at all.
Btw, there are a
On Mon, Apr 26, 2010 at 8:45 PM, Antony Dovgal wrote:
> On 26.04.2010 22:25, Ferenc Kovacs wrote:
> >
> > If you have any problems with third-party libs leaking memory not
> > accounted by Zend MM, you can always lower
> > the max_requests parameter in your config file.
> >
> > Th
On 26.04.2010 22:25, Ferenc Kovacs wrote:
>
> If you have any problems with third-party libs leaking memory not
> accounted by Zend MM, you can always lower
> the max_requests parameter in your config file.
>
> That's all. Problem solved.
>
>
> Its not the best idea. If you feed
> If you have any problems with third-party libs leaking memory not accounted
> by Zend MM, you can always lower
> the max_requests parameter in your config file.
>
> That's all. Problem solved.
>
>
Its not the best idea. If you feed imagick with random images, then your
memory leak will be pretty
On 26.04.2010 19:20, looyao teng wrote:
> 2. The PHP's management of memory can't give the occupied memory
> back to the system by itself.
This is simply not true.
It does cache some blocks, but usually the memory is simply free()d.
> 3.Though the idea is good,it cannot acquiret the actual state
Thanks for your continuing discussions, as the person who
gave this suggestion, I want to express my ideas.
1. The focus of this suggesting is that to free
the occupied memory in order to memory can be used
efficiently, at the same time, system have more free memory
to allocate. This has noting
Let's start from the beginning.
How are you going to detect how much memory a thread consumes?
no ideas
There is an old patch in the Zends PAT directory http://devzone.zend.com/content/patch/pat38.txt (it reads the /proc/pid though or
fallbacks to getrusage).
Have used this for quite a tim
Op 26-4-2010 16:05, Antony Dovgal schreef:
On 26.04.2010 18:02, Jille Timmermans wrote:
memtrack could do the usual trick; stopping the current script or whatever.
and FPM could flag the process as 'over the memory limit' and can kill it as
soon as there are no other threads running in that proc
On 26.04.2010 18:02, Jille Timmermans wrote:
> memtrack could do the usual trick; stopping the current script or whatever.
> and FPM could flag the process as 'over the memory limit' and can kill it as
> soon as there are no other threads running in that process.
There are no threads in FPM or Fa
Op 26-4-2010 13:18, Jérôme Loyet schreef:
Le 26 avril 2010 13:12, Antony Dovgal a écrit :
On 26.04.2010 14:08, Jérôme Loyet wrote:
What exactly are you going to do?
Killing a process is as easy as exit(), no interfacing is needed.
and when threads are used ? You'll kill all threads at once w
Le 26 avril 2010 13:12, Antony Dovgal a écrit :
> On 26.04.2010 14:08, Jérôme Loyet wrote:
>>> What exactly are you going to do?
>>> Killing a process is as easy as exit(), no interfacing is needed.
>>
>> and when threads are used ? You'll kill all threads at once without
>> waiting them to finish
On 26.04.2010 14:08, Jérôme Loyet wrote:
>> What exactly are you going to do?
>> Killing a process is as easy as exit(), no interfacing is needed.
>
> and when threads are used ? You'll kill all threads at once without
> waiting them to finish what they're doing at the time ?
Let's start from the
Le 26 avril 2010 12:02, Antony Dovgal a écrit :
> On 26.04.2010 13:38, Jérôme Loyet wrote:
>> I see how adding limits but how can a PECL module can do process
>> management (killing) without interfacing with the corresponding SAPI ?
>
> What exactly are you going to do?
> Killing a process is as e
On 26.04.2010 13:38, Jérôme Loyet wrote:
> I see how adding limits but how can a PECL module can do process
> management (killing) without interfacing with the corresponding SAPI ?
What exactly are you going to do?
Killing a process is as easy as exit(), no interfacing is needed.
>> That's why me
Le 26 avril 2010 10:22, Antony Dovgal a écrit :
> On 26.04.2010 12:15, Jérôme Loyet wrote:
>> 2010/4/26 Antony Dovgal :
>>> On 26.04.2010 10:58, Jérôme Loyet wrote:
Le 26 avril 2010 04:02, looyao teng a écrit :
> in linux, read the /proc/self(pid)/status, and the VmRSS(real memory
hi,
I agree with Tony. Such features should be part of memtrack or the
engine but not SAPI specific.
Cheers,
2010/4/26 Antony Dovgal :
> On 26.04.2010 12:15, Jérôme Loyet wrote:
>> 2010/4/26 Antony Dovgal :
>>> On 26.04.2010 10:58, Jérôme Loyet wrote:
Le 26 avril 2010 04:02, looyao teng a
On 26.04.2010 12:15, Jérôme Loyet wrote:
> 2010/4/26 Antony Dovgal :
>> On 26.04.2010 10:58, Jérôme Loyet wrote:
>>> Le 26 avril 2010 04:02, looyao teng a écrit :
in linux, read the /proc/self(pid)/status, and the VmRSS(real memory
usage)
or VmSize(virtual memory usage) is the th
2010/4/26 Antony Dovgal :
> On 26.04.2010 10:58, Jérôme Loyet wrote:
>> Le 26 avril 2010 04:02, looyao teng a écrit :
>>> in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
>>> or VmSize(virtual memory usage) is the the memory usage of the current
>>> process.
>>
>> in
On 26.04.2010 10:58, Jérôme Loyet wrote:
> Le 26 avril 2010 04:02, looyao teng a écrit :
>> in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
>> or VmSize(virtual memory usage) is the the memory usage of the current
>> process.
>
> in fact I was looking of a cleaner w
Hello !
in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
or VmSize(virtual memory usage) is the the memory usage of the current
process.
in fact I was looking of a cleaner way to do it.
Moreover, this solution is not available on OS like *BSD...
Best reg
Le 26 avril 2010 04:02, looyao teng a écrit :
> in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
> or VmSize(virtual memory usage) is the the memory usage of the current
> process.
in fact I was looking of a cleaner way to do it.
>
> 2010/4/24 Jérôme Loyet
>>
>> 20
in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
or VmSize(virtual memory usage) is the the memory usage of the current
process.
2010/4/24 Jérôme Loyet
> 2010/4/14 Rasmus Lerdorf
> >
> > On 04/14/2010 02:01 AM, Jérôme Loyet wrote:
> > > The patch seems good (I didn
2010/4/14 Rasmus Lerdorf
>
> On 04/14/2010 02:01 AM, Jérôme Loyet wrote:
> > The patch seems good (I didn't test it yet) but I'm curious about the
> > way you check the memory real size:
> >
> > + if(zend_memory_usage(1 TSRMLS_CC) >
> > fpm_global_config.term_on_memory_
hi,
thank you for reading my suggestion, and now I hope that PHP_FPM can
add process control to prevent from system memory running out.
There are many ways to do this, my patch is to check the PHP heap memory,
this is very easy. We can also control the child process's life time, all I
need
is t
On Thu, Apr 15, 2010 at 1:36 PM, Antony Dovgal wrote:
> On 15.04.2010 15:17, Ferenc Kovacs wrote:
> > If this is the case, then it should be stable for now, isn't it?
>
> I guess you can call it that, yes.
>
> I mean this should be reflected in the pecl package status field.
Tyrael
On 15.04.2010 15:17, Ferenc Kovacs wrote:
> If this is the case, then it should be stable for now, isn't it?
I guess you can call it that, yes.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On Thu, Apr 15, 2010 at 1:08 PM, Antony Dovgal wrote:
> On 15.04.2010 15:03, Ferenc Kovacs wrote:
> > Yeah, this could be implemented there, but it seems that its not
> > actively developed, last release 0.1 beta more than a year ago.
>
> In this case 'not actively developed' means 'it works and
On 15.04.2010 15:03, Ferenc Kovacs wrote:
> Yeah, this could be implemented there, but it seems that its not
> actively developed, last release 0.1 beta more than a year ago.
In this case 'not actively developed' means 'it works and no bugs were
found/reported',
so I don't see it as a disadvantag
On Thu, Apr 15, 2010 at 10:57 AM, Antony Dovgal wrote:
> On 15.04.2010 12:54, Ferenc Kovacs wrote:
> > Adding this to FPM won't help anyway - FPM doesn't use threads.
> >
> > You meant won't hurt?
>
> No, I mean implementing it in PECL/memtrack would be better since this way
> you add it to a
On 15.04.2010 12:54, Ferenc Kovacs wrote:
> Adding this to FPM won't help anyway - FPM doesn't use threads.
>
> You meant won't hurt?
No, I mean implementing it in PECL/memtrack would be better since this way you
add it to all non-threaded SAPIs.
While adding it to FPM means that other non-t
2010/4/15 Antony Dovgal
> On 15.04.2010 12:23, Jérôme Loyet wrote:
> > 2010/4/15 Antony Dovgal :
> >> On 06.04.2010 11:11, 滕路遥 wrote:
> >>> So I suggest that if we could add a config option to PHP-FPM, so that
> >>> PHP-FPM could just kill a PHP process if it consumes too much memory
> >>> (say m
On 15.04.2010 12:23, Jérôme Loyet wrote:
> 2010/4/15 Antony Dovgal :
>> On 06.04.2010 11:11, 滕路遥 wrote:
>>> So I suggest that if we could add a config option to PHP-FPM, so that
>>> PHP-FPM could just kill a PHP process if it consumes too much memory
>>> (say more than 256M).
>>
>> I personally don
2010/4/15 Antony Dovgal :
> On 06.04.2010 11:11, 滕路遥 wrote:
>> So I suggest that if we could add a config option to PHP-FPM, so that
>> PHP-FPM could just kill a PHP process if it consumes too much memory
>> (say more than 256M).
>
> I personally don't think this belongs to any SAPI.
> How about ad
On 06.04.2010 11:11, 滕路遥 wrote:
> So I suggest that if we could add a config option to PHP-FPM, so that
> PHP-FPM could just kill a PHP process if it consumes too much memory
> (say more than 256M).
I personally don't think this belongs to any SAPI.
How about adding another ini option to PECL/memt
On Thu, Apr 15, 2010 at 9:41 AM, Jérôme Loyet wrote:
> 2010/4/15 Ferenc Kovacs :
> >
> >
> > On Thu, Apr 15, 2010 at 9:25 AM, Jérôme Loyet wrote:
> >>
> >> 2010/4/15 Ferenc Kovacs :
> >> >
> >> >
> >> > On Thu, Apr 15, 2010 at 9:09 AM, Ferenc Kovacs
> wrote:
> >> >>
> >> >>
> >> >> 2010/4/15 Jé
On Thu, Apr 15, 2010 at 9:28 AM, Michael Shadle wrote:
> On Thu, Apr 15, 2010 at 12:09 AM, Ferenc Kovacs wrote:
>
> > My suggestion is more about releasing the allocated memory as soon as
> > possible. That is, this option is similar to "max_requests".
> > PHP-FPM would kill the PHP process if t
2010/4/15 Ferenc Kovacs :
>
>
> On Thu, Apr 15, 2010 at 9:25 AM, Jérôme Loyet wrote:
>>
>> 2010/4/15 Ferenc Kovacs :
>> >
>> >
>> > On Thu, Apr 15, 2010 at 9:09 AM, Ferenc Kovacs wrote:
>> >>
>> >>
>> >> 2010/4/15 Jérôme Loyet
>> >>>
>> >>> 2010/4/15 滕路遥 :
>> >>> > We check error log after our s
On Thu, Apr 15, 2010 at 9:25 AM, Jérôme Loyet wrote:
> 2010/4/15 Ferenc Kovacs :
> >
> >
> > On Thu, Apr 15, 2010 at 9:09 AM, Ferenc Kovacs wrote:
> >>
> >>
> >> 2010/4/15 Jérôme Loyet
> >>>
> >>> 2010/4/15 滕路遥 :
> >>> > We check error log after our server crashed, and we found that php
> heap
On Thu, Apr 15, 2010 at 12:09 AM, Ferenc Kovacs wrote:
> My suggestion is more about releasing the allocated memory as soon as
> possible. That is, this option is similar to "max_requests".
> PHP-FPM would kill the PHP process if the requests a process handled
> exceed max_requests, and similarly
2010/4/15 Ferenc Kovacs :
>
>
> On Thu, Apr 15, 2010 at 9:09 AM, Ferenc Kovacs wrote:
>>
>>
>> 2010/4/15 Jérôme Loyet
>>>
>>> 2010/4/15 滕路遥 :
>>> > We check error log after our server crashed, and we found that php heap
>>> > memory is out of limit,
>>> > so I think imagick use emalloc to allocat
When allocate memory from PHP memory heap, PHP runtime check the
memory_limit which
in php.ini, but this can only give a error message and not to continue to
excute php code, it can't
control the PHP-FPM child process, my idea is that when the memory out of
limit we set,
kill this child process,
On Thu, Apr 15, 2010 at 9:09 AM, Ferenc Kovacs wrote:
>
>
> 2010/4/15 Jérôme Loyet
>
> 2010/4/15 滕路遥 :
>> > We check error log after our server crashed, and we found that php heap
>> > memory is out of limit,
>> > so I think imagick use emalloc to allocate php heap memory, to check the
>> > zend
2010/4/15 Jérôme Loyet
> 2010/4/15 滕路遥 :
> > We check error log after our server crashed, and we found that php heap
> > memory is out of limit,
> > so I think imagick use emalloc to allocate php heap memory, to check the
> > zend_memory_usage is
> > not a method for imagick, other circumstances
2010/4/15 滕路遥 :
> We check error log after our server crashed, and we found that php heap
> memory is out of limit,
> so I think imagick use emalloc to allocate php heap memory, to check the
> zend_memory_usage is
> not a method for imagick, other circumstances which occupy huge memory can
> use th
We check error log after our server crashed, and we found that php heap
memory is out of limit,
so I think imagick use emalloc to allocate php heap memory, to check the
zend_memory_usage is
not a method for imagick, other circumstances which occupy huge memory can
use this method to
ensure the syst
On 04/14/2010 02:01 AM, Jérôme Loyet wrote:
> The patch seems good (I didn't test it yet) but I'm curious about the
> way you check the memory real size:
>
> + if(zend_memory_usage(1 TSRMLS_CC) >
> fpm_global_config.term_on_memory_limit){
>
> I don't know much about th
Le 14 avril 2010 09:29, Jérôme Loyet a écrit :
> 2010/4/6 滕路遥 :
>> hi,
>>
>> We use PHP's Imagemagick extension to process images, and this would
>> consume a lot of memory under some circumstances.
>> However, the mainstream PHP's memory management is really weak, so a
>> huge amount of memory wo
2010/4/6 滕路遥 :
> hi,
>
> We use PHP's Imagemagick extension to process images, and this would
> consume a lot of memory under some circumstances.
> However, the mainstream PHP's memory management is really weak, so a
> huge amount of memory would be consumed under high server load. What's
> worse,
48 matches
Mail list logo
