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.