(1.3.7 -> 2.0.1) and memory usage

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

(1.3.7 -> 2.0.1) and memory usage

Danilo Tuler
Hi,

I often read tweets of people saying how easy it was to migrate from 1.3.7 to 2.0.x. I envy them.
For us it was a really painful process. But after 3 weeks of work we finally did it.

The project have 62k lines of code total, stats below.

    +----------------------+-------+-------+
    | Name                 | Files |  LOC  |
    +----------------------+-------+-------+
    | Controllers          |   114 | 17348 | 
    | Domain Classes       |   129 |  4029 | 
    | Jobs                 |    11 |   273 | 
    | Services             |   134 | 22865 | 
    | Tag Libraries        |    12 |   736 | 
    | Groovy Helpers       |    19 |   513 | 
    | Java Helpers         |    18 |   901 | 
    | Unit Tests           |   116 | 14417 | 
    | Integration Tests    |     6 |   944 | 
    | Scripts              |     3 |   274 | 
    +----------------------+-------+-------+
    | Totals               |   562 | 62300 | 
    +----------------------+-------+-------+

We faced almost every kind of problem, incompatibilities, plugin upgrade issues (especially quartz and joda-time), bugs, etc.
Some problems were already known and we found discussions on the list and workarounds or bugs were already filed.
Others we filed a bug (with no response yet, http://jira.grails.org/browse/GRAILS-8782), or started discussions (with no conclusive ending, like  http://grails.1312388.n4.nabble.com/Problem-with-groupProperty-in-criteria-td4414990.html).

The most painful part was the migration of 418 unit tests.
But I'm not here to rant about this.

Memory usage in development is really high. I did a compare with a 'grails test-app' command, and the following memory settings:
GRAILS_OPTS="-Xmx1536M -Xms1536M -XX:PermSize=1024m -XX:MaxPermSize=1024m"

- grails 1.3.7: hit 700Mb heap memory, 130Mb perm gen

- grails 2.0.1: hit 1.3Gb heap memory, 230Mb perm gen

This is mostly the same app, the same test machine.
Is this normal?

Thanks,
Danilo
Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

Graeme Rocher
Administrator
On Wed, Mar 7, 2012 at 8:42 PM, Danilo Tuler <[hidden email]> wrote:

> Hi,
>
> I often read tweets of people saying how easy it was to migrate from 1.3.7
> to 2.0.x. I envy them.
> For us it was a really painful process. But after 3 weeks of work we finally
> did it.
>
> The project have 62k lines of code total, stats below.
>
>     +----------------------+-------+-------+
>     | Name                 | Files |  LOC  |
>     +----------------------+-------+-------+
>     | Controllers          |   114 | 17348 |
>     | Domain Classes       |   129 |  4029 |
>     | Jobs                 |    11 |   273 |
>     | Services             |   134 | 22865 |
>     | Tag Libraries        |    12 |   736 |
>     | Groovy Helpers       |    19 |   513 |
>     | Java Helpers         |    18 |   901 |
>     | Unit Tests           |   116 | 14417 |
>     | Integration Tests    |     6 |   944 |
>     | Scripts              |     3 |   274 |
>     +----------------------+-------+-------+
>     | Totals               |   562 | 62300 |
>     +----------------------+-------+-------+
>
> We faced almost every kind of problem, incompatibilities, plugin upgrade
> issues (especially quartz and joda-time), bugs, etc.
> Some problems were already known and we found discussions on the list and
> workarounds or bugs were already filed.
> Others we filed a bug (with no response
> yet, http://jira.grails.org/browse/GRAILS-8782), or started discussions
> (with no conclusive ending, like
>  http://grails.1312388.n4.nabble.com/Problem-with-groupProperty-in-criteria-td4414990.html).
>
> The most painful part was the migration of 418 unit tests.
> But I'm not here to rant about this.
>
> Memory usage in development is really high. I did a compare with a 'grails
> test-app' command, and the following memory settings:
> GRAILS_OPTS="-Xmx1536M -Xms1536M -XX:PermSize=1024m -XX:MaxPermSize=1024m"
>
> - grails 1.3.7: hit 700Mb heap memory, 130Mb perm gen
> http://cl.ly/0o0W43150Y390p0M243i
> http://cl.ly/0E1r0R220o2I3D0g2g0u
>
> - grails 2.0.1: hit 1.3Gb heap memory, 230Mb perm gen
> http://cl.ly/1V362s1p1o2y1d1V3P1E
> http://cl.ly/2m3t1K25111Q2K222G1V
>
> This is mostly the same app, the same test machine.
> Is this normal?

This is probably mostly down to the reloading agent and the improved
reloading capabilities. We have identified a memory leak on the
reloading agent that may improve this situation for 2.0.2.

However, if you have an example that you can attach that demonstrates
this difference we can do some profiling and further improve memory
usage. For production scenarios I expect the memory usage to be a
slightly better in Grails 2.0

Cheers


>
> Thanks,
> Danilo



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

Göran Ehrsson
On Thu, Mar 8, 2012 at 8:46 AM, Graeme Rocher wrote:

On Wed, Mar 7, 2012 at 8:42 PM, Danilo Tuler <[hidden email]> wrote:
Hi,

I often read tweets of people saying how easy it was to migrate from 1.3.7
to 2.0.x. I envy them.
For us it was a really painful process. But after 3 weeks of work we finally
did it.

The project have 62k lines of code total, stats below.

    +----------------------+-------+-------+
    | Name                 | Files |  LOC  |
    +----------------------+-------+-------+
    | Controllers          |   114 | 17348 |
    | Domain Classes       |   129 |  4029 |
    | Jobs                 |    11 |   273 |
    | Services             |   134 | 22865 |
    | Tag Libraries        |    12 |   736 |
    | Groovy Helpers       |    19 |   513 |
    | Java Helpers         |    18 |   901 |
    | Unit Tests           |   116 | 14417 |
    | Integration Tests    |     6 |   944 |
    | Scripts              |     3 |   274 |
    +----------------------+-------+-------+
    | Totals               |   562 | 62300 |
    +----------------------+-------+-------+

We faced almost every kind of problem, incompatibilities, plugin upgrade
issues (especially quartz and joda-time), bugs, etc.
Some problems were already known and we found discussions on the list and
workarounds or bugs were already filed.
Others we filed a bug (with no response
yet, http://jira.grails.org/browse/GRAILS-8782), or started discussions
(with no conclusive ending, like
 http://grails.1312388.n4.nabble.com/Problem-with-groupProperty-in-criteria-td4414990.html).

The most painful part was the migration of 418 unit tests.
But I'm not here to rant about this.

Memory usage in development is really high. I did a compare with a 'grails
test-app' command, and the following memory settings:
GRAILS_OPTS="-Xmx1536M -Xms1536M -XX:PermSize=1024m -XX:MaxPermSize=1024m"

- grails 1.3.7: hit 700Mb heap memory, 130Mb perm gen
http://cl.ly/0o0W43150Y390p0M243i
http://cl.ly/0E1r0R220o2I3D0g2g0u

- grails 2.0.1: hit 1.3Gb heap memory, 230Mb perm gen
http://cl.ly/1V362s1p1o2y1d1V3P1E
http://cl.ly/2m3t1K25111Q2K222G1V

This is mostly the same app, the same test machine.
Is this normal?

This is probably mostly down to the reloading agent and the improved
reloading capabilities. We have identified a memory leak on the
reloading agent that may improve this situation for 2.0.2.

However, if you have an example that you can attach that demonstrates
this difference we can do some profiling and further improve memory
usage. For production scenarios I expect the memory usage to be a
slightly better in Grails 2.0

Cheers



Thanks,
Danilo



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

Hi,

I know statements like this is not helping much since I don't have any hard facts/measurements, but I just want to throw in my early observations.

I put an upgraded Grails 1.3.7->2.0.1 application in production this weekend and I noticed that heap usage increased from around 700M to 850M with no other changes to the application. Max heap size was set to 800MB so I immediately hit the roof trying to start the server. I bumped it to 1024M and everything runs ok now.
PermGen usage increased from 250M to 300M but seems stable (see below).

This is a small application with 60 controllers, 70 domains and 20 services.

We have a few more 1.3.7 applications to upgrade and I will try to do better measurements before/after when I do future upgrades.

I don't have a problem with increasing heap size and the application has worked perfectly this week. It's to early to tell but I have a positive feeling that the small PermGen leaks we had in production with 1.3.7 is gone. I really really hope so! With 1.3.7 we had to restart the server once every month to avoid OOME.

Regards

/Goran Ehrsson

Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

Danilo Tuler
In reply to this post by Graeme Rocher
Hi,

This is probably mostly down to the reloading agent and the improved
reloading capabilities. We have identified a memory leak on the
reloading agent that may improve this situation for 2.0.2.
Good to know! 
However, if you have an example that you can attach that demonstrates
this difference we can do some profiling and further improve memory
usage.
It's hard to give an example because maybe it's the size of the project.

Thanks,
Danilo

Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

ACMattos
In reply to this post by Göran Ehrsson
Hi All,


I´d like to make some comments about memory leak issues. I work on a
Grails 1.3.7 app that does lots of String manipulations. I found out
that Grails is very sensitive to String manipulations (memory can´t be
garbage collected, eventually causing OOM).

To solve this issue I had to put all string manipulation code in
src/java folder. Now memory can be released and no more OOM happened
again. I also ported my app to Grails 2.0.1 (just to test the new
release of grails) and noticed that additional 100 MB of heap is
demanded by 2.0.1 version of grails. I decided to keep version 1.3.7
for a while (maybe version 2.0.2 is better than 2.0.1 and 1.3.7 - in
my case, of course) .

My adivise is: take a close look to string manipulations. It causes
memory leaks on grails.

You can take a look at "Grails x SpringMVC - performance differences"
to read more about my little cruzade... :-) It´s right bellow.


Cheers,

ACMattos

---------------------------------------------------------------------------------------------------------------

Hi All,

I´d like to share some of my experiences while tuning our Grails
application. First, let me introduce our environment:
1) Grails 1.3.7
2) Lucene 3.5.0
3) Tomcat 6.0.35

The application just run searches to lucene index and return results
to the user. Now, it doesn't use database, but sooner will... so I
could not remove Hibernate plugin.

Just because my company are new to Grails (but not to Java) I needed
to do a PoC (proof of concept) of the same project, using Spring MVC,
JSP and Java
(just a simple translation).

While runing stress tests, I noticed that Java version was faster than
grails version (40 reqs/sec for Java against 25 reqs/sec for Grails).
Besides that, memory consumption was really high. Just 10 minutes of
test and no more heap left to application works.

After our discussion on this list, I decided to put your adivises to
work. I got a profiler (3 actually) and started tuning Grails to meet
Java performance, and reduce memory footprint.

The result of this work can be seen bellow. But first, let´me two main
modifications on my grails code to save memory:

* I removed all "Build string like this: ${foo.bar}" lines of code
from the application because this kind of string building consumes
lot´s of memory;
* I moved all lucene manipulation code from groovy environment to java
(src/java, lucene*.groovy -> lucene*.java). Lucene code inside groovy
environment consumes LOTS of memory (lucene best practices were also
applied).

Now the results:

1) JMeter - 2.5.1
Users   498
Rumpup  30

