Am 27.05.2013 um 10:17 schrieb [email protected]: > 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 <[email protected]> wrote: > > Am 27.05.2013 um 09:49 schrieb Sven Van Caekenberghe <[email protected]>: > >> 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 > >
