Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Which file in memory ?? 1
- Thread starter letis
- Start date
raztaboule
IS-IT--Management
lsof will also gives you open files.
svmon -P -p should help and can be more precise
but the "actually cached in RAM" can be hard to see.
good luck.
svmon -P -p should help and can be more precise
but the "actually cached in RAM" can be hard to see.
good luck.
-
1
- #3
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
I don't know why you'd want to (but am curious to know), but here's how, with caveats.
Caveat 1: Entire files aren't cached, just referenced pages (4096 byte chunks). File I/O uses the virtual memory manager's frame paging mechanism, and this results in the most recently used pages of files being kept in available real memory. The VMM activity related to file I/O is what shows up as PageIn and PageOut in topas.
Caveat 2: It's a moving target, as the least recently used pages of real memory (persistent, working, or a mix, depending on minperm/maxperm settings) are paged out (working) or dropped/flushed (persistent) when new pages are needed. So all you can really see is which files HAD pages in real memory when you started looking. The observer affects the observed. Very quantum mechanical.
How to do it:
1. start with the output of "svmon -S"
2. with the scripting language of your choice, extract the lines of ouput where Type is "pers" and the Description is of the form "device:inode". The Inuse column shows the number of 4096 byte pages of real memory cached from the file.
3. Since "device" is a logical volume special file, use lsfs to translate it into a filesystem name.
4. Use ncheck or find to locate the file with the reported inode in said filesystem.
5. Repeat steps 3 & 4 for each line extracted in step 2.
Steps 2-5 render the data generated in step 1 increasingly invalid as they run.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
Caveat 1: Entire files aren't cached, just referenced pages (4096 byte chunks). File I/O uses the virtual memory manager's frame paging mechanism, and this results in the most recently used pages of files being kept in available real memory. The VMM activity related to file I/O is what shows up as PageIn and PageOut in topas.
Caveat 2: It's a moving target, as the least recently used pages of real memory (persistent, working, or a mix, depending on minperm/maxperm settings) are paged out (working) or dropped/flushed (persistent) when new pages are needed. So all you can really see is which files HAD pages in real memory when you started looking. The observer affects the observed. Very quantum mechanical.
How to do it:
1. start with the output of "svmon -S"
2. with the scripting language of your choice, extract the lines of ouput where Type is "pers" and the Description is of the form "device:inode". The Inuse column shows the number of 4096 byte pages of real memory cached from the file.
3. Since "device" is a logical volume special file, use lsfs to translate it into a filesystem name.
4. Use ncheck or find to locate the file with the reported inode in said filesystem.
5. Repeat steps 3 & 4 for each line extracted in step 2.
Steps 2-5 render the data generated in step 1 increasingly invalid as they run.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
- Thread starter
- #4
well in fact I'm a curious guy, and I want to be able to check by myself how VMM and various vmtune/vmo settings can affect the caching of filesystem.
VMM is so funny sometimes, for information, without intending it, I could see one day an AIX system being able to go on unzipping a Maintenance Level package that I had deleted WHILE the extracting process was running (ftp'ed the file to a system, launched the gunzip in background, deleted the file, the extraction completed correctly a few minutes after) )
regards,
VMM is so funny sometimes, for information, without intending it, I could see one day an AIX system being able to go on unzipping a Maintenance Level package that I had deleted WHILE the extracting process was running (ftp'ed the file to a system, launched the gunzip in background, deleted the file, the extraction completed correctly a few minutes after
) )regards,
- Thread starter
- #5
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
letis said:I could see one day an AIX system being able to go on unzipping a Maintenance Level package that I had deleted WHILE the extracting process was running (ftp'ed the file to a system, launched the gunzip in background, deleted the file, the extraction completed correctly a few minutes after
That's already the case, or is at least documented as such. From the Technical Reference: Base Operating System and Extensions, Volume 2 documentation of the unlink subroutine:
"When all links to a file are removed and no process has the file open, all resources associated with the file are reclaimed, and the file is no longer accessible. If one or more processes have the file open when the last link is removed, the directory entry disappears. However, the removal of the file contents is postponed until all references to the file are closed."
Obviously, I'm also a curious guy.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
- Status
Similar threads
- Locked
- Question