I am currently experimenting with Pharo on Amazon EC2. I'd like to keep the CPU usage low for when Pharo hasn't anything special to do. At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret. Is there a way to get that lower? Even if it means tweaking the VM. The OS is Ubuntu 12 LTS Thanks!
Am 27.05.2013 um 09:19 schrieb "phil@highoctane.be" <phil@highoctane.be>:
I am currently experimenting with Pharo on Amazon EC2.
I'd like to keep the CPU usage low for when Pharo hasn't anything special to do.
At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret.
Is there a way to get that lower? Even if it means tweaking the VM.
The OS is Ubuntu 12 LTS
Sure, it is one of the long outstanding issues. While decades ago polling was the way to handle native and external stuff this isn't the case anymore. The big problem is that the image has quite some polling actions going on keeping the image eating cpu cycles. Your best bet at the moment is suspending the ui thread. That will spare some cycles. If you use seaside there is even a web handler to suspend/resume the ui thread. Or you can hack the vm to use an event based approach. Norbert
On May 27, 2013, at 9:47 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 09:19 schrieb "phil@highoctane.be" <phil@highoctane.be>:
I am currently experimenting with Pharo on Amazon EC2.
I'd like to keep the CPU usage low for when Pharo hasn't anything special to do.
At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret.
Is there a way to get that lower? Even if it means tweaking the VM.
There is a "Server Mode" Setting in Pharo that reduces UI related polling⦠Marcus
Phil, On 27 May 2013, at 09:19, "phil@highoctane.be" <phil@highoctane.be> wrote:
I am currently experimenting with Pharo on Amazon EC2.
I'd like to keep the CPU usage low for when Pharo hasn't anything special to do.
At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret.
Is there a way to get that lower? Even if it means tweaking the VM.
The OS is Ubuntu 12 LTS
Thanks!
It would definitively by better if we could get CPU usage when idle very close to 0%. But IMO the current situation is not really a problem. Actual load problems will still be caused by real load, not by idle instances. Anyway, that is what I see on production machines with multiple Pharo instances next to many other processes. Sven BTW, load & cpu usage numbers can be very hard to interpret. -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Thanks for the info. Norbert, I didn't knew about that UI thread handler in Seaside. I'll check that out. Phil On Mon, May 27, 2013 at 9:49 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Phil,
On 27 May 2013, at 09:19, "phil@highoctane.be" <phil@highoctane.be> wrote:
I am currently experimenting with Pharo on Amazon EC2.
I'd like to keep the CPU usage low for when Pharo hasn't anything special to do.
At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret.
Is there a way to get that lower? Even if it means tweaking the VM.
The OS is Ubuntu 12 LTS
Thanks!
It would definitively by better if we could get CPU usage when idle very close to 0%.
But IMO the current situation is not really a problem. Actual load problems will still be caused by real load, not by idle instances. Anyway, that is what I see on production machines with multiple Pharo instances next to many other processes.
Sven
BTW, load & cpu usage numbers can be very hard to interpret.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
It includes as well a button to make a screenshot in the image :) Norbert Am 27.05.2013 um 09:56 schrieb "phil@highoctane.be" <phil@highoctane.be>:
Thanks for the info.
Norbert, I didn't knew about that UI thread handler in Seaside. I'll check that out.
Phil
On Mon, May 27, 2013 at 9:49 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Phil,
On 27 May 2013, at 09:19, "phil@highoctane.be" <phil@highoctane.be> wrote:
I am currently experimenting with Pharo on Amazon EC2.
I'd like to keep the CPU usage low for when Pharo hasn't anything special to do.
At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret.
Is there a way to get that lower? Even if it means tweaking the VM.
The OS is Ubuntu 12 LTS
Thanks!
It would definitively by better if we could get CPU usage when idle very close to 0%.
But IMO the current situation is not really a problem. Actual load problems will still be caused by real load, not by idle instances. Anyway, that is what I see on production machines with multiple Pharo instances next to many other processes.
Sven
BTW, load & cpu usage numbers can be very hard to interpret.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
That feature I know of. It is a nice one for sure! Phil On Mon, May 27, 2013 at 9:58 AM, Norbert Hartl <norbert@hartl.name> wrote:
It includes as well a button to make a screenshot in the image :)
Norbert
Am 27.05.2013 um 09:56 schrieb "phil@highoctane.be" <phil@highoctane.be>:
Thanks for the info.
Norbert, I didn't knew about that UI thread handler in Seaside. I'll check that out.
Phil
On Mon, May 27, 2013 at 9:49 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Phil,
On 27 May 2013, at 09:19, "phil@highoctane.be" <phil@highoctane.be> wrote:
I am currently experimenting with Pharo on Amazon EC2.
I'd like to keep the CPU usage low for when Pharo hasn't anything special to do.
At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret.
Is there a way to get that lower? Even if it means tweaking the VM.
The OS is Ubuntu 12 LTS
Thanks!
It would definitively by better if we could get CPU usage when idle very close to 0%.
But IMO the current situation is not really a problem. Actual load problems will still be caused by real load, not by idle instances. Anyway, that is what I see on production machines with multiple Pharo instances next to many other processes.
Sven
BTW, load & cpu usage numbers can be very hard to interpret.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
BTW, load & cpu usage numbers can be very hard to interpret.
really? CPU usage is pretty easy and you can see this in most OSses directly. 100% CPU usage is full :) Load isn't that much harder. It's just the load of the scheduler queue. So if some needs a rule of thumb safe CPU load = number of cores/processes * 0.7 theoretical optimal CPU load = number of core/processes Everything above should really be investigated because you entered the zone where additional CPU load can drive your machine unresponsive. You have less CPU usage but high load? Investigate I/O usage! I know you know that, Sven. I just wanted to mention it because this comes up from time to time. Compared to memory consumption, CPU, scheduler and I/O are easier targets IMHO. For Phil the point isn't the health of the system. It is EC2. You have to pay for the CPU usage on EC2 so I think he had the impression there is room for improvement. And indeed there is. But if you calculate it through it isn't really a factor. Norbert
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed. Well, I'll look at all that this evening and give back the impressions. I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot. Phil On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
BTW, load & cpu usage numbers can be very hard to interpret.
really? CPU usage is pretty easy and you can see this in most OSses directly. 100% CPU usage is full :) Load isn't that much harder. It's just the load of the scheduler queue. So if some needs a rule of thumb
safe CPU load = number of cores/processes * 0.7 theoretical optimal CPU load = number of core/processes
Everything above should really be investigated because you entered the zone where additional CPU load can drive your machine unresponsive. You have less CPU usage but high load? Investigate I/O usage!
I know you know that, Sven. I just wanted to mention it because this comes up from time to time. Compared to memory consumption, CPU, scheduler and I/O are easier targets IMHO.
For Phil the point isn't the health of the system. It is EC2. You have to pay for the CPU usage on EC2 so I think he had the impression there is room for improvement. And indeed there is. But if you calculate it through it isn't really a factor.
Norbert
Am 27.05.2013 um 10:17 schrieb phil@highoctane.be:
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed.
Well, I'll look at all that this evening and give back the impressions.
I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot.
What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? I need to dig deeper. Norbert
Phil
On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
BTW, load & cpu usage numbers can be very hard to interpret.
really? CPU usage is pretty easy and you can see this in most OSses directly. 100% CPU usage is full :) Load isn't that much harder. It's just the load of the scheduler queue. So if some needs a rule of thumb
safe CPU load = number of cores/processes * 0.7 theoretical optimal CPU load = number of core/processes
Everything above should really be investigated because you entered the zone where additional CPU load can drive your machine unresponsive. You have less CPU usage but high load? Investigate I/O usage!
I know you know that, Sven. I just wanted to mention it because this comes up from time to time. Compared to memory consumption, CPU, scheduler and I/O are easier targets IMHO.
For Phil the point isn't the health of the system. It is EC2. You have to pay for the CPU usage on EC2 so I think he had the impression there is room for improvement. And indeed there is. But if you calculate it through it isn't really a factor.
Norbert
On 31 May 2013, at 11:26, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 10:17 schrieb phil@highoctane.be:
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed.
Well, I'll look at all that this evening and give back the impressions.
I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot.
What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? I need to dig deeper.
Killing as much non-needed process is certainly step one. A clean image has these processes: 1. Delay scheduling process 2. Input events fetching process 3. The low space watcher 4. The weak array finalization process 5. Morphic UI process 6. The idle process So you killed 5. How did you do that exactly ? Is #serverMode still relevant when 5 is gone ? Would it be possible to kill 2 ? Is it needed for a headless server ? As long as file and socket IO keeps working, we're good. The rest is probably all needed. Are there any (slightly busy) processes inside the VM that we can't see at the Smalltalk level ?
Norbert
Phil
On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
BTW, load & cpu usage numbers can be very hard to interpret.
really? CPU usage is pretty easy and you can see this in most OSses directly. 100% CPU usage is full :) Load isn't that much harder. It's just the load of the scheduler queue. So if some needs a rule of thumb
safe CPU load = number of cores/processes * 0.7 theoretical optimal CPU load = number of core/processes
Everything above should really be investigated because you entered the zone where additional CPU load can drive your machine unresponsive. You have less CPU usage but high load? Investigate I/O usage!
I know you know that, Sven. I just wanted to mention it because this comes up from time to time. Compared to memory consumption, CPU, scheduler and I/O are easier targets IMHO.
For Phil the point isn't the health of the system. It is EC2. You have to pay for the CPU usage on EC2 so I think he had the impression there is room for improvement. And indeed there is. But if you calculate it through it isn't really a factor.
Norbert
Am 31.05.2013 um 11:38 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 31 May 2013, at 11:26, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 10:17 schrieb phil@highoctane.be:
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed.
Well, I'll look at all that this evening and give back the impressions.
I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot.
What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? I need to dig deeper.
Killing as much non-needed process is certainly step one. A clean image has these processes:
1. Delay scheduling process 2. Input events fetching process 3. The low space watcher 4. The weak array finalization process 5. Morphic UI process 6. The idle process
So you killed 5. How did you do that exactly ?
I didn't kill it. I just did MorphicUIManager default uiProcess suspend
Is #serverMode still relevant when 5 is gone ?
I was asking myself the same question.
Would it be possible to kill 2 ? Is it needed for a headless server ?
That could be one of the more busy processes. So if we stop 5. there is no point in running 2., right? Or asking the other way round: What is included in input events fetching? keyboard and mouse or something else, too?
As long as file and socket IO keeps working, we're good.
Yes and it is quite interesting to see how much polling is going on there. I think those two are the ones that would benefit the most from having an event based native adaption. Norbert
The rest is probably all needed.
Are there any (slightly busy) processes inside the VM that we can't see at the Smalltalk level ?
Norbert
Phil
On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
BTW, load & cpu usage numbers can be very hard to interpret.
really? CPU usage is pretty easy and you can see this in most OSses directly. 100% CPU usage is full :) Load isn't that much harder. It's just the load of the scheduler queue. So if some needs a rule of thumb
safe CPU load = number of cores/processes * 0.7 theoretical optimal CPU load = number of core/processes
Everything above should really be investigated because you entered the zone where additional CPU load can drive your machine unresponsive. You have less CPU usage but high load? Investigate I/O usage!
I know you know that, Sven. I just wanted to mention it because this comes up from time to time. Compared to memory consumption, CPU, scheduler and I/O are easier targets IMHO.
For Phil the point isn't the health of the system. It is EC2. You have to pay for the CPU usage on EC2 so I think he had the impression there is room for improvement. And indeed there is. But if you calculate it through it isn't really a factor.
Norbert
On May 31, 2013, at 11:39 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 31 May 2013, at 11:26, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 10:17 schrieb phil@highoctane.be:
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed.
Well, I'll look at all that this evening and give back the impressions.
I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot.
What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? I need to dig deeper.
Killing as much non-needed process is certainly step one. A clean image has these processes:
1. Delay scheduling process 2. Input events fetching process 3. The low space watcher 4. The weak array finalization process 5. Morphic UI process 6. The idle process
So you killed 5. How did you do that exactly ? Is #serverMode still relevant when 5 is gone ? Would it be possible to kill 2 ? Is it needed for a headless server ? As long as file and socket IO keeps working, we're good.
The rest is probably all needed.
Did you try the server mode? WorldState serverMode: true. Marcus
Am 31.05.2013 um 12:57 schrieb Marcus Denker <marcus.denker@inria.fr>:
On May 31, 2013, at 11:39 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 31 May 2013, at 11:26, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 10:17 schrieb phil@highoctane.be:
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed.
Well, I'll look at all that this evening and give back the impressions.
I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot.
What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? I need to dig deeper.
Killing as much non-needed process is certainly step one. A clean image has these processes:
1. Delay scheduling process 2. Input events fetching process 3. The low space watcher 4. The weak array finalization process 5. Morphic UI process 6. The idle process
So you killed 5. How did you do that exactly ? Is #serverMode still relevant when 5 is gone ? Would it be possible to kill 2 ? Is it needed for a headless server ? As long as file and socket IO keeps working, we're good.
The rest is probably all needed.
Did you try the server mode?
WorldState serverMode: true.
I did and it doesn't make a big difference what makes me wonder. So having quite some CPU usage with a static 50ms delay does mean that every cycle does many things or the CPU usage is not UI bound. Norbert
I don't know how to do this for Linux based VMs (which is what I'll need in the end) but can do some experiments with Apple Xcode Instruments. That's something I've wanted to do for a long time as this gives deep insight on how a program is behaving. http://en.wikipedia.org/wiki/Instruments_%28application%29 http://developer.apple.com/library/mac/#documentation/DeveloperTools/Concept... Thanks for looking into this. Maybe could we do a chapter on these matters in one of the Pharo books. The point of having idle VMs is that when one machine is hit by a peak of usage, the other instances can swallow the load. Now, I am not talking about a single EC2 VM, but a group of them, each having a set of VMs. FWIW, AIMP3 playing MP3s all the time is 9%-11% on an old PIV 3Ghz, while Skype takes 1% idling Phil On Fri, May 31, 2013 at 11:26 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 10:17 schrieb phil@highoctane.be:
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed.
Well, I'll look at all that this evening and give back the impressions.
I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot.
What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? I need to dig deeper.
Norbert
Phil
On Mon, May 27, 2013 at 10:07 AM, Norbert Hartl <norbert@hartl.name>wrote:
Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
BTW, load & cpu usage numbers can be very hard to interpret.
really? CPU usage is pretty easy and you can see this in most OSses directly. 100% CPU usage is full :) Load isn't that much harder. It's just the load of the scheduler queue. So if some needs a rule of thumb
safe CPU load = number of cores/processes * 0.7 theoretical optimal CPU load = number of core/processes
Everything above should really be investigated because you entered the zone where additional CPU load can drive your machine unresponsive. You have less CPU usage but high load? Investigate I/O usage!
I know you know that, Sven. I just wanted to mention it because this comes up from time to time. Compared to memory consumption, CPU, scheduler and I/O are easier targets IMHO.
For Phil the point isn't the health of the system. It is EC2. You have to pay for the CPU usage on EC2 so I think he had the impression there is room for improvement. And indeed there is. But if you calculate it through it isn't really a factor.
Norbert
On 31 May 2013 11:26, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.05.2013 um 10:17 schrieb phil@highoctane.be:
I was looking at the output of "top" for while and Pharo was trusting the top spot indeed.
Well, I'll look at all that this evening and give back the impressions.
I want to run several instances of Pharo on the box and it will for sure add up. Say, 20 x 2% gives an awful lot.
What is the use of having 20 idle images on one server? :) I think you can't easily say that it always adds on top. If your image is running at 100% the 2% off even if fully countable wouldn't be that much. But nevertheless it is a valid point and I cannot see pharo becomes more modern by stop polling in the mid-term future. Anyway I played a little bit with the tweaks and there are things that make me wonder. I raised the limit for server mode but didn't get much benefit. Having a cycle pause of 100ms in serverMode and stopping the ui process still gave me a 1% CPU usage which is really a lot. Does anyone know in-depth what an image is doing? How to investigate? Maybe there are a lot of native polling things involved, too? I need to dig deeper.
each ms, a heartbeat thread wakes up and triggers interrupt processing. this is equivalent to polling each 1ms just yesterday we discussed this.. the problem is how to avoid interrupt processing each ms and support green threading at same time. i know that hardware given plenty of opportunities to do that.. but the problem is that most of it available only in privileged mode. i hate to see that: hardware allows much better scheduling handling, but we're doomed to use ineffective scheme, because of OS limitations.
Norbert
Phil
-- Best regards, Igor Stasenko.
participants (5)
-
Igor Stasenko -
Marcus Denker -
Norbert Hartl -
phil＠highoctane.be -
Sven Van Caekenberghe