• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Java competing with native code app over resources

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi.

I have 2 apps running on my server, a native code application, and a Java one.
Java app is communicating with the native code over IPC (shared memory). They both work on same number of resources.

On high loads (about 80% CPU), the native app takes about 100% more of CPU time (the server is multi-cpu, multi-core).

My question is, does it possible to balance the CPU loads between the two apps? Meaning, give the two apps equal priorities?

Thanks for any advice.
 
Saloon Keeper
Posts: 28319
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I couldn't quite get a clear picture of what you're looking for, but maybe this will help:

The technical name for scheduling more work on a computer than it can handle is "overcommit". Overcommitting was fairly common back when expensive mainframes were the rule, but these days hardware is so cheap that the usual response to a heavier workload is to just buy more hardware.

However, sometimes that's not sufficient and even after tuning you may still end up overcommitted.

Once that occurs, it's time to sit down and determine who's going to get the short end of the deal. Since resources are finite, then next best thing is to give them to those who can best justify their use - meaning produce more revenue, keep everyone out of trouble, or just plain have the political pull. You then draw up service level agreements that specify how much of the pie each consumer is going to get and what the rules on dividing the pie are going to be.

The original Unix solution for that was in programs like "nice" that maintained a set of CPU dispatcher priority levels. You would mostly adjust the nice levels yourself on a manual basis.

That's only the start, however. On a heavily-used system, you have queues for more than just CPU time, you may also want to load-balance on network and disk resources. Also on how much real memory will back up each process versus how much virtual memory it consumes.

The big-league vendors like IBM and Sun have very elaborate resource management systems. They would allocate general service levels, dynamically bump resources up and down in response to changing conditions - for example, the longer a processs ran, the lower priority it might be given - and do whatever else was necessary. In one IBM shop I worked in, we'd even switch the service level rules 3 times a day as we went from day shift (online users and developers) to night shift (production processing) to early-morning shift (backups and system maintenance).

Ultimately, Java apps are native code as well. The JVM is native code and so is any JIT- or pre-compiled Java code. From the OS's point of view, it's just another native app. Of course, every app has its own ways of using resources. So for optimal performance, you'll want to set some service levels and investigate the load-balancing options that the system(s) you're running on support.
 
Let nothing stop you! Not even this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic