Am 31.05.2013 um 11:38 schrieb Sven Van Caekenberghe <[email protected]>:
> > On 31 May 2013, at 11:26, Norbert Hartl <[email protected]> wrote: > >> >> 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. > > 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 <[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 >>> >>> >> > >