2) Tomcat - 6.0.35
server.xml: connectionTimeout=3000, maxThreads=400,
maxKeepAliveRequests=100        and compression=on

3) JVM - 1.6.0_24-b07 (Oracle)
Memory: "-Xms1024M -Xmx1024M -XX:NewSize=448m -XX:MaxNewSize=448m
-XX:SurvivorRatio=6 -Xss1024K -XX:MaxPermSize=128m -server"
GC:     "-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
-XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled"

4) OS - Windows XP

A) Grails 1.3.7 Version
- Duration      : 30 min
- Throughput: 8514.64 reqs/mim
- # of Requests: 255477
- Hits per Second (AVG): 200
- Response Latencies Over Time (AVG): 3.4 sec
- Transactions per Second (AVG): 58 t/sec (search list and form search
pages) and 30 t/sec (search details page)

B) Grails 2.0.1 Version
- Duration      : 30 min
- Throughput: 7506.46 reqs/mim
- # of Requests: 225295
- Hits per Second (AVG): 187
- Response Latencies Over Time (AVG): 7.5 sec (form search page) and
1.5 sec (search list  and search details pages)
- Transactions per Second (AVG): 50 t/sec (search list and form search
pages) and 30 t/sec (search details page)

C) Java/Spring MVC/JSP Version
- Duration      : 30 min
- Throughput: 8667.02 reqs/mim
- # of Requests: 258819
- Hits per Second (AVG): 150
- Response Latencies Over Time (AVG): 0.5 sec (form search page), 4.5
sec (search details page) and 6 sec (search list page)
- Transactions per Second (AVG): 28 t/sec (search details page),  63
t/sec (form search and search list pages)

