lewis@CASTOR.WUSTL.EDU (Lewis Yuchan) (07/12/89)
Is there any way to reduce the size of /debug, as it acts like it takes
up 50Mb on our system? Is this a wise thing to do? Thanks.
--
lewis@castor.wustl.edu "The blonde spat at me and threw
Lewis Yuchan Geer herself on my leg and tried to bite
Campus Box 8131 that. I cracked her on the head with
Radiation Oncology/MIR the gun, not very hard, and tried to
Washington University Medical School stand up. She rolled down my legs
St. Louis, MO 63110 and wrapped her arms around them. I
(314) 362-2951 fax: (314) 362-8521 fell back on the davenport. The
blonde was strong with the madness of
love or fear, or a mixture of both, or maybe she was just strong."
-- Raymond Chandler, _The Big Sleep_lewis@CASTOR.WUSTL.EDU (Lewis Yuchan) (07/13/89)
Return-path: info-iris-request@vmb.brl.mil
Return-path: lewis@castor
Received: from VMB.BRL.MIL by CCVAX.IASTATE.EDU; Wed, 12 Jul 89 19:29 CST
Received: by VMB.BRL.MIL id aa04581; 12 Jul 89 16:37 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab11926; 12 Jul 89 12:30 EDT
Received: from adm.brl.mil by VMB.BRL.MIL id aa11832; 12 Jul 89 12:10 EDT
Received: from wucs1.wustl.edu by ADM.BRL.MIL id aa17114; 12 Jul 89 11:59 EDT
Received: from wucs2.wustl.edu by wucs1.wustl.edu (5.59/1.35); id AA19079; Wed,
12 Jul 89 10:40:11 CDT
Received: from castor.wustl.edu by wucs2. (4.0/SMI-4.0) id AA08066; Wed, 12 Jul
89 10:42:16 CDT
Received: by castor.wustl.edu (5.52/SGI) id AA02390; Wed, 12 Jul 89 10:37:25 CDT
Date: Wed, 12 Jul 89 10:37:25 CDT
From: Lewis Yuchan <lewis@castor.wustl.edu>
Subject: /debug size
To: info-iris@BRL.MIL
Message-Id: <8907121537.AA02390@castor.wustl.edu>
Is there any way to reduce the size of /debug, as it acts like it takes
up 50Mb on our system? Is this a wise thing to do? Thanks.
--
lewis@castor.wustl.edu "The blonde spat at me and threw
Lewis Yuchan Geer herself on my leg and tried to bite
Campus Box 8131 that. I cracked her on the head with
Radiation Oncology/MIR the gun, not very hard, and tried to
Washington University Medical School stand up. She rolled down my legs
St. Louis, MO 63110 and wrapped her arms around them. I
(314) 362-2951 fax: (314) 362-8521 fell back on the davenport. The
blonde was strong with the madness of
love or fear, or a mixture of both, or maybe she was just strong."
-- Raymond Chandler, _The Big Sleep_
fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) (07/14/89)
>> Is there any way to reduce the size of /debug, as it acts like it takes >> up 50Mb on our system? Is this a wise thing to do? Thanks. As far as I can determine, this is not physical disk space, but rather some sort of virtual disk. The size allocated to /debug changes as users on the system do thier work. Even if you were to remove the files in /debug, you would not gain any disk space to use for permanent storage, so its probably not wise to do anything with it. So why even show it in the "df" display? These are just some observations, since no one from SGI offered any advice, I thought I'd try to help. Now, if I could just find a fast and reliable polygon fill algorithm.. -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------
jh34607@suntc.UUCP (john howell) (07/14/89)
lewis@castor writes ... >Is there any way to reduce the size of /debug, as it acts like it takes >up 50Mb on our system? Is this a wise thing to do? Thanks. I believe that /debug represents the swap space on your system. Personally I think 50 MB is just barely enough.
dunlap@bigboote.csd.sgi.com (D. Christopher Dunlap) (07/15/89)
In article <8907121537.AA02390@castor.wustl.edu>, lewis@CASTOR.WUSTL.EDU (Lewis Yuchan) writes: > Is there any way to reduce the size of /debug, as it acts like it takes > up 50Mb on our system? Is this a wise thing to do? Thanks. > > -- > > lewis@castor.wustl.edu "The blonde spat at me and threw > Lewis Yuchan Geer herself on my leg and tried to bite The "/debug" filesystem doesn't take up any space. You can look at it as a sort of logical construct that acts as a window into the virtual memory space. It's size is the combination of Real User memory space and Swap Space. (So I guess reducing swapspace would make /debug smaller, but that's usually not a good idea. Most people want to INCREASE swapsace.) The Files shown are actually the processes that are runnning. Things like debugers use /debug as a way to get at running processes in a more elegant and reasonable way. I think there was a more lucid discussion of how all this works a while back in this newsgroup. chris -- D. Christopher Dunlap email: dunlap@sgi.sgi.com Hardware Product Support Customer Support Division Silicon Graphics Computer Systems
chris@spock.ame.arizona.edu (Chris Ott) (07/16/89)
lewis@castor.wustl.edu (Lewis Yuchan Geer) writes: > Is there any way to reduce the size of /debug, as it acts like it takes > up 50Mb on our system? Is this a wise thing to do? Thanks. No, it's not a wise thing to do. The /debug partition is actually the swap partition for the IRIX system. Reducing its size will reduce the amount of virtual memory available to all of the processes on the system. fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) writes: > As far as I can determine, this is not physical disk space, but rather some > sort of virtual disk. No, it is actual, physical disk space. It is required for virtual memory. > The size allocated to /debug changes as users on the > system do thier work. This is _not_ true. The amount of space _available_ in /debug changes as users do their work, but the amount allocated is determined when the hard disk is partitioned, just like the / and /usr filesystems. > Even if you were to remove the files in /debug, you would not gain any > disk space to use for permanent storage, so its probably not wise to do > anything with it. Considering that each file in the /debug partition represents the virtual memory of a process on the system, I'd say deleting any of them would be unwise, at best. Notice, also (in "df") that /debug's filesystem type is "dbg", while the others are "efs" or "nfs". I wouldn't advise writing any normal files there, even though it appears to be possible. Do an "ls" on /debug. Notice that all of the files' names are numbers, rather than words. Now do a "ps". Notice that most of the PIDs listed by "ps" match the file names in the /debug partition. Reading and writing these files is the same as reading and writing the memory space of the corresponding process. It is used mostly by the debugger for reading and writing variables, hence the name /debug. Quite an ingenious idea on Silicon Graphics' part, in my opinion (if it was they who invented it). > So why even show it in the "df" display? Probably because it's a file system, just like / and /usr. The amount of memory available (displayed by "df") represents the amount of virtual memory left on your system. Personally, I like it. > since no one from SGI offered any advice, I > thought I'd try to help. Yeah, I'm surprised at this. They're usually pretty helpful. Maybe it's because it's the weekend... Chris ------------------------------------------------------------------------------- Chris Ott Forensic Productions, Inc. Infatuation is blind, not love. A Tucson, Arizona person in love can see the other's faults, but loves them anyway. Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris -------------------------------------------------------------------------------
bul@ANACONDA.STANFORD.EDU (Byung-Uk Lee) (07/17/89)
One problem with the /debug size is that it builds up. My guess is that there are some processes that claims swap spaces even after the process is killed. The only way to refresh the /debug directory seems to be rebooting the machine. Byung-Uk Lee
dunlap@bigboote.csd.sgi.com (D. Christopher Dunlap) (07/17/89)
In article <1008@amethyst.math.arizona.edu>, chris@spock.ame.arizona.edu (Chris Ott) writes: > > lewis@castor.wustl.edu (Lewis Yuchan Geer) writes: > > Is there any way to reduce the size of /debug, as it acts like it takes > > up 50Mb on our system? Is this a wise thing to do? Thanks. > > No, it's not a wise thing to do. The /debug partition is actually > the swap partition for the IRIX system. Reducing its size will reduce > the amount of virtual memory available to all of the processes on the > system. > Almost right. It's actually ALL the virtual space. Real memory AND swapspace. > Do an "ls" on /debug. Notice that all of the files' names are > numbers, rather than words. Now do a "ps". Notice that most of the PIDs > listed by "ps" match the file names in the /debug partition. Reading and > writing these files is the same as reading and writing the memory space of > the corresponding process. It is used mostly by the debugger for reading > and writing variables, hence the name /debug. Quite an ingenious idea on > Silicon Graphics' part, in my opinion (if it was they who invented it). > Yep. That's how it works. I'm not sure of the origin of the idea. > > So why even show it in the "df" display? > > Probably because it's a file system, just like / and /usr. The > amount of memory available (displayed by "df") represents the amount of > virtual memory left on your system. Personally, I like it. > I think it's mostly to make work for the Hotline. ;-} > > since no one from SGI offered any advice, I > > thought I'd try to help. > > Yeah, I'm surprised at this. They're usually pretty helpful. Maybe > it's because it's the weekend... > > Chris Hmmmm. I posted an article some time ago. (When I first saw the original) Maybe it didn't get out? Or maybe my .signature isn't getting stuck on my postings all of a sudden? So I'll put one on manually just to be sure... See ya, chris ------ D. Christopher Dunlap Support Team Manager Hardware Product Support (aka "The Geometry Hotline") Customer Support Division Silicon Graphics Computer Systems -- D. Christopher Dunlap email: dunlap@sgi.sgi.com Hardware Product Support Customer Support Division Silicon Graphics Computer Systems
mitch@rock.sgi.com (Thomas P. Mitchell) (07/18/89)
In article <8907161727.AA17013@anaconda.Stanford.EDU> bul@ANACONDA.STANFORD.EDU (Byung-Uk Lee) writes: > >One problem with the /debug size is that it builds up. My guess is that there >are some processes that claims swap spaces even after the process is killed. >The only way to refresh the /debug directory seems to be rebooting the machine Please, the size of /debug is not real. /debug is a data structure which is used by the debugging tools to locate running processes. Users need do nothing with it. Except perhaps omit it in backups. The size is not real. Remember one of the primary goals of Unix/Irix(1) is to reuse code. When 'dbx' was enhanced to permit attaching running processes the model of a filesystem was apparently selected because there was a lot of code which was easy to reuse. As a side effect things like 'df' could return interesting things. The nature of 'interesting' is a result of the whims of the kernel programer. In other words things may change. What is documented is the -p flag to dbx. Let us review; /debug was designed as a hook for dbx. ^ *PERIOD* It happens to look like a filesystem. But that makes things like open/close/lseek etc. work in ordinary ways. Remember the part about reusing code. -------- (1) Both Trademarks. UNIX is AT&T's Irix is Silicon Graphics' -- Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows. Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.
mitch@rock.sgi.com (Thomas P. Mitchell) (07/19/89)
One of our engineers sent me some gentle flames about my last posting. The following is a summary of his note and our discussions. Both of us were concerned about a possible memory leak in the OS or some application. My initial posting was to keep people from using the equivalent of cotton clothes line to climb mountains. Now on to a possible real problem. A memory leak in SGI code is wrong and needs to be identified so we can fix it. As I indicated /debug can return fun things. In article <215@odin.SGI.COM> mitch@rock.sgi.com (Thomas P. Mitchell) writes: >In article <8907161727.AA17013@anaconda.Stanford.EDU> bul@ANACONDA.STANFORD.EDU (Byung-Uk Lee) writes: >> >>One problem with the /debug size is that it builds up. > >are some processes that claims swap spaces even after the process is killed. > >The only way to refresh the /debug directory seems to be rebooting the machine > > Please, the size of /debug is not real. /debug is a data > structure which is used by the debugging tools to locate > running processes. Users need do nothing with it. Except > perhaps omit it in backups. > > The size is not real. Remember one of the primary goals of > Unix/Irix(1) is to reuse code. When 'dbx' was enhanced to > permit attaching running processes the model of a filesystem > was apparently selected because there was a lot of code > which was easy to reuse. As a side effect things like 'df' > could return interesting things. The nature of > 'interesting' is a result of the whims of the kernel > programer. In other words things may change. > > What is documented is the -p flag to dbx. Let us review; > /debug was designed as a hook for dbx. > ^ *PERIOD* Thom is correct in that /debug is modelled after an early version of the the AT&T /proc mechanism. He is also correct in that /debug was implemented as a facility for multiprocess/arbitrary process debugging. The /debug mechanism replaced the ptrace mechanism for process control. AT&T will be implementing /proc in the System V.4 release. The semantics of /debug may be changed or replaced by the new /proc mechanism in the future. Though Thom refers to other "artifacts" of /debug being a file system as whimsical, I counter that much of what you see is a logical extension of the file system concept. For instance do a "df -ik /debug" to show the number of inodes and display all information in 1KB blocks. For instance: Filesystem Type kbytes use avail %use iuse ifree %iuse Mounted /debug dbg 51048 16664 34384 33% 46 50 48% /debug The field "iuse" shows the number of file system inodes in use. There is one inode per process file. Thus there are 46 processes running on this system. "ifree" shows the number of available inodes left on the file system. This means I could run 50 more processes (one inode per process) on the system. The default process limit (/usr/sysgen/kernel:#define NPROC) on a 4D is 96 processes. At one inode per process, we have 96 available inodes on /debug. 46 inodes in use plus 50 inodes free equals 96 inodes. The "kbytes" field represents the total size of the swap partition (a very real size). The "use" field indicates how much of my swap partition is in use and "avail" shows the remainder. Now, lets do an "ls -lsa /debug". total 42253 4 dr-xr-xr-x 2 root sys 1568 Jul 18 10:45 . 1 drwxr-xr-x 17 root sys 512 Jul 12 17:21 .. 232 -rw------- 1 root sys 118784 Jul 12 17:20 00001 . . . 2184 -rw------- 1 root engr 1118208 Jul 12 17:26 00240 1144 -rw------- 1 ciemo engr 585728 Jul 12 17:26 00241 472 -rw------- 1 ciemo engr 241664 Jul 12 17:26 00243 2320 -rw------- 1 root engr 1187840 Jul 12 17:58 00477 464 -rw------- 1 ciemo engr 237568 Jul 12 17:58 00478 The first column (ls -s) represents the size of the process in swap in 512 byte blocks. The permissions show that only root can write into the swap partition. Imagine all of the security breaches that could occur if just anybody could write into the swap partition. No, no, no. You don't want to be able to write arbitrary data into the swap space. Notice, also, that no one else has write permissions for my process but myself. This is the permissions of the running process and all writing into the process is done on my behalf by the kernel (root). The number of links is 1 (one inode per process). The uid/gid are those of the running process. The size in bytes is the size of the virtual memory taken up by the process. The date shows the creation time of the process (a liberty taken since "ls" usually shows the last modification time). The file name is the process id. To correct Thom, these numbers are real. I hate to admit that something running on your system may be growing due to a memory leak. It would be most useful to yourself and SGI if you could watch your system and periodically note the change in size of long running processes. Try doing an "ls -s > /usr/tmp/ls.atboot" right after booting your system. If your system seems to have lost swap space "permanently", do another "ls -s > /usr/tmp/ls.chk1". You might want to sample at a couple points to get a good handle on memory usage. The representations of /debug by "ls" and "df" match up well with the concept of processes as files. The caveat here is that changes in IRIX and adoption of external standards will possibly change the semantics of these operations of /debug. > > It happens to look like a filesystem. But that makes things > like open/close/lseek etc. work in ordinary ways. Remember > the part about reusing code. > > -------- > (1) Both Trademarks. > UNIX is AT&T's > Irix is Silicon Graphics' =============================================================================== Form: 27B-6 Submitted by: Central Services Operative, DC-473 Task: Duct repair Status: Emergency =============================================================================== Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.