On Mon, 2007-05-07 at 12:15 -0400, Douglas Allan Tutty wrote: > On Mon, May 07, 2007 at 11:55:56AM -0400, Greg Folkert wrote: > > I've part-time admin'd (contracted) a couple of systems that required > > 128GB of swap during batch processing "middle of the night" setups. > > Primarily because of the inner looping of some of the jobs and the > > amount of "stored" info hanging in memory. Rather than fix the batch > > processing system, which came from an AS400 (which originally was on an > > IBM 36 system), the company suggested swap as a workaround. > > How much memory and swap did the program have to play with on an AS400 > or 36? Things are allocated differently on the AS400 and different differently on the 36. There really isn't a way compare them, easily. Plus the "extending" has had deleterious effects on the currently supported implementations. They no longer support the "other" platforms as they don't have enough experience with them. They are trying to move everything to "Windows" as that is what everyone is asking for. > To generalize the problem, given that the software can't be changed, at > what point do you start to look at either a bigger single computer or a > cluster that looks like a bigger computer? For me its just an > intelectual exercise; I went from a 486 with 32 MB swap to an Athlon > with 1GB in a single bound. That Xorg makes _that_ swap really burns me > up. Cluster? HA! Bigger Single computer? HA! They have 8 processor machines with 64GB of memory already. The batch process can only utilize 1 processor. The other 7 processors, are basically idle. I've trended the entire machine for them. If they could LPAR the machine(s) out, they'd be marvelously happy. But they would need to get the memory upto 512MB or better and then multi-path IO for the swap... sheesh. It would be cheaper to just buy another machine and add it, but then they already have 3 hours at worst, 4 hours at best, of growth left. In any case, a "pre-batch" program assigns jobs to each machine, it takes nearly an hour to estimate loads. Again single processor usage. This whole package was never meant to scale. But it has been forced to. It also was meant to be a temporary fix until a new system was to be spec'd and written. Nothing ever came of the effort in the 70's and was dropped when this was "good enough". -- greg, greg@gregfolkert.net PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0
Attachment:
signature.asc
Description: This is a digitally signed message part