As you can see, I also tested Grails 2.0.1 version. This particular
version inspired me to write "Grails 2.0.1 strange behaviour" message
to this list. You can see the details there.

I believe Grails documentation should have some tips about
performance. If you want to put this message there, feel free for do
it. ;-)

I'm attaching a spreedsheet with full test data. This file contains
data about memory comsumption also.

Now I have arguments to support grails development.... :-)

Question and comments... Just reply this message.

Thanks for your support and help,

ACMattos.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

Graeme Rocher
Administrator
On Fri, Mar 9, 2012 at 1:28 PM, ACMattos <[hidden email]> wrote:
> Hi All,
>
>
> I´d like to make some comments about memory leak issues. I work on a
> Grails 1.3.7 app that does lots of String manipulations. I found out
> that Grails is very sensitive to String manipulations (memory can´t be
> garbage collected, eventually causing OOM).


Can you attach an example that demonstrates this issue?

Thanks

>
> To solve this issue I had to put all string manipulation code in
> src/java folder. Now memory can be released and no more OOM happened
> again. I also ported my app to Grails 2.0.1 (just to test the new
> release of grails) and noticed that additional 100 MB of heap is
> demanded by 2.0.1 version of grails. I decided to keep version 1.3.7
> for a while (maybe version 2.0.2 is better than 2.0.1 and 1.3.7 - in
> my case, of course) .
>
> My adivise is: take a close look to string manipulations. It causes
> memory leaks on grails.
>
> You can take a look at "Grails x SpringMVC - performance differences"
> to read more about my little cruzade... :-) It´s right bellow.
>
>
> Cheers,
>
> ACMattos
>
> ---------------------------------------------------------------------------------------------------------------
>
> Hi All,
>
> I´d like to share some of my experiences while tuning our Grails
> application. First, let me introduce our environment:
> 1) Grails 1.3.7
> 2) Lucene 3.5.0
> 3) Tomcat 6.0.35
>
> The application just run searches to lucene index and return results
> to the user. Now, it doesn't use database, but sooner will... so I
> could not remove Hibernate plugin.
>
> Just because my company are new to Grails (but not to Java) I needed
> to do a PoC (proof of concept) of the same project, using Spring MVC,
> JSP and Java
> (just a simple translation).
>
> While runing stress tests, I noticed that Java version was faster than
> grails version (40 reqs/sec for Java against 25 reqs/sec for Grails).
> Besides that, memory consumption was really high. Just 10 minutes of
> test and no more heap left to application works.
>
> After our discussion on this list, I decided to put your adivises to
> work. I got a profiler (3 actually) and started tuning Grails to meet
> Java performance, and reduce memory footprint.
>
> The result of this work can be seen bellow. But first, let´me two main
> modifications on my grails code to save memory:
>
> * I removed all "Build string like this: ${foo.bar}" lines of code
> from the application because this kind of string building consumes
> lot´s of memory;
> * I moved all lucene manipulation code from groovy environment to java
> (src/java, lucene*.groovy -> lucene*.java). Lucene code inside groovy
> environment consumes LOTS of memory (lucene best practices were also
> applied).
>
> Now the results:
>
> 1) JMeter - 2.5.1
> Users   498
> Rumpup  30
>
> 2) Tomcat - 6.0.35
> server.xml: connectionTimeout=3000, maxThreads=400,
> maxKeepAliveRequests=100        and compression=on
>
> 3) JVM - 1.6.0_24-b07 (Oracle)
> Memory: "-Xms1024M -Xmx1024M -XX:NewSize=448m -XX:MaxNewSize=448m
> -XX:SurvivorRatio=6 -Xss1024K -XX:MaxPermSize=128m -server"
> GC:     "-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
> -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled"
>
> 4) OS - Windows XP
>
> A) Grails 1.3.7 Version
> - Duration      : 30 min
> - Throughput: 8514.64 reqs/mim
> - # of Requests: 255477
> - Hits per Second (AVG): 200
> - Response Latencies Over Time (AVG): 3.4 sec
> - Transactions per Second (AVG): 58 t/sec (search list and form search
> pages) and 30 t/sec (search details page)
>
> B) Grails 2.0.1 Version
> - Duration      : 30 min
> - Throughput: 7506.46 reqs/mim
> - # of Requests: 225295
> - Hits per Second (AVG): 187
> - Response Latencies Over Time (AVG): 7.5 sec (form search page) and
> 1.5 sec (search list  and search details pages)
> - Transactions per Second (AVG): 50 t/sec (search list and form search
> pages) and 30 t/sec (search details page)
>
> C) Java/Spring MVC/JSP Version
> - Duration      : 30 min
> - Throughput: 8667.02 reqs/mim
> - # of Requests: 258819
> - Hits per Second (AVG): 150
> - Response Latencies Over Time (AVG): 0.5 sec (form search page), 4.5
> sec (search details page) and 6 sec (search list page)
> - Transactions per Second (AVG): 28 t/sec (search details page),  63
> t/sec (form search and search list pages)
>
> As you can see, I also tested Grails 2.0.1 version. This particular
> version inspired me to write "Grails 2.0.1 strange behaviour" message
> to this list. You can see the details there.
>
> I believe Grails documentation should have some tips about
> performance. If you want to put this message there, feel free for do
> it. ;-)
>
> I'm attaching a spreedsheet with full test data. This file contains
> data about memory comsumption also.
>
> Now I have arguments to support grails development.... :-)
>
> Question and comments... Just reply this message.
>
> Thanks for your support and help,
>
> ACMattos.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

