论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2003-04-18 11:48 |只看该作者 |倒序浏览

Memory: 72236K (65944K) real, 66052K (61912K) virtual, 254636K free Page# 1/5

我内存是1G,怎么看到就这么小？谁能帮忙解释解释？谢谢！

xiaoguazi

白手起家

论坛徽章:: 0

2楼 [报告]

发表于 2003-04-19 15:36 |只看该作者

手头上没有hp的机器，兄弟，是不是抓错信息了？下面是linux的top帮助
TOP(1) Linux User\'s Manual TOP(1)

NAME
   top - display top CPU processes

SYNOPSIS
   top [-] [d delay] [p pid] [q] [c] [C] [S] [n iter]

DESCRIPTION
   top  provides  an  ongoing look at processor activity in real time.  It
   displays a listing of the most CPU-intensive tasks on the  system,  and
   can  provide  an interactive interface for manipulating processes.  It
   can sort the tasks by CPU usage, memory usage and runtime.  can be bet-
   ter  configured than the standard top from the procps suite.  Most fea-
   tures can either be selected by an interactive command or by specifying
   the  feature  in the  personal or system-wide configuration file. See
   below for more information.

COMMAND-LINE OPTIONS
   d Specifies the delay between screen updates. You can  change  this
      with the s interactive command.

   p Monitor  only  processes  with given process id.  This flag can be
      given up to twenty times. This option is neither available inter-
      actively nor can it be put into the configuration file.

   q This  causes  top  to refresh without any delay. If the caller has
      superuser priviledges, top runs with the highest  possible prior-
      ity.

   S Specifies  cumulative  mode, where each process is listed with the
      CPU time that it as well as its dead children has spent.  This  is
      like  the  -S  flag to  ps(1).  See the discussion below of the S
      interactive command.

   s Tells top to run in secure mode.  This  disables  the  potentially
      dangerous  of  the interactive commands (see below).  A secure top
      is a nifty thing to leave running on a spare terminal.

   i Start top ignoring any idle or zombie processes. See the  interac-
      tive command i below.

   C display  total  CPU states in  addition to individual CPUs. This
      option only affects SMP systems.

   c display command line instead of the command name only. The default
      behaviour has been changed as this seems to be more useful.

   n Number  of iterations. Update the display this number of times and
      then exit.

   b Batch mode. Useful for sending output from top to  other  programs
      or to  a  file. In  this mode, top will not accept command line
      input.  It runs  until  it produces  the number of  iterations
      requested  with the n option or until killed. Output is plain text
      suitable for display on a dumb terminal.

