> The question is how to lower the CPU utilization of an application. > - Is there any general rules?
Wow - this is a very, very general question. There are, however, a couple of general rules which usually stand you in good stead when looking at optimisation: * There are only two ways to make software quicker: * Make it do less stuff (i.e. choose better algorithms which need less underlying operations to achieve the same results) * Do what you do quicker (i.e. optimise the underlying operations) * The biggest wins are at the highest layers of the software stack (i.e. you're better off just trying to call strcmp(3C) less, rather than trying to write a better strcmp). > - What kind of operations consume large amount of CPU time? > - How to make sure multiple instance of applications not > working in too-awful way? My apologies - I'm afraid I can't really come up with sensible answers to these - the questions are just too general. > For example, when using gzip compress a big file, the CPU > utilization could be more than 40%. But if using 3 gzip > session simultaneously, the system will still have 10+ % of idle time. > > But for my application, single instance will consume 40% CPU, > and 3 instances will always make CPU idle time to zero. It's worth thinking about what you mean by "40% CPU" here, and it's worth remembering that CPU isn't the only thing which can be the rate-determining step for an application (if only it was!). Taking your gzip job as an example - gzip doesn't have any wait loops in it, it tries to read in your file, compress it and write it out as quickly as it can. If it's not using 100% CPU for the whole of its run, it's restricted by something else - it's likely that the filesystem can't deliver the file quickly enough to keep the CPU busy. As such, adding more instances of the process _might_ use more CPU, and _might_ not. If you're looking to optimise an application, your first step is usually to determine what the rate-determining step is. It might be CPU-bound, network-bound or disk-bound; high-performance computing applications will most likely even be memory-bound, where the machine's memory subsystem can't deliver data quickly enough to the CPU to keep it busy. Once you know where the bottleneck is, you can look at how to remove it. As for finding this rate-determining step - there are a number of ways to attack it. You can use traditional tools like vmstat, mpstat, iostat and prstat to get a broad view of what's happening on a system. At a lower level, the mighty DTrace can answer most questions you ever want to ask - but you might find it a bit difficult to phrase the questions to begin with, because the DTrace vocabulary is pretty big. If you _do_ end up being CPU-bound, you need to get an execution profiler out to see where your app is spending its time. There's an excellent profiler in Sun Studio, which you can get a license for as a member of the OpenSolaris community. You can also use DTrace for profiling purposes. I realise my answers are pretty general here, and I hope I haven't offended your intelligence by going through some of the basics. There's a good book (or two) to be written in response to your original question! -- Phil Home: mailto:[EMAIL PROTECTED] Work: mailto:[EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of phreedom > Sent: 14 November 2005 10:54 > To: perf-discuss@opensolaris.org > Subject: [perf-discuss] How to lower CPU utilization of applications? > > > The question is how to lower the CPU utilization of an application. > - Is there any general rules? > - What kind of operations consume large amount of CPU time? > - How to make sure multiple instance of applications not > working in too-awful way? > > For example, when using gzip compress a big file, the CPU > utilization could be more than 40%. But if using 3 gzip > session simultaneously, the system will still have 10+ % of idle time. > > But for my application, single instance will consume 40% CPU, > and 3 instances will always make CPU idle time to zero. > > Thanks. > This message posted from opensolaris.org > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