smaldini
Hi,
Is your SpringMVC using OSIV too ? And Sitemesh ?
Disabling OSIV and Sitemesh if not needed can improve things. Using singleton controllers like SpringMVC too. If you can attach both sample projects I'll investigate these issues. In my company projects, I didn't notice something relevant yet but I can understand the frustration :(

Thanks for your feedback !

On Sun, Mar 11, 2012 at 9:48 AM, Graeme Rocher <[hidden email]> wrote:
On Fri, Mar 9, 2012 at 1:28 PM, ACMattos <[hidden email]> wrote:
> Hi All,
>
>
> I´d like to make some comments about memory leak issues. I work on a
> Grails 1.3.7 app that does lots of String manipulations. I found out
> that Grails is very sensitive to String manipulations (memory can´t be
> garbage collected, eventually causing OOM).


Can you attach an example that demonstrates this issue?

Thanks

>
> To solve this issue I had to put all string manipulation code in
> src/java folder. Now memory can be released and no more OOM happened
> again. I also ported my app to Grails 2.0.1 (just to test the new
> release of grails) and noticed that additional 100 MB of heap is
> demanded by 2.0.1 version of grails. I decided to keep version 1.3.7
> for a while (maybe version 2.0.2 is better than 2.0.1 and 1.3.7 - in
> my case, of course) .
>
> My adivise is: take a close look to string manipulations. It causes
> memory leaks on grails.
>
> You can take a look at "Grails x SpringMVC - performance differences"
> to read more about my little cruzade... :-) It´s right bellow.
>
>
> Cheers,
>
> ACMattos
>
> ---------------------------------------------------------------------------------------------------------------
>
> Hi All,
>
> I´d like to share some of my experiences while tuning our Grails
> application. First, let me introduce our environment:
> 1) Grails 1.3.7
> 2) Lucene 3.5.0
> 3) Tomcat 6.0.35
>
> The application just run searches to lucene index and return results
> to the user. Now, it doesn't use database, but sooner will... so I
> could not remove Hibernate plugin.
>
> Just because my company are new to Grails (but not to Java) I needed
> to do a PoC (proof of concept) of the same project, using Spring MVC,
> JSP and Java
> (just a simple translation).
>
> While runing stress tests, I noticed that Java version was faster than
> grails version (40 reqs/sec for Java against 25 reqs/sec for Grails).
> Besides that, memory consumption was really high. Just 10 minutes of
> test and no more heap left to application works.
>
> After our discussion on this list, I decided to put your adivises to
> work. I got a profiler (3 actually) and started tuning Grails to meet
> Java performance, and reduce memory footprint.
>
> The result of this work can be seen bellow. But first, let´me two main
> modifications on my grails code to save memory:
>
> * I removed all "Build string like this: ${foo.bar}" lines of code
> from the application because this kind of string building consumes
> lot´s of memory;
> * I moved all lucene manipulation code from groovy environment to java
> (src/java, lucene*.groovy -> lucene*.java). Lucene code inside groovy
> environment consumes LOTS of memory (lucene best practices were also
> applied).
>
> Now the results:
>
> 1) JMeter - 2.5.1
> Users   498
> Rumpup  30
>
> 2) Tomcat - 6.0.35
> server.xml: connectionTimeout=3000, maxThreads=400,
> maxKeepAliveRequests=100        and compression=on
>
> 3) JVM - 1.6.0_24-b07 (Oracle)
> Memory: "-Xms1024M -Xmx1024M -XX:NewSize=448m -XX:MaxNewSize=448m
> -XX:SurvivorRatio=6 -Xss1024K -XX:MaxPermSize=128m -server"
> GC:     "-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
> -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled"
>
> 4) OS - Windows XP
>
> A) Grails 1.3.7 Version
> - Duration      : 30 min
> - Throughput: 8514.64 reqs/mim
> - # of Requests: 255477
> - Hits per Second (AVG): 200
> - Response Latencies Over Time (AVG): 3.4 sec
> - Transactions per Second (AVG): 58 t/sec (search list and form search
> pages) and 30 t/sec (search details page)
>
> B) Grails 2.0.1 Version
> - Duration      : 30 min
> - Throughput: 7506.46 reqs/mim
> - # of Requests: 225295
> - Hits per Second (AVG): 187
> - Response Latencies Over Time (AVG): 7.5 sec (form search page) and
> 1.5 sec (search list  and search details pages)
> - Transactions per Second (AVG): 50 t/sec (search list and form search
> pages) and 30 t/sec (search details page)
>
> C) Java/Spring MVC/JSP Version
> - Duration      : 30 min
> - Throughput: 8667.02 reqs/mim
> - # of Requests: 258819
> - Hits per Second (AVG): 150
> - Response Latencies Over Time (AVG): 0.5 sec (form search page), 4.5
> sec (search details page) and 6 sec (search list page)
> - Transactions per Second (AVG): 28 t/sec (search details page),  63
> t/sec (form search and search list pages)
>
> As you can see, I also tested Grails 2.0.1 version. This particular
> version inspired me to write "Grails 2.0.1 strange behaviour" message
> to this list. You can see the details there.
>
> I believe Grails documentation should have some tips about
> performance. If you want to put this message there, feel free for do
> it. ;-)
>
> I'm attaching a spreedsheet with full test data. This file contains
> data about memory comsumption also.
>
> Now I have arguments to support grails development.... :-)
>
> Question and comments... Just reply this message.
>
> Thanks for your support and help,
>
> ACMattos.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Stéphane MALDINI
--


Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

