Les Mikesell wrote:
vmstat and iostat will a reasonable idea of what is happening swap
and disk-wise if you watch them with a 1 or 5 second interval while
the app runs. Note that disk writes are normally queued and especially
for scsi have little CPU overhead. Reads often mean that the
CPU is waiting. Depending on whether the same thing is read more
than once or not you might be able to speed this up with more
RAM to cache it. But, if sar is reporting near 100% CPU use for
most of the run there probably isn't much you can do.
According to iostat, there does not appear to be any big problems on
disk access or wait. In fact, wait is 0. The largest block writes I've
seen are like 6000/sec, writing 30,400 in 5 seconds. Sar is reporting
at the current, zero swap, and from what I've been watching, it pretty
much stays that way unitil 0420, when all the updatedb and other cron
jobs kick off. The machine stays busy about 20 hours of of 24, so it's
pretty easy to monitor what's going on. I just wish I knew more about
the internal workings of the model and how it does things. Doubt if
source code would help me much as I'm not really up to speed on fortran.
A different algorithm, or something like pre-sorting the data might make
a huge difference.
I don't know if there is anything that could be done in that area. The
software reads in files, I'd assume, sequentially, as that is how the
initialization data is done.. all based on time.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
