Re: [Pharo-dev] Growing large images: the case of Moose models
Le 3 mars 2017 13:56, "Clément Bera" <bera.clement@gmail.com> a écrit : On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com
wrote:
On 03/03/2017 11:56, Clément Bera wrote:
Hello everyone,
This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size.
To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs.
Using the stable Pharo VM, the analysis results were the following: - total time spent to load the Model: 2 minutes - time spent in full GC: 1 minute (4 fullGCs) - time spent in scavenges[1]: 15 seconds On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code.
We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds.
In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds.
Overall, loading the model is now taking ~50 seconds instead of 2 minutes.
To increase Eden size, one needs to run a script similar to:
| currentEdenSize desiredEdenSize | currentEdenSize := Smalltalk vm parameterAt: 44. desiredEdenSize := currentEdenSize * 4. Smalltalk vm parameterAt: 45 put: desiredEdenSize.
_*And then restart the image.*_
I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. _* *_ Best,
Clement
[1] A scavenge is basically the garbage collection of only young objects [2] Eden is basically the space where objects are initially allocated. [3] All numbers in the report are order of magnitudes and not precise numbers
Hi,
This is great! We will probably try it soon on our models.
Guillaume had a question also, what is the counterparty if we let the EdenSize at this size when we are not loading/exporting a MSE?
There are 2 main counterparts: - You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste 8Mb. - The user-pauses for scavenges may be more significant. There are customers using 64Mb Eden in production. It improves their performance, they do not care about wasting 60Mb on machine with 16Gb RAM and their application does heavy computation and does not need to be that responsive. However for UI applications (typically the IDE), the scavenge pauses may become significant enough to be noticed by the programmer. Maybe not at 12Mb, but certainly at 64Mb. For your case: - Do you care that your application use some more Mb of RAM ? - Do you care if your application takes a couple extra ms to answer a request ? (In any case, the full GC takes much more time and also delays the answer right now) If you don't care, you can use larger Eden. In any case, an Eden of 12 or 16 Mb should be safe. There are other settings that can be useful in your case. I will try to write a post about it.
Because in our case we deploy a server that might need to read some MSE. We cannot restart it with our current solution. In that case it would be good to have more info to select the best EdenSize for the server.
Thank you!
I have images that do not shrink with the new compactor and as there are no leaks I am wondering if there is a way for me to diagnose why this happens. I am routinely loading 100MB XML in the image but these are only transient. Shrinking works with a Pharo6 image but not with a 5.0 based. Strange. Anyone willing to pair over the internet to have a look? It is annoying because I am providing those images to customers and an ever growing thing is not really great especially with a non standard tech I am trying to push forward there. Phil
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Hi Phil, On Fri, Mar 3, 2017 at 5:04 AM, philippe.back@highoctane.be < philippe.back@gmail.com> wrote:
Le 3 mars 2017 13:56, "Clément Bera" <bera.clement@gmail.com> a écrit :
On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
On 03/03/2017 11:56, Clément Bera wrote:
Hello everyone,
This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size.
To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs.
Using the stable Pharo VM, the analysis results were the following: - total time spent to load the Model: 2 minutes - time spent in full GC: 1 minute (4 fullGCs) - time spent in scavenges[1]: 15 seconds On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code.
We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds.
In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds.
Overall, loading the model is now taking ~50 seconds instead of 2 minutes.
To increase Eden size, one needs to run a script similar to:
| currentEdenSize desiredEdenSize | currentEdenSize := Smalltalk vm parameterAt: 44. desiredEdenSize := currentEdenSize * 4. Smalltalk vm parameterAt: 45 put: desiredEdenSize.
_*And then restart the image.*_
I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. _* *_ Best,
Clement
[1] A scavenge is basically the garbage collection of only young objects [2] Eden is basically the space where objects are initially allocated. [3] All numbers in the report are order of magnitudes and not precise numbers
Hi,
This is great! We will probably try it soon on our models.
Guillaume had a question also, what is the counterparty if we let the EdenSize at this size when we are not loading/exporting a MSE?
There are 2 main counterparts: - You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste 8Mb. - The user-pauses for scavenges may be more significant.
There are customers using 64Mb Eden in production. It improves their performance, they do not care about wasting 60Mb on machine with 16Gb RAM and their application does heavy computation and does not need to be that responsive.
However for UI applications (typically the IDE), the scavenge pauses may become significant enough to be noticed by the programmer. Maybe not at 12Mb, but certainly at 64Mb.
For your case: - Do you care that your application use some more Mb of RAM ? - Do you care if your application takes a couple extra ms to answer a request ? (In any case, the full GC takes much more time and also delays the answer right now) If you don't care, you can use larger Eden. In any case, an Eden of 12 or 16 Mb should be safe.
There are other settings that can be useful in your case. I will try to write a post about it.
Because in our case we deploy a server that might need to read some MSE. We cannot restart it with our current solution. In that case it would be good to have more info to select the best EdenSize for the server.
Thank you!
I have images that do not shrink with the new compactor and as there are no leaks I am wondering if there is a way for me to diagnose why this happens. I am routinely loading 100MB XML in the image but these are only transient.
First of all run the attached shell script on your image and report back what the "freespace" field value us. In the old compactor this would usually be tens to hundreds of kilobytes. With the new compactor this should be zero or perhaps a few hundred bytes (and I suspect the few hundred bytes should only show up in Newspeak images).
Shrinking works with a Pharo6 image but not with a 5.0 based. Strange.
Look at the vm parameters for growth and shrinkage.
Anyone willing to pair over the internet to have a look?
Yes, but sometime next week.
It is annoying because I am providing those images to customers and an ever growing thing is not really great especially with a non standard tech I am trying to push forward there.
Phil
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- _,,,^..^,,,_ best, Eliot
Eliot, Script? Best, Phil On Fri, Mar 3, 2017 at 5:05 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Phil,
On Fri, Mar 3, 2017 at 5:04 AM, philippe.back@highoctane.be < philippe.back@gmail.com> wrote:
Le 3 mars 2017 13:56, "Clément Bera" <bera.clement@gmail.com> a écrit :
On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
On 03/03/2017 11:56, Clément Bera wrote:
Hello everyone,
This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size.
To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs.
Using the stable Pharo VM, the analysis results were the following: - total time spent to load the Model: 2 minutes - time spent in full GC: 1 minute (4 fullGCs) - time spent in scavenges[1]: 15 seconds On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code.
We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds.
In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds.
Overall, loading the model is now taking ~50 seconds instead of 2 minutes.
To increase Eden size, one needs to run a script similar to:
| currentEdenSize desiredEdenSize | currentEdenSize := Smalltalk vm parameterAt: 44. desiredEdenSize := currentEdenSize * 4. Smalltalk vm parameterAt: 45 put: desiredEdenSize.
_*And then restart the image.*_
I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. _* *_ Best,
Clement
[1] A scavenge is basically the garbage collection of only young objects [2] Eden is basically the space where objects are initially allocated. [3] All numbers in the report are order of magnitudes and not precise numbers
Hi,
This is great! We will probably try it soon on our models.
Guillaume had a question also, what is the counterparty if we let the EdenSize at this size when we are not loading/exporting a MSE?
There are 2 main counterparts: - You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste 8Mb. - The user-pauses for scavenges may be more significant.
There are customers using 64Mb Eden in production. It improves their performance, they do not care about wasting 60Mb on machine with 16Gb RAM and their application does heavy computation and does not need to be that responsive.
However for UI applications (typically the IDE), the scavenge pauses may become significant enough to be noticed by the programmer. Maybe not at 12Mb, but certainly at 64Mb.
For your case: - Do you care that your application use some more Mb of RAM ? - Do you care if your application takes a couple extra ms to answer a request ? (In any case, the full GC takes much more time and also delays the answer right now) If you don't care, you can use larger Eden. In any case, an Eden of 12 or 16 Mb should be safe.
There are other settings that can be useful in your case. I will try to write a post about it.
Because in our case we deploy a server that might need to read some MSE. We cannot restart it with our current solution. In that case it would be good to have more info to select the best EdenSize for the server.
Thank you!
I have images that do not shrink with the new compactor and as there are no leaks I am wondering if there is a way for me to diagnose why this happens. I am routinely loading 100MB XML in the image but these are only transient.
First of all run the attached shell script on your image and report back what the "freespace" field value us. In the old compactor this would usually be tens to hundreds of kilobytes. With the new compactor this should be zero or perhaps a few hundred bytes (and I suspect the few hundred bytes should only show up in Newspeak images).
Shrinking works with a Pharo6 image but not with a 5.0 based. Strange.
Look at the vm parameters for growth and shrinkage.
Anyone willing to pair over the internet to have a look?
Yes, but sometime next week.
It is annoying because I am providing those images to customers and an ever growing thing is not really great especially with a non standard tech I am trying to push forward there.
Phil
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- _,,,^..^,,,_ best, Eliot
oops :-) On Fri, Mar 3, 2017 at 8:19 AM, phil@highoctane.be <phil@highoctane.be> wrote:
Eliot,
Script?
Best, Phil
On Fri, Mar 3, 2017 at 5:05 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Phil,
On Fri, Mar 3, 2017 at 5:04 AM, philippe.back@highoctane.be < philippe.back@gmail.com> wrote:
Le 3 mars 2017 13:56, "Clément Bera" <bera.clement@gmail.com> a écrit :
On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
On 03/03/2017 11:56, Clément Bera wrote:
Hello everyone,
This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size.
To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs.
Using the stable Pharo VM, the analysis results were the following: - total time spent to load the Model: 2 minutes - time spent in full GC: 1 minute (4 fullGCs) - time spent in scavenges[1]: 15 seconds On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code.
We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds.
In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds.
Overall, loading the model is now taking ~50 seconds instead of 2 minutes.
To increase Eden size, one needs to run a script similar to:
| currentEdenSize desiredEdenSize | currentEdenSize := Smalltalk vm parameterAt: 44. desiredEdenSize := currentEdenSize * 4. Smalltalk vm parameterAt: 45 put: desiredEdenSize.
_*And then restart the image.*_
I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. _* *_ Best,
Clement
[1] A scavenge is basically the garbage collection of only young objects [2] Eden is basically the space where objects are initially allocated. [3] All numbers in the report are order of magnitudes and not precise numbers
Hi,
This is great! We will probably try it soon on our models.
Guillaume had a question also, what is the counterparty if we let the EdenSize at this size when we are not loading/exporting a MSE?
There are 2 main counterparts: - You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste 8Mb. - The user-pauses for scavenges may be more significant.
There are customers using 64Mb Eden in production. It improves their performance, they do not care about wasting 60Mb on machine with 16Gb RAM and their application does heavy computation and does not need to be that responsive.
However for UI applications (typically the IDE), the scavenge pauses may become significant enough to be noticed by the programmer. Maybe not at 12Mb, but certainly at 64Mb.
For your case: - Do you care that your application use some more Mb of RAM ? - Do you care if your application takes a couple extra ms to answer a request ? (In any case, the full GC takes much more time and also delays the answer right now) If you don't care, you can use larger Eden. In any case, an Eden of 12 or 16 Mb should be safe.
There are other settings that can be useful in your case. I will try to write a post about it.
Because in our case we deploy a server that might need to read some MSE. We cannot restart it with our current solution. In that case it would be good to have more info to select the best EdenSize for the server.
Thank you!
I have images that do not shrink with the new compactor and as there are no leaks I am wondering if there is a way for me to diagnose why this happens. I am routinely loading 100MB XML in the image but these are only transient.
First of all run the attached shell script on your image and report back what the "freespace" field value us. In the old compactor this would usually be tens to hundreds of kilobytes. With the new compactor this should be zero or perhaps a few hundred bytes (and I suspect the few hundred bytes should only show up in Newspeak images).
Shrinking works with a Pharo6 image but not with a 5.0 based. Strange.
Look at the vm parameters for growth and shrinkage.
Anyone willing to pair over the internet to have a look?
Yes, but sometime next week.
It is annoying because I am providing those images to customers and an ever growing thing is not really great especially with a non standard tech I am trying to push forward there.
Phil
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
participants (3)
-
Eliot Miranda -
phil＠highoctane.be -
philippe.back＠highoctane.be