W2H: How to use tableadmin

To improve performance (speed) of the W2H interface, there is usually a need to change slightly the GCG starting script genetics. This is not necessary on all platforms, but on most of them (we know about HP-UX where it was not needed, but it is true for sure for Solaris and IRIX, for example).

Unfortunately, it is not enough to copy the genetics script and make a change only in the copy. The telnet (terminal-oriented) GCG sessions call this script as well and when they use the unchanged genetics, then the W2H interface is affected as well.

We know from experience that a W2H administrator is not necessarily the same person as a GCG administrator. Therefore, often a W2H admin has to go to a GCG admin and convince him/her why a change in a GCG script is needed. The purpose of this document is to explain the background needed to understand the suggested change.

What to change

But, first of all, here is the change to do:

In genetics script, comment out the line:
$GCGUTILDIR/tableadmin

And that's it. At least almost, because tableadmin must be called from time to time - see below for two examples.

Why to change

GCG sessions use shared memory blocks. These blocks are created when a GCG session is started, and it takes time. Therefore, W2H interface wants to re-use just created blocks as much as possible. The W2H interface has built-it mechanism how to remember pointers to the memory blocks between several connections (a connection is needed, roughly speaking, to display a page in your browser).

However, the memory blocks exist (and can be re-used) only if nobody starts a tableadmin program in between W2H connections. And because every terminal GCG session starts genetics, which starts tableadmin, the memory blocks can be very often cleaned-up and W2H has to create them again and again - and it takes time. And more: the blocks are not cleaned up only by terminal sessions but also by other users using W2H itself (because every user starts his/her own GCG session at the beginning).

Therefore, you need to remove a calling of tableadmin from genetics script. But, if no tableadmin is called, who will clean the memory, at least at the end? Good point...

What to do more

From time to time tableadmin must be called to do the clean-up, otherwise your machine may run out of memory segments. For this we provide two concepts:

(preferred) whenever you run out of memory segments in genetics (i.e. tablemap fails), run tableadmin and try it a 2nd time
or/and
create a cronjob that calls tableadmin from time to time

To follow the 1st concept, just add a few lines of shell commands below the call of tablemap in genetics. This new code will be executed whenever tablemap fails. Example:

#
#	Check to see if the name service is already running, if it isn't
#	start the name service
#
# W2H change: we do not want to kill tables all the times
#             because people using w2h don't have a shell
#             and would loose their tables.
# $GCGUTILDIR/tableadmin
  $GCGUTILDIR/symbol -q GCGVersion; set verSet=$status
  if ( ! $?GCGNID || ( $verSet != 0 ) )  then
    if ( ! $?NFLAGS )  then
      setenv GCGNID `$GCGUTILDIR/tablemap`
    else
      setenv GCGNID `$GCGUTILDIR/tablemap $NFLAGS`
    endif
  endif

# W2H change: if tablemap failed, try it once more, but run
#             tableadmin first to clean up unused tables
  if ( $GCGNID == "" )  then
     echo "try it once more:"
     $GCGUTILDIR/tableadmin
     if ( ! $?NFLAGS )  then
        setenv GCGNID `$GCGUTILDIR/tablemap`
     else
        setenv GCGNID `$GCGUTILDIR/tablemap $NFLAGS`
     endif
  endif
#
#	This symbol is set ASAP in order that it can serve as evidence that
#	name service is running.
#
....

If you want to ensure that unused memory segments are not hanging around on your system for a long time (or you don't want to do the "bigger" change in genetics suggested in the 1st conept), you need to create a cronjob that calls tableadmin.

Calling tableadmin from a cronjob does no harm to terminal sessions, neither to W2H sessions: terminal sessions are not affected at all, because of the running GCG shell, and W2H sessions will be restarted automatically (with a time penalty but it happens only once in several hours, so who cares?).

The tableadmin does not need a GCG environment or any other specialties. It can be called directly from a cronjob. In fact it doesn't even matter, who calls tableadmin. Every user on a GCG computer can initiate a table clean-up by calling tableadmin (although, fortunately for W2H, users don't do this :-)).

The frequency of the cronjob depends on

the general amount of users,
the amount of users quitting GCG without calling exitgcg,
the amount of memory segments allowed in the operating system.

If you are not sure, start with calling tableadmin every six hours. A record for such cronjob is:

0 0,6,12,18 * * * /gcg/gcgbin/execute/tableadmin

Please, change the path according your GCG installation.

Note, that typing 'man crontab' and 'man cron' will give you more information on cronjobs generally.

How to check that it works

A usual way to see how many memory segments are allocated is to use ipcs -ma command. However, because in one memory segment can be up to 4 GCG tables (4 sessions) it is better to ask for more detailed information using, not surprisingly, tableadmin itself:

/gcg/gcgbin/execute/tableadmin -vts

When used with these options, it will not clean-up segments but presents the current tables and its number. Here is a sequence for playing;

type: tableadmin -vts
let's assume you get something like that (shortened)

The Control Segment Id is: 6812
        SegId   Tables Used     Tables Free
        -----   -----------     -----------
         1213        1               3

start W2H session

type again: tableadmin -vts and now we have

The Control Segment Id is: 6812
        SegId   Tables Used     Tables Free
        -----   -----------     -----------
         1213        2               2

You can see that a table was added.

now do a clean-up: tableadmin (no options) and again tableadmin -vts

The Control Segment Id is: 6812
        SegId   Tables Used     Tables Free
        -----   -----------     -----------
         1213        1               3

You are again one table shorter. Making something with W2H session will take now a bit longer.

Peter Ernst

Last modified: Mon Mar 19 16:55:07 2001