ACMattos
In reply to this post by Graeme Rocher
Hi Graeme,

Unfortunantelly, I can´t share the code and because of the size I
can't create a quick example. But I can write a example of bad string
manipulation:

"Build string like this: ${foo.bar}"

This kind of string manipulation causes high memory consumption. This
was one (third problem in scale) of my problems.

All the other problems involves Lucene index manipulation. In my case
only searchs to index results. After I move all code to src/java this
behavour changed. Now memory is consumed and freeded whithout problem.


Cheers,

ACMattos.


On 3/11/12, Graeme Rocher <[hidden email]> wrote:

> On Fri, Mar 9, 2012 at 1:28 PM, ACMattos <[hidden email]> wrote:
>> Hi All,
>>
>>
>> I´d like to make some comments about memory leak issues. I work on a
>> Grails 1.3.7 app that does lots of String manipulations. I found out
>> that Grails is very sensitive to String manipulations (memory can´t be
>> garbage collected, eventually causing OOM).
>
>
> Can you attach an example that demonstrates this issue?
>
> Thanks
>
>>
>> To solve this issue I had to put all string manipulation code in
>> src/java folder. Now memory can be released and no more OOM happened
>> again. I also ported my app to Grails 2.0.1 (just to test the new
>> release of grails) and noticed that additional 100 MB of heap is
>> demanded by 2.0.1 version of grails. I decided to keep version 1.3.7
>> for a while (maybe version 2.0.2 is better than 2.0.1 and 1.3.7 - in
>> my case, of course) .
>>
>> My adivise is: take a close look to string manipulations. It causes
>> memory leaks on grails.
>>
>> You can take a look at "Grails x SpringMVC - performance differences"
>> to read more about my little cruzade... :-) It´s right bellow.
>>
>>
>> Cheers,
>>
>> ACMattos
>>
>> ---------------------------------------------------------------------------------------------------------------
>>
>> Hi All,
>>
>> I´d like to share some of my experiences while tuning our Grails
>> application. First, let me introduce our environment:
>> 1) Grails 1.3.7
>> 2) Lucene 3.5.0
>> 3) Tomcat 6.0.35
>>
>> The application just run searches to lucene index and return results
>> to the user. Now, it doesn't use database, but sooner will... so I
>> could not remove Hibernate plugin.
>>
>> Just because my company are new to Grails (but not to Java) I needed
>> to do a PoC (proof of concept) of the same project, using Spring MVC,
>> JSP and Java
>> (just a simple translation).
>>
>> While runing stress tests, I noticed that Java version was faster than
>> grails version (40 reqs/sec for Java against 25 reqs/sec for Grails).
>> Besides that, memory consumption was really high. Just 10 minutes of
>> test and no more heap left to application works.
>>
>> After our discussion on this list, I decided to put your adivises to
>> work. I got a profiler (3 actually) and started tuning Grails to meet
>> Java performance, and reduce memory footprint.
>>
>> The result of this work can be seen bellow. But first, let´me two main
>> modifications on my grails code to save memory:
>>
>> * I removed all "Build string like this: ${foo.bar}" lines of code
>> from the application because this kind of string building consumes
>> lot´s of memory;
>> * I moved all lucene manipulation code from groovy environment to java
>> (src/java, lucene*.groovy -> lucene*.java). Lucene code inside groovy
>> environment consumes LOTS of memory (lucene best practices were also
>> applied).
>>
>> Now the results:
>>
>> 1) JMeter - 2.5.1
>> Users   498
>> Rumpup  30
>>
>> 2) Tomcat - 6.0.35
>> server.xml: connectionTimeout=3000, maxThreads=400,
>> maxKeepAliveRequests=100        and compression=on
>>
>> 3) JVM - 1.6.0_24-b07 (Oracle)
>> Memory: "-Xms1024M -Xmx1024M -XX:NewSize=448m -XX:MaxNewSize=448m
>> -XX:SurvivorRatio=6 -Xss1024K -XX:MaxPermSize=128m -server"
>> GC:     "-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
>> -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled"
>>
>> 4) OS - Windows XP
>>
>> A) Grails 1.3.7 Version
>> - Duration      : 30 min
>> - Throughput: 8514.64 reqs/mim
>> - # of Requests: 255477
>> - Hits per Second (AVG): 200
>> - Response Latencies Over Time (AVG): 3.4 sec
>> - Transactions per Second (AVG): 58 t/sec (search list and form search
>> pages) and 30 t/sec (search details page)
>>
>> B) Grails 2.0.1 Version
>> - Duration      : 30 min
>> - Throughput: 7506.46 reqs/mim
>> - # of Requests: 225295
>> - Hits per Second (AVG): 187
>> - Response Latencies Over Time (AVG): 7.5 sec (form search page) and
>> 1.5 sec (search list  and search details pages)
>> - Transactions per Second (AVG): 50 t/sec (search list and form search
>> pages) and 30 t/sec (search details page)
>>
>> C) Java/Spring MVC/JSP Version
>> - Duration      : 30 min
>> - Throughput: 8667.02 reqs/mim
>> - # of Requests: 258819
>> - Hits per Second (AVG): 150
>> - Response Latencies Over Time (AVG): 0.5 sec (form search page), 4.5
>> sec (search details page) and 6 sec (search list page)
>> - Transactions per Second (AVG): 28 t/sec (search details page),  63
>> t/sec (form search and search list pages)
>>
>> As you can see, I also tested Grails 2.0.1 version. This particular
>> version inspired me to write "Grails 2.0.1 strange behaviour" message
>> to this list. You can see the details there.
>>
>> I believe Grails documentation should have some tips about
>> performance. If you want to put this message there, feel free for do
>> it. ;-)
>>
>> I'm attaching a spreedsheet with full test data. This file contains
>> data about memory comsumption also.
>>
>> Now I have arguments to support grails development.... :-)
>>
>> Question and comments... Just reply this message.
>>
>> Thanks for your support and help,
>>
>> ACMattos.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> SpringSource - A Division of VMware
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

