[daip] [!8570]: AIPS - TVSERVER MEMORY ISSUE

[Eric Greisen]

Eric Greisen updated #8570
--------------------------

       Staff (Owner): Eric Greisen (was: -- Unassigned --)
                 Due: - Cleared - (was: 22 June 2016 02:22 PM)

TVSERVER MEMORY ISSUE
---------------------

           Ticket ID: 8570
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/8570
           Full Name: Christopher Stockdale
               Email: christopher.stockdale at mu.edu
             Creator: User
          Department: AIPS Data Reduction
       Staff (Owner): Eric Greisen
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: NRAO E2E
      Template Group: Default
             Created: 20 June 2016 02:22 PM
             Updated: 20 June 2016 03:31 PM
      Resolution Due: 28 June 2016 02:22 PM (7d 22h 51m)



This does not look like the usual problem which is discussed below from the AIPS Manager FAQ

The actual TV is called XAS and might need to be killed also.  But killing the TV by drastic means
(i.e. kill -9 , or the X in the upper right corner) is not a good idea.  The shared memory segments
are returned to the OS by the abort handler but drastic kills avoid the abort handler.  You may
have used up all the shared memory your machine will support.  A reboot is the easiest way
to clear this situation.   gentle ways to kill XAS are the verb KLEENEX is aips or opening the TV
window, putting the cursor in the window, and hitting the Esc key.

Eric Greisen 


Shared memory id failure on Macs: Invalid Argument

    After you follow the instructions below appropriate to your release of the Mac operating system, you must re-boot the computer. The control file for shared memory is read at boot time only. Note that a re-boot is not simply logging the current user out and then back in. You must do a full restart.

    The default Mac system limits shared memory pages to 4 Mbytes. When XAS starts it tells you that it is making a screen x pixels by y pixels. The memory you will need is at least 4 x y bytes, but this rounds upward rapidly. For the new large screens this is more than 8 Mbytes. On 10.3 and 10.4 systems, you can change this limit by changing (as root or admin) the rc file in /etc, adjusting the kern.sysv.shm* line to

             #Setting the shared memory to something a bit more reasonable.
                sysctl -w kern.sysv.shmmax=10485760
                sysctl -w kern.sysv.shmmin=1
                sysctl -w kern.sysv.shmmni=32
                sysctl -w kern.sysv.shmseg=8
                sysctl -w kern.sysv.shmall=4096
             

    If you are really lucky and have a 30-inch screen (2550 by 1500 pixels) then you will have to make the shmmax line even larger

                sysctl -w kern.sysv.shmmax=16777216
             

    Note that these are upper limits, so it does not hurt to set a value that might be larger than necessary for your system. The shmmax must be an integer multiple of the shmall which must be a power of 2 >= 1024. A 3190 by 958 screen was found to require the larger value above. I think this comes by n times (4096 / 4 bytes/word) has to be > 3190 leading to 4096 words per row. Then 958 * 4096 * 4 bytes = 15695872 or just a bit less than the 16777216.

    On the latest "leopard", "snow leopard", "lion", "mountain lion", and "yosemite" (X 10.5-10.10) systems, /etc/rc is gone and creating it will have no effect. You need to create an /etc/sysctl.conf file and put the values in it,

                kern.sysv.shmmax=10485760
                kern.sysv.shmmin=1
                kern.sysv.shmmni=32
                kern.sysv.shmseg=8
                kern.sysv.shmall=4096
             

    You should use the values you had when you were running tiger. Those could be in /Previous\ System/etc/rc, assuming you have "Previous System". So three different OS upgrades and three different ways to adjust the default shared memory. Note: You will need to reboot the system for the change in shared memory to take place. You can check if the shared memory changes happened by typing "sysctl kern.sysv" in a terminal or xterm window. Look for the kern.sysv.shm* values. If the values have not changed, make sure you haven't inadvertently left in "sysctl -w" in the /etc/sysctl.conf file or mis-typed one of the values. If the /etc/sysctl.conf file is not properly formatted, or shmmax is not an integer multiple of shmall, the shared memory will not be adjusted after the reboot.



------------------------------------------------------
Staff CP:  https://help.nrao.edu/staff