Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!hp4nl!tuegate.tue.nl!al.ele.tue.nl!euteal!michel From: michel@es.ele.tue.nl (Michel Berkelaar) Newsgroups: comp.sys.hp Subject: Re: HP 9000/835 memory usage (System crawling ...) Message-ID: Date: 24 Sep 90 08:00:52 GMT References: <7679@ucdavis.ucdavis.edu> <530019@hpcuhc.HP.COM> Sender: news@ele.tue.nl Organization: Eindhoven University of Technology, Eindhoven, The Netherlands Lines: 55 In-reply-to: mck@hpcuhc.HP.COM's message of 20 Sep 90 19:19:08 GMT The fact that system performance of a hp9000/835 decreases more than dramatically when forced to swap has been observed in our group as well. Our configuration: 2 x HP 9000/835 with 16 MB. Typical load: about 5 users, 1 minute load average between 0.5 and 1.5 each When we were experimenting with swapon to increase our swap space, I wrote the following little program, just to see how much memory I could get: main() { int i; for(i = 1; calloc((unsigned)(1<<20), (unsigned)1); i++) printf("megabytes: %d\n", i); perror("test"); printf ("Come to the end\n"); sleep(10000); } Running this on the HP showed a slow increase in allocated memory during the first 10 MB or so, but after that each new MB took longer to calloc, and the system load started growing, and growing. When I reached 23 MB after 10 minutes or so (!!!), the load had gone up to 22. I then decided to stop the process, but even that took minutes. And, even more strange, it took the HP more than 10 minutes to recover from this event, with the load only very gradually coming down to the normal valu of about 1. No need to tell you that some of the other users were furious by that time. Btw, none of the other users were doing something that could have accounted for the load. So: what is going on inside the 835 when it starts swapping? Why is it so overly sensitive to this situation? Do other people see the same behaviour? By the way, running the same test on our Alliant FX8 (with 120 MB of memory) also showed a dramatic increase in system load when the process started swapping, but not as bad as the HP. The same test on my humble Apollo DN2500 with 16MB runs without problems, the load staying around 1, and the megabytes being calloc-ed faster then on the HP. It continues on the 2500 untill the disk is full, and then stops gracefully because calloc returns 0. It would be interesting if some people could try the above code on different hardware platforms, and report the observed behaviour. -- ------------------------------------------------------------------------------- Michel Berkelaar | Email: michel@ele.tue.nl Eindhoven University of Technology | Dept. of Electrical Engineering | Design Automation Section | P.O. Box 513 | Phone: ... - 31 - 40 - 473345 NL-5600 MB Eindhoven | Fax: ... - 31 - 40 - 448375 The Netherlands | -------------------------------------------------------------------------------