| The system is most likely paging and swapping. The out of
box tuning of recent versions seems to prefer to swap out
large processes so the smaller ones can their share of time.
But when the large one runs again it swaps back in and
everything else pages or swaps out. Since the big process
is too large to fit in memory, it probably pages a lot
and may even page against itself, making the performance
even worse than usual.
My first recommendation is to get a system that will support
the load required by the program. Virtual memory is wonderful
stuff, but it is no substitute for large amounts of physical
memory. This appears to be an application in need of more
physical memory than this system can offer.
If this isn't feasible, looking into upgrading the I/O subsystem
to use faster paging disks. Spread the disks over more busses
(okay, on the 200 maybe another bus).
Look into redesigning the application. If its memory use is
one big array or a few arrays that are all needed at once
there isn't much that can be done. If the data being used
is a data structure can small objects be used for some of
the members? At the same time recognize Alpha's preference
for 32 bit or larger integers. I don't know how much of
an affect it would have, but consider memory mapping the
arrays. That might allow more detailed controller of access
patterns and using volume and file system management to
provide better I/O than the page/swap might.
I/O and allocations to the page/swap space are round-robin
from what I've read. When the paging load is spread over
many processes this will probably balance the load out in
way that is nearly as good as striping. For when one big
process is paging, it may not offer the high bandwidth
needed. Using a striped file under AdvFS or volume striping
with LSM might.
If the big process needs all of its memory at the same time
then each time it runs everything else that can will have to
page or swap out. That's a fair amount of memory that has
to be written to and read from disk. The process itself is
certainly more and probably ends up paging against itself.
See if there is a way to tune the system to allow the big
process to run less often but run longer when it has the
memory. I have doubts that this will help any since it
probably won't run efficently anyway, but it may be worth
looking at.
And as a last resort, do brute force process scheduling by
hand. When the system is needed for interface use, send the
process a SIGSTOP. The system will quickly figure out that
it is idle and will bleed away all its memory. When the
system isn't needed for interactive use, send it a SIGCONT.
eff
|
| I as mentioned (well, my evil twin mentioned) in .1, out of the
box, Digital UNIX seems to prefer to swap large processes. Now,
this particular process isn't very friendly no matter what you
do, but it could help the rest of the system if it didn't have
to swap it out to allow the other things to run. Assuming a
2 MB/sec disk, it will take around 3 minutes to swap that
process out and that much again to swap it back in.
If you re-tune the system to not swap out the large process,
when the others want to run they will cause pages to be trimmed
off the big one so they can run. The paging activity will
probably still be excessive, but it may be enough of a change
to the system usable for interactive work; you don't wait three
minutes for swapin/swapout.
|