Ian Roberts
On 12/03/2012 12:27, ACMattos wrote:

> Hi Graeme,
>
> Unfortunantelly, I can´t share the code and because of the size I
> can't create a quick example. But I can write a example of bad string
> manipulation:
>
> "Build string like this: ${foo.bar}"
>
> This kind of string manipulation causes high memory consumption. This
> was one (third problem in scale) of my problems.

That's not a String, it's a GString.  It acts as a closure, holding a
reference to foo, so if you do something like

session.message = "A message about ${foo.bar}"

then foo will not be garbage-collectable until the *session* expires.
Contrast this with

session.message = "A message about ${foo.bar}".toString()

which converts the GString to a String immediately and so does not hold
on to any extra references.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

ACMattos
In reply to this post by smaldini
Hi Stephane,

By the time I wrote this previous message, I wasn´t using Hibernate
yet. Today i must use it due to other requirements. Sitemesh is also
used to deal with layout requirements.

As I explained to Graeme  I can´t attach a code sample. But I can
share with you my spreedsheet if you want. Because of the size I can´t
attach to this message.


Thanks for your tips and help,

ACMattos.


On 3/11/12, Stephane Maldini <[hidden email]> wrote:

> Hi,
> Is your SpringMVC using OSIV too ? And Sitemesh ?
> Disabling OSIV and Sitemesh if not needed can improve things. Using
> singleton controllers like SpringMVC too. If you can attach both sample
> projects I'll investigate these issues. In my company projects, I didn't
> notice something relevant yet but I can understand the frustration :(
>
> Thanks for your feedback !
>
> On Sun, Mar 11, 2012 at 9:48 AM, Graeme Rocher <[hidden email]> wrote:
>
>> On Fri, Mar 9, 2012 at 1:28 PM, ACMattos <[hidden email]> wrote:
>> > Hi All,
>> >
>> >
>> > I´d like to make some comments about memory leak issues. I work on a
>> > Grails 1.3.7 app that does lots of String manipulations. I found out
>> > that Grails is very sensitive to String manipulations (memory can´t be
>> > garbage collected, eventually causing OOM).
>>
>>
>> Can you attach an example that demonstrates this issue?
>>
>> Thanks
>>
>> >
>> > To solve this issue I had to put all string manipulation code in
>> > src/java folder. Now memory can be released and no more OOM happened
>> > again. I also ported my app to Grails 2.0.1 (just to test the new
>> > release of grails) and noticed that additional 100 MB of heap is
>> > demanded by 2.0.1 version of grails. I decided to keep version 1.3.7
>> > for a while (maybe version 2.0.2 is better than 2.0.1 and 1.3.7 - in
>> > my case, of course) .
>> >
>> > My adivise is: take a close look to string manipulations. It causes
>> > memory leaks on grails.
>> >
>> > You can take a look at "Grails x SpringMVC - performance differences"
>> > to read more about my little cruzade... :-) It´s right bellow.
>> >
>> >
>> > Cheers,
>> >
>> > ACMattos
>> >
>> >
>> ---------------------------------------------------------------------------------------------------------------
>> >
>> > Hi All,
>> >
>> > I´d like to share some of my experiences while tuning our Grails
>> > application. First, let me introduce our environment:
>> > 1) Grails 1.3.7
>> > 2) Lucene 3.5.0
>> > 3) Tomcat 6.0.35
>> >
>> > The application just run searches to lucene index and return results
>> > to the user. Now, it doesn't use database, but sooner will... so I
>> > could not remove Hibernate plugin.
>> >
>> > Just because my company are new to Grails (but not to Java) I needed
>> > to do a PoC (proof of concept) of the same project, using Spring MVC,
>> > JSP and Java
>> > (just a simple translation).
>> >
>> > While runing stress tests, I noticed that Java version was faster than
>> > grails version (40 reqs/sec for Java against 25 reqs/sec for Grails).
>> > Besides that, memory consumption was really high. Just 10 minutes of
>> > test and no more heap left to application works.
>> >
>> > After our discussion on this list, I decided to put your adivises to
>> > work. I got a profiler (3 actually) and started tuning Grails to meet
>> > Java performance, and reduce memory footprint.
>> >
>> > The result of this work can be seen bellow. But first, let´me two main
>> > modifications on my grails code to save memory:
>> >
>> > * I removed all "Build string like this: ${foo.bar}" lines of code
>> > from the application because this kind of string building consumes
>> > lot´s of memory;
>> > * I moved all lucene manipulation code from groovy environment to java
>> > (src/java, lucene*.groovy -> lucene*.java). Lucene code inside groovy
>> > environment consumes LOTS of memory (lucene best practices were also
>> > applied).
>> >
>> > Now the results:
>> >
>> > 1) JMeter - 2.5.1
>> > Users   498
>> > Rumpup  30
>> >
>> > 2) Tomcat - 6.0.35
>> > server.xml: connectionTimeout=3000, maxThreads=400,
>> > maxKeepAliveRequests=100        and compression=on
>> >
>> > 3) JVM - 1.6.0_24-b07 (Oracle)
>> > Memory: "-Xms1024M -Xmx1024M -XX:NewSize=448m -XX:MaxNewSize=448m
>> > -XX:SurvivorRatio=6 -Xss1024K -XX:MaxPermSize=128m -server"
>> > GC:     "-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
>> > -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled"
>> >
>> > 4) OS - Windows XP
>> >
>> > A) Grails 1.3.7 Version
>> > - Duration      : 30 min
>> > - Throughput: 8514.64 reqs/mim
>> > - # of Requests: 255477
>> > - Hits per Second (AVG): 200
>> > - Response Latencies Over Time (AVG): 3.4 sec
>> > - Transactions per Second (AVG): 58 t/sec (search list and form search
>> > pages) and 30 t/sec (search details page)
>> >
>> > B) Grails 2.0.1 Version
>> > - Duration      : 30 min
>> > - Throughput: 7506.46 reqs/mim
>> > - # of Requests: 225295
>> > - Hits per Second (AVG): 187
>> > - Response Latencies Over Time (AVG): 7.5 sec (form search page) and
>> > 1.5 sec (search list  and search details pages)
>> > - Transactions per Second (AVG): 50 t/sec (search list and form search
>> > pages) and 30 t/sec (search details page)
>> >
>> > C) Java/Spring MVC/JSP Version
>> > - Duration      : 30 min
>> > - Throughput: 8667.02 reqs/mim
>> > - # of Requests: 258819
>> > - Hits per Second (AVG): 150
>> > - Response Latencies Over Time (AVG): 0.5 sec (form search page), 4.5
>> > sec (search details page) and 6 sec (search list page)
>> > - Transactions per Second (AVG): 28 t/sec (search details page),  63
>> > t/sec (form search and search list pages)
>> >
>> > As you can see, I also tested Grails 2.0.1 version. This particular
>> > version inspired me to write "Grails 2.0.1 strange behaviour" message
>> > to this list. You can see the details there.
>> >
>> > I believe Grails documentation should have some tips about
>> > performance. If you want to put this message there, feel free for do
>> > it. ;-)
>> >
>> > I'm attaching a spreedsheet with full test data. This file contains
>> > data about memory comsumption also.
>> >
>> > Now I have arguments to support grails development.... :-)
>> >
>> > Question and comments... Just reply this message.
>> >
>> > Thanks for your support and help,
>> >
>> > ACMattos.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>>
>>
>>
>> --
>> Graeme Rocher
>> Grails Project Lead
>> SpringSource - A Division of VMware
>> http://www.springsource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> --
> *Stéphane MALDINI*
> --
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: (1.3.7 -> 2.0.1) and memory usage

