Surlignage Leo Alvyn 'Vynnie' Cruz <[EMAIL PROTECTED]>:
> Thanks Ariz, I'll see what I can do with these suggestions for now.
>
> Ariz Jacinto wrote:
> > oic. i'll give you an idea. if the application have child processes
> > (ie. lots of ./appname ./appname ./appname), openmosix can
> > help since the child process can be migrated to the other
> > machine w/c a part of your openmosix cluster. but if not, the
> > whole single application process will be migrated instead to
> > the machine with a lesser load.
> >
> > let's add some complexity. if your application involves file
> > processing, you have to enable openmosix's DFS module
> > to make it possible or just access the file remotely on a file
> > server which adds another overhead.
> >
you just have to note that your application must not be I/O bound or
there will be significant network disk synchrnonization issues. this is
because your farmed out application in any of the slave nodes must have
access to the same data via DFS. (this is your bottleneck).
the first thing should be to break your monolithic process into smaller
bite site farmable applications. or your monolithic process can fork
these processes off to allow openmosix to farm them out.
another possibility is to create "processing nodes" that expose a service
to these heavy tasks. then you can write your monolithic application to
to use these services.
if you really have the time you can write is using C and MPI this way you
can really maximize your existing computing resources to the dot. for the
application you have in mind ;-) i believe this is the most elegant solution.
> > you might also want to consider using an HTC cluster instead
> > of an HPC (openmosix). using an HTC would let the application
> > be managed by a job scheduler which forwards the application
> > to a machine with idle resources (we ended up using this, we
> > tried many HTC tools but we reduced the complexity by creating
> > our own after fully understanding it :) ).
> >
> > but before you hit any clustering tools, i would advised you to
> > look more on what's causing the resource hog on your application.
> > once you've identified it, the wiser you'll become on choosing the
> > right solution. sometimes the hog is simply caused by while{}
> > loop without any processing delays in between hehehe or you
> > simply need to optimize the code. if file processing is involved,
> > try reading the disk resources. hdparm command will give you
> > an idea.
> >
> >
> >
> >
> >
> > On 4/4/06, *Leo Alvyn 'Vynnie' Cruz* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Hi Ariz/Guys,
> >
> > Our application are usually a few heavy processes which should also be
> > running at all times. These applications mainly focus on message
> > parsing
> > and lots of computing (playing around integers and float vars with
> > dependency
> > on random generated numbers). It's not the sort of http/ftp service
> > where there's
> > a listening daemon. These few "heavy" process are user initiated
> > within
> > the box.
> > Currently, I have 3 boxes with 2 heavy process each box. Now, what i
> > experience
> > is that, box #1 is running at 80-90% (both CPU & MEM, with little
> > I/O),
> > while the 2 other boxes are running at low numbers. With the
> > clustering
> > in mind,
> > i'll be able to address the"SHARING" of resources as well as ensuring
> > uptime.
> >
> > FYI, these boxes are dual-procs with hefty amount of ram.
> >
> > Thanks Guys.
> >
> >
> > ------------------------------------------------------------------------
> >
> > _________________________________________________
> > Philippine Linux Users' Group (PLUG) Mailing List
> > [email protected] (#PLUG @ irc.free.net.ph)
> > Read the Guidelines: http://linux.org.ph/lists
> > Searchable Archives: http://archives.free.net.ph
>
> --
> L E O A L V Y N "V Y N N I E" C R U Z
> SysAd/NetAd [EMAIL PROTECTED]
> ----------------------------------------
> "There is always a clue." -- Gil Grissom
>
>
-------------------------------------------------------
William Emmanuel S. Yu
Department of Information Systems and Computer Science
Ateneo de Manila University
email : wyu at ateneo dot edu
blog : http://yutivo.org/
web : http://CNG.ateneo.edu/cng/wyu/
phone : +63(2)4266001 loc. 4186
GPG : http://CNG.ateneo.net/cng/wyu/wyy.pgp
Confidentiality Issue: This message is intended only for the use of the
addressee and may contain information that is privileged and
confidential. If you are not the intended recipient, you are hereby
notified that any use or dissemination of this communication is strictly
prohibited. If you have received this communication in error, please
notify us immediately by reply and delete this message from your system.
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph
