Hello David,

Were you able to run the test again after adding some of the free()
statements back in? Did it improve the performance? I am seeing a similar
issue where the memory footprint of the apache process keeps increasing
until a point when the server becomes very unresponsive and my client starts
getting timeouts.

After a while the root apache process spawns some new processes and the
server starts responding again. But the earlier apache processes never free
up their memory. Their memory usage reaches about 60mb and kind of stays
there.

I am using Axis 1.1 with apache 2.0.59.

May be someone from the Apache team can shed some more light.


Thanks,
Subra

On 10/12/07, David Klassen <[EMAIL PROTECTED]> wrote:
>
> Thanks, I assumed that this memory would be automatically free'd. I will
> try again, stress testing then waiting for the memory to be free'd, since I
> did not  give the server a break in the action (Rather just watched the
> process memory move from 20 MB to 500MB without seeing any memory relieved).
> Over a  period of 30 minutes @ 25 requests/second.
>
> However I am very sure that a well designed server should not reach a
> 500MB process footprint. The functionality of Linux v1.1.0 single threaded
> example server (axis2_http_server), seems to have changed so as to not
> de-allocate all the memory right away. I suspect that with all the
> indentation changes and code replacements from the v1.0.0 release to 
> 1.1.0release perhaps a _free() or _FREE() function was accidentally removed in
> the process. I have already spotted one questionable place, when I scanned
> the svn diff from v1.0.0 to v1.1.0. I will test my theory tomorrow,
> attempting to read-add various free() functions where I cannot justify
> removal.
>
> ----- Original Message -----
> From: Samisa Abeysinghe <[EMAIL PROTECTED]>
> Date: Thursday, October 11, 2007 7:46 pm
> Subject: Re: Memory Issues in Sample Server Code
> To: Apache AXIS C User List <axis-c-user@ws.apache.org>
>
> > David Klassen wrote:
> > > Right this is what I have already done, using gnuthilla and
> > without
> > > gnuthilla. Unfortunately using mod_axis2.so with v1.1.0 or
> > v1.0.0
> > > causes the size of  httpd.exe to grow continually. I
> > decided to post
> > > bug  *AXIS2C-717
> > <https://issues.apache.org/jira/browse/AXIS2C-717>*
> > > detailing where the memory of httpd.exe kept growing and
> > eventually
> > > encountered an unhandled exception.
> > Please note that, even though there seems to be a growith, if
> > you keep
> > on sending requests, you would notice that, at some point, it
> > drops
> > back. This is dues to the pooling behaviors of apache. I cannot
> > recall
> > an exact number, after which it would drop, possibly you have to
> > send
> > few hundred requests.
> >
> > Samisa...
> > >
> > > ----- Original Message -----
> > > From: Dumindu Pallewela <[EMAIL PROTECTED]>
> > > Date: Thursday, October 11, 2007 2:27 pm
> > > Subject: Re: Memory Issues in Sample Server Code
> > > To: Apache AXIS C User List <axis-c-user@ws.apache.org>
> > >
> > > > Hi David,
> > > >
> > > > As we use apr pools for memory management in mod_axis2, the loss
> > > > that you see (when deployed in apache2) is most _likely_ not
> > a bug.
> > > > Rather, it should be because that is how apr pools work.
> > They do not
> > > > necessarily free up memory immediately after a pool is destroyed.
> > > >
> > > > The best way to test the apache module (If this isn't what you
> > > > already did!), is to run the client repeatedly and check if the
> > > > memory grows significantly.
> > > >
> > > > HTH,
> > > > -Dumindu.
> > > >
> > > > David Klassen wrote:
> > > > > Actually I was using both apache and the
> > axis2_http_server, of
> > > > which the axis2_http_server had less memory absorption.
> > > > Incidentally I also found a difference in the amount of memory
> > > > loss due to version of the axis2c client program used. All tests
> > > > were performed using a v1.1.0 based server on Windows. The
> > > > client programs were invoked on Linux using both v1.0.0 and
> > > > v1.1.0 of axis2c:
> > > > >
> > > > >
> > > >
> > Server                        |  v1.1.0 client   |   v1.0.0 client
> > > > > -------------------------------------------------------
> > > > >
> > > >
> > httpd.exe                    |   24K loss      |   16K loss
> > > > > axis2_http_server.exe |     8K
> > > > loss      |
> > 4K loss
> > > > >
> > > > > I then decide to try using a Windows client against a Linux
> > > > server. The windows client only used version 1.1.0.  I only
> > > > used the Linux axis2_http_server for the server but alternated
> > > > between v1.1.0 and v1.0.0. Here are the results:
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > Server                             |   v1.1.0 Window Client
> > > > >
> > > > > -------------------------------------------------------
> > > > >
> > > > > axis2_http_server v1.1.0
> > > > |         4K loss
> > > > >
> > > > > axis2_http_server v1.0.0
> > > > |         no loss
> > > > >
> > > > > I have already seen both version of the Windows server leak,
> > > > however in these tests it shows that  v1.0.0 of the Linux
> > > > server did not leak but v1.1.0 does leak. Unfortunately I need
> > > > to use the Windows server version for my implementation, so this
> > > > does not help in my case. Do you know does axis C++ v1.6 have
> > > > memory issues like this on Windows server side? I really
> > need a
> > > > version that performs well on Windows.
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: Samisa Abeysinghe <[EMAIL PROTECTED]>
> > > > > Date: Wednesday, October 10, 2007 8:23 pm
> > > > > Subject: Re: Memory Issues in Sample Server Code
> > > > > To: Apache AXIS C User List <axis-c-user@ws.apache.org>
> > > > >
> > > > >> There is are memory issues with simple axis server. We
> > got to
> > > > >> fix that.
> > > > >> In the mean time, could you please try the same tests with
> > > > httpd
> > > > >> module?I hope that would yield better results.
> > > > >>
> > > > >> Samisa...
> > > > >>
> > > > >> David Klassen wrote:
> > > > >>> I have been stress testing axis2c for performance (using the
> > > > >> echo
> > > > >>> sample service), to determine if this platform is a good
> > > > >> solution for
> > > > >>> my purposes. So far I have been attempting to debug each
> > > > >> echo.exe
> > > > >>> invocation. Each time I execute the remote client
> > > > invocation,
> > > > >> the
> > > > >>> server process increments its used memory by 4 KB. When the
> > > > >> service
> > > > >>> thread completes this memory is not deallocated. During the
> > > > >> debug
> > > > >>> session I notice that:
> > > > >>>
> > > > >>>    echo_invoke
> > > > >>>
> > > > >>> is the only DLL function called. The other echo_skeleton.c
> > > > >> memory
> > > > >>> management functions are not called:
> > > > >>>
> > > > >>>    echo_free
> > > > >>>    axis2_remove_instance
> > > > >>>
> > > > >>> Can anyone suggest how I might configure axis2c to free
> > > > memory
> > > > >> for
> > > > >>> each echo service invocation (ie. per request)?
> > > > >>
> > > > >> --
> > > > >> Samisa Abeysinghe : WSO2 WSF/PHP
> > > > >> "http://wso2.org/projects/wsf/php?WSO2 Web Services
> > > > Framework%2FPHP - Open source PHP extention for providing and
> > > > consuming Web services in PHP"
> > > > >>
> > > > >>
> > > > >> ----------------------------------------------------------
> > ----
> > > > ---
> > > > >> ----
> > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > --
> > > > Dumindu Pallewela
> > > > http://blog.dumindu.com
> > > > GPG ID: 0x9E131672
> > > >
> > > > WSO2 | http://wso2.com | "Oxygenating the Web Service Platform"
> > > >
> > > >
> >
> >
> > --
> > Samisa Abeysinghe : WSO2 WSF/PHP
> > "http://wso2.org/projects/wsf/php?WSO2
>  Web Services Framework%2FPHP - Open source PHP extention for providing and 
> consuming Web services in PHP"
> >
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Reply via email to