ACMattos
In reply to this post by Ian Roberts
Hi Ian,

Thanks for your explaination! Anyway, I did not change all the GString
manipulation. I only change GString to String.

So I´ll change 'I can write a example of bad string manipulation:
"Build string like this: ${foo.bar}"' to GString can cause bad side
effects like high memory usage. Use it wiselly!

Cheers,

ACMattos.

On 3/12/12, Ian Roberts <[hidden email]> wrote:

> On 12/03/2012 12:27, ACMattos wrote:
>> Hi Graeme,
>>
>> Unfortunantelly, I can´t share the code and because of the size I
>> can't create a quick example. But I can write a example of bad string
>> manipulation:
>>
>> "Build string like this: ${foo.bar}"
>>
>> This kind of string manipulation causes high memory consumption. This
>> was one (third problem in scale) of my problems.
>
> That's not a String, it's a GString.  It acts as a closure, holding a
> reference to foo, so if you do something like
>
> session.message = "A message about ${foo.bar}"
>
> then foo will not be garbage-collectable until the *session* expires.
> Contrast this with
>
> session.message = "A message about ${foo.bar}".toString()
>
> which converts the GString to a String immediately and so does not hold
> on to any extra references.
>
> Ian
>
> --
> Ian Roberts               | Department of Computer Science
> [hidden email]  | University of Sheffield, UK
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email