syscrc@GSUSGI1.GSU.EDU (Randy Carpenter) (06/01/91)
I have a few miscellaneous IRIX questions:
1.) Where can we get the SGI diagnostic programs that are supposed
to be in /usr/diags? By default, there's nothing in the
directory.
2.) Why does ps(1) take so long every once in a while but then
has good response at other times.
3.) Why doesn't ex(1) and vi(1) look at the TMPDIR environment
variable like ed(1) to allocate buffers? The default root
partition on SGI systems doesn't leave enough space in /tmp
to edit huge files. I don't want to have to worry about
every user having to "set directory=/usr/tmp" in their .exrc
files and I don't want to expand the root partition.
Randy Carpenter
Georgia State University
Wells Computer Center
syscrc@gsu.eduolson@anchor.esd.sgi.com (Dave Olson) (06/02/91)
In <9105311819.AA02956@gsusgi1.gsu.edu> syscrc@GSUSGI1.GSU.EDU (Randy Carpenter) writes: | I have a few miscellaneous IRIX questions: | | 1.) Where can we get the SGI diagnostic programs that are supposed | to be in /usr/diags? By default, there's nothing in the | directory. They are in eoe2.sw.diags, if I remember correctly, and are machine specific. In fact, the subsystem is empty for 4D20, 25, and 35 machines. For the PI products, MOST of the same diagnostic functionality is in the 'ide' program run from the PROM menu. The non-PI products mostly don't run standalone, and so live in /usr/diags. | 2.) Why does ps(1) take so long every once in a while but then | has good response at other times. If you change /unix, or remove /tmp/.ps_data, the file gets re-created, which takes a while. After that ps runs faster. Basicly it saves ps having to grub through the kernel symbol table on each invocation. | 3.) Why doesn't ex(1) and vi(1) look at the TMPDIR environment | variable like ed(1) to allocate buffers? The default root | partition on SGI systems doesn't leave enough space in /tmp | to edit huge files. I don't want to have to worry about | every user having to "set directory=/usr/tmp" in their .exrc | files and I don't want to expand the root partition. Well, you could just symlink /tmp to /usr/tmp... vi long predates the TMPDIR convention, and since the equivalent functionality is already present, there has been no urgency to add another; one would then have to decide which set of tmpdir specifiers take precedence. You could also do set the EXINIT variable in /etc/{profile,cshrc} so your 'naive' users get your default, while experienced users can easily override it. -- Dave Olson Life would be so much easier if we could just look at the source code.
rpaul@crow.UUCP (Rodian Paul) (06/02/91)
Randy Carpenter asked: > | 2.) Why does ps(1) take so long every once in a while but then > | has good response at other times. Dave Olson answered: > If you change /unix, or remove /tmp/.ps_data, the file gets re-created, > which takes a while. After that ps runs faster. Basicly it saves ps > having to grub through the kernel symbol table on each invocation. > Myself and others here have also noticed this problem. We don't dick with the kernels that often and to my knowledge nobody deliberatly trashes /tmp/.ps_data. I'm afraid I don't think that the above answer quite explains why the response is often so slow. The odd thing is that the response problem doesn't seem tied to the load-average on the machine. The machines we've noted this on: 4D/70GT's, 4D/210's, 4D/240GTX's, 4D/25's, 4D/35's and a 4D/380S. OS: IRIX 3.3.1 and 3.3.2 > | 3.) Why doesn't ex(1) and vi(1) look at the TMPDIR environment > | variable like ed(1) to allocate buffers? The default root > | partition on SGI systems doesn't leave enough space in /tmp > | to edit huge files. I don't want to have to worry about > | every user having to "set directory=/usr/tmp" in their .exrc > | files and I don't want to expand the root partition. > Now for a naive question. I collect a lot of stuff from the net and the folders that I save via 'rn' often become quite large. At a later date, when I try to run: % Mail -f ~/News/Comp.foo on a large file, I get the following response: /tmp: No such file or directory I then have to switch to a machine with a larger root partition. I find that nowadays I am slicing my news folders and giving them a .n suffix. Is there a way to specify which directory /usr/sbin/Mail uses for a temporary dir? Yep. I'm allready specifying TMPDIR in my env. Cheers. ------------------------------------------------------------------------------- rpaul%crow@ccut.cc.u-tokyo.ac.jp phone: +81 (3) 5706-8357 ccut.cc.u-tokyo.ac.jp!crow!rpaul FAX: +81 (3) 5706-8437
mg@godzilla.cgl.rmit.oz.au (Mike Gigante) (06/02/91)
rpaul@crow.UUCP (Rodian Paul) writes:
]Randy Carpenter asked:
]] | 2.) Why does ps(1) take so long every once in a while but then
]] | has good response at other times.
]Dave Olson answered:
]] If you change /unix, or remove /tmp/.ps_data, the file gets re-created,
]] which takes a while. After that ps runs faster. Basicly it saves ps
]] having to grub through the kernel symbol table on each invocation.
]]
]Myself and others here have also noticed this problem. We don't dick
]with the kernels that often and to my knowledge nobody deliberatly
]trashes /tmp/.ps_data. I'm afraid I don't think that the above
]answer quite explains why the response is often so slow. The odd
]thing is that the response problem doesn't seem tied to the load-average
]on the machine.
The way I have figured it is that the first time each day it is really slow
while the other times ity is fast. It may be either date/time based as I
speculate, or it may ignore /tmp/ps_data if it is older than X (for some X)mg@godzilla.cgl.rmit.oz.au (Mike Gigante) (06/02/91)
While we are talking about Mail, I used to use the & f fred command in Mail prior to 3.3 to give me headers of all the messages from the user fred. It no longer works - it may be related to the fact that the headers are displayed differently in 3.3 Mail than they used to be in 3.2 (to be specific, the sender field is printed differently). Is there some reason for this change? Mike Gigante, ACGC Royal Melbourne Institute of Technology
srp@babar.mmwb.ucsf.edu (Scott R. Presnell) (06/03/91)
mg@godzilla.cgl.rmit.oz.au (Mike Gigante) writes: >rpaul@crow.UUCP (Rodian Paul) writes: >]Randy Carpenter asked: >]] | 2.) Why does ps(1) take so long every once in a while but then >]] | has good response at other times. >]Dave Olson answered: >]] If you change /unix, or remove /tmp/.ps_data, the file gets re-created, >]] which takes a while. After that ps runs faster. Basicly it saves ps >]] having to grub through the kernel symbol table on each invocation. >]] My experience is that a change in /dev, or /etc/passwd will also trigger the remake of the .ps_data - Scott -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet
olson@anchor.esd.sgi.com (Dave Olson) (06/03/91)
In <9106020322.AA12664@crow.omni.co> rpaul@crow.UUCP (Rodian Paul) writes: | Randy Carpenter asked: | > | 2.) Why does ps(1) take so long every once in a while but then | > | has good response at other times. | | Dave Olson answered: | | > If you change /unix, or remove /tmp/.ps_data, the file gets re-created, | > which takes a while. After that ps runs faster. Basicly it saves ps | > having to grub through the kernel symbol table on each invocation. | > | | Myself and others here have also noticed this problem. We don't dick | with the kernels that often and to my knowledge nobody deliberatly | trashes /tmp/.ps_data. I'm afraid I don't think that the above | answer quite explains why the response is often so slow. The odd | thing is that the response problem doesn't seem tied to the load-average | on the machine. One other possiblity, if this happens all the time on a particular machine is that you ran afoul of the date bug at one point, and /unix has a mod time far in the future. If so, the .ps_data file will always be out of date. I know of no other problems that cause ps to *intermittently* take a much longer time to run on a particular machine with a low load average. (Actually, there IS one other possiblity. If a lot of users are YP/NIS users, then ps may be spending time waiting on yp to get uid -> username translations, but this seems unlikely. | Now for a naive question. I collect a lot of stuff from the net and the | folders that I save via 'rn' often become quite large. At a later date, | when I try to run: | | % Mail -f ~/News/Comp.foo | | on a large file, I get the following response: | | /tmp: No such file or directory Mail is another 'old' program predating TMPDIR and tempnam(). Worse yet, there are no workarounds, as /tmp is hardcoded in multiple places, and the error messages are less than informative. I think a bug is already submitted on this; if not I'll create one. It isn't fixed in 4.0. The only workaround is to make /tmp be a symlink to /usr/tmp. By the way, this problem is still in S5R3.2 mailx, and all the 4.3 Mail versions, including reno and tahoe. This doesn't excuse our not fixing it, but you will likely see the same problem on other systems. -- Dave Olson Life would be so much easier if we could just look at the source code.
olson@anchor.esd.sgi.com (Dave Olson) (06/03/91)
In <mg.675842217@godzilla> mg@godzilla.cgl.rmit.oz.au (Mike Gigante) writes: | The way I have figured it is that the first time each day it is really slow | while the other times ity is fast. It may be either date/time based as I | speculate, or it may ignore /tmp/ps_data if it is older than X (for some X) Actually, I abbreviated the algorithm somewhat. The ps_data file is ignored and/or re-created if it is older than any of /unix, /dev, and /etc/passwd. So if you create devices/files in /dev a lot, or alter /etc/passwd fairly often, that might explain it. Both mtime and ctime are considered; some backup programs modify ctime to preserve atime, so this might explain your first use of the day slowness. Excessive age is not a reason to not use the ps_data file; it is considered simply a sign of a stable system :) Also note that if you use YP/NIS, that new YP users don't show up by name in the ps output until you touch one of those files or remove the ps_data file. -- Dave Olson Life would be so much easier if we could just look at the source code.