FIELD DESCRIPTIONS
   top displays a variety of information about the processor  state. The
   display is updated every 5 seconds by default, but you can change that
   with the d command-line option or the s interactive command.

   uptime
      This line displays the time the system has been up, and the three
      load  averages  for the system.  The load averages are the average
      number of process ready to run during the last 1, 5 and  15  min-
      utes.  This line is just like the output of uptime(1).  The uptime
      display may be toggled by the interactive l command.

   processes
      The total number of processes running at  the  time of  the  last
      update. This  is also broken down into the number of tasks which
      are running, sleeping,  stopped,  or  undead.  The processes  and
      states display may be toggled by the t interactive command.

   CPU states
      Shows  the percentage of CPU time in user mode, system mode, niced
      tasks, and idle.  (Niced tasks are only those whose nice value  is
      negative.) Time spent in niced tasks will also be counted in sys-
      tem and user time, so the total will be more than 100%.  The  pro-
      cesses and states display may be toggled by the t interactive com-
      mand.

   Mem  Statistics on memory usage, including total available memory, free
      memory,  used  memory, shared memory, and memory used for buffers.
      The display of memory information may be toggled by the m interac-
      tive command.

   Swap Statistics on  swap  space, including total swap space, available
      swap space, and used swap space.  This and Mem are just  like  the
      output of free(1).

   PID  The process ID of each task.

   PPID The parent process ID each task.

   UID  The user ID of the task\'s owner.

   USER The user name of the task\'s owner.

   PRI  The priority of the task.

   NI The nice value of the task.  Negative nice values are higher pri-
      ority.

   SIZE The size of the task\'s code plus data plus stack space,  in kilo-
      bytes, is shown here.

   TSIZE
      The code  size  of the task. This gives strange values for kernel
      processes and is broken for ELF processes.

   DSIZE
      Data + Stack size. This is broken for ELF processes.

   TRS  Text resident size.

   SWAP Size of the swapped out part of the task.

   D Size of pages marked dirty.

   LC Last used processor.  (That this changes from time to time is  not
      a  bug;  Linux intentionally uses weak affinity.  Also notice that
      the very act of running top may break weak affinity and cause more
      processes  to  change  current CPU more often because of the extra
      demand for CPU time.)

   RSS  The total amount of physical memory used by the  task,  in kilo-
      bytes,  is shown  here.  For ELF processes used library pages are
      counted here, for a.out processes not.

   SHARE
      The amount of shared memory used by the task is shown in this col-
      umn.

   STAT The state of  the task is shown here. The state is either S for
      sleeping, D for uninterruptible sleep, R for running, Z  for  zom-
      bies,  or  T  for  stopped or traced. These states are modified by
      trailing < for a process with negative nice value, N for a process
      with  positive  nice value, W for a swapped out process (this does
      not work correctly for kernel processes).

   WCHAN
      depending on the availablity of  either  /boot/psdatabase  or  the
      kernel  link  map  /boot/System.map this shows the address or the
      name of the kernel function the task currently is sleeping in.

   TIME Total CPU time the task has used since it started. If  cumulative
      mode  is on, this also includes the CPU time used by the process\'s
      children which have died.  You can set cumulative mode with the  S
      command  line  option or toggle it with the interactive command S.
      The header line will then be changed to CTIME.

   %CPU The task\'s share of the CPU time since  the last  screen  update,
      expressed as a percentage of total CPU time per processor.

   %MEM The task\'s share of the physical memory.

   COMMAND
      The task\'s command name, which will be truncated if it is too long
      to be displayed on one line.  Tasks in memory  will have  a  full
      command line, but swapped-out tasks will only have the name of the
      program in parentheses (for example, \"(getty)\".

   A , WP
      these fields from the kmem top are not supported.

INTERACTIVE COMMANDS
   Several single-key commands are recognized while top is running. Some
   are disabled if the s option has been given on the command line.

   space
      Immediately updates the display.

   ^L Erases and redraws the screen.

   h or ?
      Displays a help screen giving a brief summary of commands, and the
      status of secure and cumulative modes.

   k Kill a process.  You will be prompted for the PID of the task, and
      the signal to send to it.  For a normal kill, send signal 15.  For
      a sure, but rather abrupt, kill, send signal 9.  The default  sig-
      nal,  as with kill(1), is 15, SIGTERM.  This command is not avail-
      able in secure mode.

   i Ignore idle and zombie processes.  This is a toggle switch.

   I Toggle between Solaris (CPU percentage divided by total number  of
      CPUs)  and Irix  (CPU  percentage calculated solely by amount of
      time) views.  This is a toggle switch that affects only  SMP  sys-
      tems.

   n or #
      Change  the number of processes to show.  You will be prompted to
      enter the number.  This overrides automatic determination  of  the
      number  of processes  to show, which is based on window size mea-
      surement.  If 0 is specified, then top will show as many processes
      as will fit on the screen; this is the default.

   q Quit.

   r Re-nice  a process. You will be prompted for the PID of the task,
      and the value to nice it to.  Entering a positve value will cause
      a  process to be niced to negative values, and lose priority.  If
      root is running top, a negative value can be  entered,  causing  a
      process  to get a higher than normal priority.  The default renice
      value is 10.  This command is not available in secure mode.

   S This toggles cumulative mode, the equivalent of ps -S, i.e.,  that
      CPU times will  include  a process\'s defunct children.  For some
      programs, such as compilers,  which work  by  forking  into  many
      seperate  tasks,  normal mode will make them appear less demanding
      than they actually are.  For others, however, such as  shells  and
      init,  this behavior is correct.  In any case, try cumulative mode
      for an alternative view of CPU use.

   s Change the delay between updates.  You will be prompted  to enter
      the delay time,  in seconds, between updates.  Fractional values
      are recognized down to microseconds.  Entering 0 causes continuous
      updates. The  default  value is 5 seconds.  Note that low values
      cause nearly unreadably fast displays, and greatly raise the load.
      This command is not available in secure mode.

   f or F
      Add fields to display or remove fields from the display. See below
      for more information.

   o or O
      Change order of displayed fields. See below for more  information.

   l toggle display of load average and uptime information.

   m toggle display of memory information.

   t toggle display of processes and CPU states information.

   c toggle display of command name or full command line.

   N sort tasks by pid (numerically).

   A sort tasks by age (newest first).

   P sort tasks by CPU usage (default).

   M sort tasks by resident memory usage.

   T sort tasks by time / cumulative time.

   W Write  current  setup to ~/.toprc. This is the recommended way to
      write a top configuration file.

The Field and Order Screens
   After pressing f, F, o or O you will be shown a screen  specifying  the
   field  order  on the top line and short descriptions of the field con-
   tents. The field order string uses the following syntax: If the letter
   in  the filed string corresponding to a field is upper case, the field
   will be displayed.  This is furthermore indicated  by  an  asterisk  in
   front of the field description. The order of the fields corresponds to
   the order of the letters in the string.
From the field select screen you can toggle the display of a field  by
   pressing the corresponding letter.
From the order screen you may move a field to the left by pressing the
   corresponding upper case letter resp. to the  right  by pressing  the
   lower case one.

Configuration Files
   Top  reads  it\'s default  configuration from two files, /etc/toprc and
   ~/.toprc.  The global configuration file may be used  to restrict  the
   usage  of  top to the secure mode for non-priviledged users. If this is
   desired, the file should contain a \'s\' to specify  secure  mode and  a
   digit  d (2<=d<=9) for the default delay (in seconds) on a single line.
   The personal configuration file contains two lines. The first line con-
   tains lower and upper letters to specify which fields in what order are
   to be displayed. The letters correspond to the letters in the Fields or
   Order  screens  from top. As this is not very instructive, it is recom-
   mended to select fields and order in a running top process and to  save
   this  using  the W interactive command. The second line is more inter-
   esting (and important). It contains information on the  other  options.
   Most  important, if you have saved a configuration in secure mode, you
   will not get an insecure top without removing the lower \'s\'  from  the
   second line of your ~/.toprc.  A digit specifies the delay time between
   updates, a capital \'S\' cumulative mode, a lower \'i\'  no-idle  mode,  a
   capital \'I\'  Irix  view. As in interactive mode, a lower \'m\', \'l\', and
   \'t\' suppresses the display of memory,  uptime  resp.  process  and  CPU
   state  information. Currently changing the default sorting order (by
   CPU usage) is not supported.

NOTES
   This proc-based top works by reading the files in the proc  filesystem,
   mounted on /proc.  If /proc is not mounted, top will not work.

   %CPU  shows  the cputime/realtime  percentage  in  the period of time
   between updates. For the first update, a short delay is used, and  top
   itself  dominates the CPU usage. After that, top will drop back, and a
   more reliable estimate of CPU usage is available.

   The SIZE and RSS fields don\'t count the page tables and the task_struct
   of  a  process; this is at least 12K of memory that is always resident.
   SIZE is the virtual size of the process (code+data+stack).

   Keep in mind that a process must die for its time to be recorded on its
   parent  by  cumulative  mode.  Perhaps more useful behavior would be to
   follow each process upwards, adding time, but that would be more expen-
   sive,  possibly prohibitively  so.  In any case, that would make top\'s
   behavior incompatible with ps.

FILES
   /etc/toprc The global configuration file.  ~/.toprc The personal  con-
   figuration file.

SEE ALSO
   ps(1), free(1), uptime(1), kill(1), renice(1).

BUGS
   If  the window is less than about 70x7, top will not format information
   correctly.
Many fields still have problems with ELF processes.
the help screens are not yet optimized for windows with less  than  25
   lines

AUTHOR
   top  was originally written by Roger Binns, based on Branko Lankester\'s
   <lankeste@fwi.uva.nl> ps program. Robert Nation
   <nation@rocket.sanders.lockheed.com>  re-wrote  it significantly to use
   the proc filesystem,  based  on Michael K.  Johnson\'s <johnsonm@red-
   hat.com> proc-based ps program. Michael    Shields
   <mjshield@nyx.cs.du.edu> made many changes, including secure and cumu-
   lative modes and a general cleanup.  Tim Janik <timj@gtk.org> added age
   sorting and the ability to monitor  specific  processes through their
   ids.

   Helmut Geyer <Helmut.Geyer@iwr.uni-heidelberg.de> Heavily changed it to
   include support for configurable fields and other new options, and  did
   further cleanup and use of the new readproc interface.

   The \"b\" and \"n\" options contributed by George Bonser
   <george@captech.com> for CapTech IT Services.

   Please send bug reports to <acahalan@cs.uml.edu>

Linux Feb 1 1993 TOP(1)

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

miko

白手起家

论坛徽章:: 0

3楼 [报告]

发表于 2003-04-19 23:05 |只看该作者

read this.

OVERVIEW OF PHYSICAL AND VIRTUAL MEMORY
The memory management system is designed to make memory resources available safely and efficiently among threads and processes:
?It provides a complete address space for each process, protected from all other processes.
?It enables program size to be larger than physical memory.
?It decides which threads and processes reside in physical memory and manipulates threads and processes in and out of memory.
?It manages the parts of the virtual address space of a thread or process not in physical memory and determines what portions of the address space should reside in physical memory.
?It allows efficient sharing of memory between processes.
The data and instructions of any process (a program in execution) or thread of execution within a process must be available to the CPU by residing in physical memory at the time of execution.
To execute a process, the kernel creates a per-process virtual address space that is set up by the kernel; portions of the virtual space are mapped onto physical memory. Virtual memory allows the total size of user processes to exceed physical memory. Through \"demand paging\", HP-UX enables you to execute threads and processes by bringing virtual pages into main memory only as needed (that is, \"on demand\"

and pushing out portions of a process\'s address space that have not been recently used.
The term \"memory management\" refers to the rules that govern physical and virtual memory and allow for efficient sharing of the system\'s resources by user and system processes.
The system uses a combination of pageout and deactivation to manage physical memory.  Paging involves writing recently unreferenced pages from main memory to disk from time to time. A page is this smallest unit of physical memory that can be mapped to a virtual address with a given set of access attributes. On a loaded system, total unreferenced pages might be a large fraction of memory.
Deactivation takes place if the system is unable to maintain a large enough free pool of physical memory. When an entire process is deactivated, the pages associated with the process can be written out to secondary storage, since they are no longer referenced. A deactivated process cannot run, and therefore, cannot reference its data.
Secondary storage supplements physical memory.  The memory management system monitors available memory and, when it is low, writes out pages of a process or thread to a secondary storage device called a swap device.  The data is read from the swap device back into physical memory when it is needed for the process to execute.
Pages
Pages are the smallest contiguous block of physical memory that can be allocated for storing data and code. Pages are also the smallest unit of memory protection.  The page size of all HP-UX systems is four kilobytes.
On a PA-RISC system, every page of physical memory is addressed by  a physical page number (PPN), which is a software \"reduction\" of the physical page number from the physical address.  Access to pages (and thus to the data they contain) are done through virtual addresses, except under specific circumstances.1
Virtual Addresses
When a program is compiled, the compiler generates virtual addresses for the code. Virtual addresses represent a location in memory.  These virtual addresses must be mapped to physical addresses (locations of the physical pages in memory) for the compiled code to execute. User programs use virtual addresses only.
The kernel and the hardware coordinate a mapping of these virtual and physical addresses for the CPU, called \"address translation,\" to locate the process in memory.
A PA-RISC virtual address consists of a space identifier (SID) and an offset.
?Each space ID represents a 4 GB unit of virtual memory.
?The offset portion of a virtual address is the offset into this space.
Table 1-1 Format of a 48-bit virtual address
Every process running on a PA-RISC processor shares a 48-bit (or larger, depending on HP-PA architecture version) global virtual address space with the kernel and with all other processes running on that machine. Although any process can create and attempt to read or write any virtual address, the kernel uses page granularity access control mechanisms to prevent unwanted interference between processes.
When a virtual page is \"paged\" into physical memory, free physical pages are allocated to it from the free list.  These pages may be randomly scattered throughout the memory depending on their usage history.  Translations are needed to tell the processor where the virtual pages are loaded.  The process of translating the virtual into physical address is called virtual address translation.
Potentially the virtual address space can be much greater than the physical address space.  The virtual memory system enables the CPU to execute programs much larger than the available physical memory and allows you run many more programs at a time than you could without a virtual memory system.
Demand Paging
For a process to execute, all the structures for data, text, and so on have to be set up.  However, pages are not loaded in memory until they are \"demanded\" by a process -- hence the term, demand paging. Demand paging allows the various parts of a process to be brought into physical memory as the process needs them to execute. Only the working set of the process, not the entire process, need be in memory at one time. A translation is not established until the actual page is accessed.
THE ROLE OF PHYSICAL MEMORY
Memory is the \"container\" for data storage; the general repository for high-speed data storage is close to the CPU, and is termed random access memory (RAM) or \"main memory.\" For the CPU to execute a process, the code and data referenced by that process must reside in random access memory (RAM). RAM holds data during process execution in two even-faster implementations of memory, registers and cache, found on the processor.  RAM is shared by all processes.
The more main memory in the system, the more data the system can access and the more (or larger) processes it can retain and execute without having to page or cause deactivation as frequently.  Memory-resident resources (such as page tables) also take up space in main memory, reducing the space available to applications.
At boot time, the system loads HP-UX from disk into RAM, where it remains memory-resident until the system is shut down.
User programs and commands too are loaded from disk into RAM.  When a program terminates, the operating system frees the memory used by the process.
Disk access is slow compared to RAM access. Excessive disk access can lead to increased latency or reduced throughput and can lead to the disk access becoming the bottleneck in the system. To avoid this, you need to do some sort of buffering. Buffering, paging, and deactivation algorithms optimize disk access and determine when data and code for currently running programs are returned from RAM to disk. When a user or system program writes data to disk, the data is either written directly to RAM (if raw data) or buffered in what is called buffer cache and written to disk in relatively big chunks. Programs also read files and database structures from disk into RAM.  When you issue the sync command before shutting down a system, all modified buffers of the buffer cache are flushed (written) out to disk.
Figure 1-1 Physical memory available to processes
Available Memory
The amount of main memory not reserved for the kernel is termed available memory. Available memory is used by the system for executing user processes.
Not all physical memory is available to user processes.  Kernel text and initialized data occupy about 8 MB of RAM.
Instead of allocating all its data structures at system initialization, the HP-UX kernel dynamically allocates and releases some kernel structures as needed by the system during normal operation.  This allocation comes from the available memory pool; thus, at any given time, part of the available memory is used by the kernel and the remainder is available for user programs.
Physical address space is the entire range of addresses used by hardware (4GB), and is divided into memory address space, processor-dependent code (PDC) address space, and I/O address space. The next figure shows the expanse of memory available for computation. Memory address space takes up most of the system address space, while address space allotted to PDC and I/O consume a relatively small range of addresses.
Figure 1-2 Major sections of system address space.
Lockable Memory
Pages kept in memory for the lifetime of a process by means of a system call (such as mlock, plock, or shmctl) are termed lockable memory.  Locked memory cannot be paged and processes with locked memory cannot be deactivated.  Typically, locked memory holds frequently accessed programs or data structures, such as critical sections of application code.  Keeping them memory-resident improves application performance.
The lockable_mem variable tracks how much memory can be locked.
Available memory is a portion of physical memory, minus the amount of space required for the kernel and its data structures. The initial value of lockable_mem is the available memory on the system after boot-up, minus the value of the system parameter, unlockable_mem.
The value of lockable memory depends on several factors:
?The size of the kernel varies, depending on the number of interface cards, users, and values of the tunable parameters.
?Available memory varies from system to system.
?The system parameter unlockable_mem is a kernel tunable parameter. Changing the value of unlockable_mem alters the default value of lockable_mem also.
HP-UX places no explicit limits on the amount of available memory you may lock down; instead, HP-UX restricts how much memory cannot be locked.
Other kernel resources that use memory (such as the dynamic buffer cache) can cause changes.
?As memory is used, the amount of memory that can be locked decreases.
?As memory is freed up, the amount of memory that can be locked increases.
As the amount of memory that has been locked down increases, existing processes compete for a smaller and smaller pool of usuable memory. If the number of pages in this remaining pool of memory falls below the paging threshold called lotsfree, the system will activates its paging mechanism, by scheduling vhand in an attempt to keep a reasonable amount of memory free for general system use.
Care must be taken to allow sufficient space for processes to make forward progress; otherwise, the system is forced into paging and deactivating processes constantly, to keep a reasonable amount of memory free.