Are you sure this isn't because the IIS thread is still running? One thread handles multiple requests.
> -----Original Message----- > From: Michael Vergoz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 11, 2006 10:33 AM > To: Dmitry Stogov; 'Andi Gutmans'; PHPdev > Subject: Re: [PHP-DEV] FW: Help needed in benchmarking memory patch > > In fact I had found some leaks it would seem that > ts_free_thread() after > php_request_shutdown() solves all the problem. > I am checking if it's bad but if not the case the SAPI ISAPI > should have a small modification. > > mv- > ----- Original Message ----- > From: "Dmitry Stogov" <[EMAIL PROTECTED]> > To: "'Michael Vergoz'" <[EMAIL PROTECTED]>; "'Andi Gutmans'" > <[EMAIL PROTECTED]>; <internals@lists.php.net> > Sent: Tuesday, July 11, 2006 1:54 PM > Subject: RE: [PHP-DEV] FW: Help needed in benchmarking memory patch > > > > Hi Michael, > > > > The patch was tested in ZTS mode too. > > > > What SAPI you are talking about? (I would like to reproduce > the problem). > > > > Thanks. Dmitry. > > > >> -----Original Message----- > >> From: Michael Vergoz [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, July 11, 2006 1:22 PM > >> To: Andi Gutmans; internals@lists.php.net > >> Subject: Re: [PHP-DEV] FW: Help needed in benchmarking memory patch > >> > >> > >> Hi aAndy > >> > >> > We didn't find a material difference between malloc() and mmap() > >> > though, most probably because malloc() at these sizes > >> actually calls > >> > mmap(). > >> You can have good difference with the mremap() of Linux > >> because it directly > >> changes the vector into memory without recopying these data. > >> > >> -- > >> Before beginning a benchmark I would like to speak about a > >> serious problem > >> that I have with TSRM/MM. > >> > >> A S1 script carried out by thread T1 will use the same memory > >> capacity as S2 > >> script by T2 whereas theoretically separation is obligatory. > >> In addition to > >> the problem of safety, that cause also a problem of > >> management of the load > >> memory of the process father. > >> > >> We define a father process P=while(1); > >> > >> When a process father starts it must initialize tsrm_startup(), > >> sapi_startup() and php_module_startup(). At this time all the > >> additional > >> functions and objects are loaded and usable by all script > >> (what is normal). > >> > >> With the creation of a thread one associates a TSRMLS to > it. Then one > >> carries out php_request_startup(), php_execute_script() and > >> php_request_shutdown() to entirely enclose PHP/Zend. > >> > >> With the execution of Sx script in Tx: the variables > >> dynamics, static and > >> constant of this one will be stored in AG(head). > >> > >> The problem comes from there. It is impossible to destroy a > >> memory which a > >> script has just used because the process father continues to > >> turn and nor > >> php_request_shutdown(), php_module_shutdown(), sapi_shutdown() and > >> tsrm_shutdown() will not be carried out AND THUS there will > >> be a mem leak > >> > >> I am very annoyed by this problem, it is necessary that I > >> find a possibility > >> to destroy these buffer. > >> > >> Michael Vergoz > >> > >> ----- Original Message ----- > >> From: "Andi Gutmans" <[EMAIL PROTECTED]> > >> To: "'Michael Vergoz'" <[EMAIL PROTECTED]>; > >> <internals@lists.php.net> > >> Sent: Tuesday, July 11, 2006 8:26 AM > >> Subject: RE: [PHP-DEV] FW: Help needed in benchmarking memory patch > >> > >> > >> > Sorry I didn't make clear that only the malloc()/free() > part works. > >> > The > >> > mmap() and Win32 Allocation code is commented. > >> > We didn't find a material difference between malloc() and > >> mmap() though, > >> > most probably because malloc() at these sizes actually > calls mmap(). > >> > So really most important is for some ppl to run some > >> benchmarks on this. > >> > > >> > Thx. > >> > > >> > Andi > >> > > >> >> -----Original Message----- > >> >> From: Michael Vergoz [mailto:[EMAIL PROTECTED] > >> >> Sent: Monday, July 10, 2006 5:25 PM > >> >> To: Andi Gutmans; internals@lists.php.net > >> >> Subject: Re: [PHP-DEV] FW: Help needed in benchmarking > memory patch > >> >> > >> >> Hi Andi, > >> >> > >> >> I appreciated to see this code which I must still > study. Already a > >> >> small remark it is that the system call mremap() is not > >> portable it > >> >> is available only on Linux. Then the size of the segments > >> must always > >> >> "be paginated" - normally your code is good on this level. > >> >> I think that a concept of kernel-memory and user-memory can > >> >> be very interesting to study, especially in threads > >> >> environments - that I use. > >> >> > >> >> I would continue to look at your code but now I will > sleep (04:26 > >> >> pm)! > >> >> > >> >> mv- > >> >> > >> >> ----- Original Message ----- > >> >> From: "Andi Gutmans" <[EMAIL PROTECTED]> > >> >> To: "'Andi Gutmans'" <[EMAIL PROTECTED]>; <internals@lists.php.net> > >> >> Sent: Monday, July 10, 2006 5:57 PM > >> >> Subject: RE: [PHP-DEV] FW: Help needed in benchmarking > memory patch > >> >> > >> >> > >> >> > No help??? Come on guys. I'm sure some of you can spare a > >> >> few idle cycles > >> >> > :) > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Andi Gutmans [mailto:[EMAIL PROTECTED] > >> >> >> Sent: Friday, July 07, 2006 8:38 PM > >> >> >> To: internals@lists.php.net > >> >> >> Subject: [PHP-DEV] FW: Help needed in benchmarking > memory patch > >> >> >> > >> >> >> Sending 3rd time this time without the attachment. > >> >> >> You can get the diff at http://gutmans.org/alloc.zip > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Andi Gutmans [mailto:[EMAIL PROTECTED] > >> >> >> Sent: Thursday, July 06, 2006 11:06 PM > >> >> >> To: 'internals@lists.php.net' > >> >> >> Subject: Help needed in benchmarking memory patch > >> >> >> > >> >> >> Hi all, > >> >> >> > >> >> >> Attached is a patch we've been working on to improve > the memory > >> >> >> management of PHP. This patch's main advantage is > reducing the > >> >> >> memory footprint of PHP, and therefore allowing it to scale > >> >> >> better. Although at low concurrencies the change seems to be > >> >> >> negligble, while testing at higher concurrencies we saw > >> >> >> significant improvement with this patch, mainly due to lower > >> >> >> memory usage. > >> >> >> > >> >> >> We would very much appreciate if people here tested > >> this patch and > >> >> >> send in their results. It would help us understand if > >> others are > >> >> >> getting consistent results with ours, and also see > >> whether there > >> >> >> are any additional improvements we should make. > >> >> >> > >> >> >> This patch should apply cleanly to the PHP 5.2 CVS > >> tree. There's > >> >> >> not much tuning that needs to be done. It uses > >> >> >> malloc() to allocate large memory blocks. You can > >> control the size > >> >> >> of these blocks by setting the ZEND_MM_SEG_SIZE environment > >> >> >> variable before starting Apache/PHP. You may use K > or M to play > >> >> >> around with the block size. The default we are using is 256KB > >> >> >> which seems to be a good balance. > >> >> >> > >> >> >> Any feedback would be appreciated! > >> >> >> > >> >> >> Andi > >> >> >> > >> >> >> -- > >> >> >> PHP Internals - PHP Runtime Development Mailing List To > >> >> >> unsubscribe, visit: http://www.php.net/unsub.php > >> >> >> > >> >> > > >> >> > -- > >> >> > PHP Internals - PHP Runtime Development Mailing List > >> >> > To unsubscribe, visit: http://www.php.net/unsub.php > >> >> > > >> >> > > >> >> > >> > > >> > > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
