1. Installing GemStone/S 64 Bit Version 3.5

1. File size and file descriptors

To use extents in the file system larger than 2 GB or to increase the number of file descriptors available, make these changes in /etc/security/limits:

Fsize = -1

nofiles = 2000

You must also have the Large File System enabled when creating a jfs file system using SMIT.

We recommend that you pregrow such extents to a size greater than 2 GB so any configuration difficulty is detected when the server is first started.

The default file descriptor limit of 1024 is adequate for up to about 500 GemStone users. Each user session requires two file descriptors, and others are needed for extents, transaction logs, and overhead. Use caution and increase the default setting only when necessary because doing so can have system side effects.

2. PAM

If you are using UNIX authentication for GemStone logins, or if you run NetLDI as root with setuid (i.e. not in guest mode), you must have PAM (Pluggable Authentication Module) configured on the server. You may include a specific GemStone authorization service name, or allow the default “other” authentication definitions to be used.

PAM authentication definitions are in /etc/pam.conf.

The specific GemStone service names are gemstone.gem for user authentication, and gemstone.netldi for a NetLDI running with authentication. The libraries that are specified in the stack depend on how you are configuring PAM to perform the authentication. AIX does not provide an LDAP module as part of the core.

For example, to allow GemStone UNIX authentication, which uses PAM, to authenticate via a custom LDAP module:

gemstone.gem   	auth   	required   	/usr/lib/security/pam_ldap

For NetLDI running as root, to authenticate directly to the AIX security subsystem, use the following. This only applies for process running as root.

gemstone.netldi  auth   required   /usr/lib/security/pam_aix

If the following “other” stack is available in /etc/pam.conf, GemStone can use this to authenticate, via a custom LDAP module:

OTHER   auth    required        /usr/lib/security/pam_ldap

Consult your System Administrators for more information on how authentication is handled on your system.

3. Large Memory Pages

The default size for memory pages is 4K (small), and AIX also transparently supports 64K (medium) pages; AIX automatically adjusts between these two page sizes.

Current releases of AIX also support larger pages sizes, including 16MB (large) pages. If you have a large repository, using large pages may improve performance. To use large pages, you must configure AIX to allocate large pages, and configure GemStone to request large pages.

To configure GemStone to use Large Pages:

a. Determine the number of huge pages that will be needed, based on your GemStone configuration. This is calculated by the utility largememorypages. This utility needs several details to compute the number of required pages: the shared page cache size, the maximum number of GemStone processes, and the number of shared counters. These can be provided by arguments or read from an existing configuration file.

largememorypages [-e path ][-z path][-F cacheFrames | -M cacheKB]

  [ -P maxProcesses] [-C maxSharedCounters]

You may specify the required values using a valid configuration file. This is parsed as a Stone configuration file and the necessary values extracted.

-e path
specifies an executable config file (same as startstone -e).

-z path
specifies a system config file (same as startstone -z).

If a config file is not specified, then -M or -F and -P and -C are required. These arguments can be used in addition to the configuration file, in which case they override values set or computed in the configuration file:

-F cacheFrames
shared cache size expressed in 16 KB frames

-M cacheKB
shared cache size in bytes, with a optional units suffix.

-P maxProcesses
setting for SHR_PAGE_CACHE_NUM_PROCS

-C maxSharedCounters
setting for SHR_PAGE_CACHE_NUM_SHARED_COUNTERS.

The following example is for an (approximately) 20GB shared page cache, 200 processes, and 1900 shared counters, with 2 MB memory pages:

unix> largememorypages -P 200 -M 20GB -C 1900 

Cache config is 1310720 pages = 20480 MB,  total is 22064 MB,  overhead 7% of configured size

Large page size requested is: 16 MB.

Large page overhead: 4.80 MB

For 1310720 pages, 200 processes and 1900 shared counters, 10 pusherThreads

  required cache size is 23135780864 bytes.

Number of 16 MB large pages required: 1379

<with further update commands>

b. Configure AIX to use large pages using the following commands, which are also output by largememorypages.

unix> vmo -r -o lgpg_regions=numPages -o lgpg_size=16777216

unix> vmo -p -o v_pinshm=1

After this has been executed, the bosboot command must be run to build a new kernel image, and the system must be rebooted

You can confirm large memory pages are available for use using vmstat -l.

c. The UNIX user running the shared cache monitor must be given permission to use large memory pages.

chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE <user id>

Alternatively, you can run the SPC monitor process with an effective user ID of root:

chown root $GEMSTONE/sys/shrpcmonitor $GEMSTONE/sys/startshrpcmon

chmod u+s $GEMSTONE/sys/shrpcmonitor $GEMSTONE/sys/startshrpcmon

d. Configure GemStone to request large pages by setting the configuration option SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_POLICY = 2.

4. Configuring GemStone’s Shared Page Cache

The configuration option SHR_PAGE_CACHE_SIZE_KB defines the size (in KBytes) of extent page space in the shared page cache. The maximum acceptable value for this configuration option is limited by system memory, kernel configurations, cache space allocated by SHR_PAGE_CACHE_NUM_PROCS and space allocated for other GemStone caches.

For more general information about these and other configuration options, see Appendix A of the System Administration Guide.

5. System clock

The system clock must be set to the correct time. When GemStone opens the repository at startup, it compares the current system time with the recorded checkpoint times as part of a consistency check. A system time earlier than the time at which the last checkpoint was written may be taken as an indication of corrupted data and prevent GemStone from starting. The time comparisons use GMT.

6. TCP keepalive option

GemStone processes ordinarily use the TCP keepalive option to determine how long they will wait after communications activity ceases unexpectedly. This setting can be useful for reaping stale RPC Gems, but the operating system default may not be appropriate for this purpose. For further information, refer to your operating system documentation.

Licensed Customer key file

Licenced customers can email keyfiles@gemtalksystems.com or contact GemTalk Technical Support to request a keyfile for version 3.5 for their platform or platforms. Keyfiles for previous versions of GemStone are not valid with v3.5.

Installing a keyfile

To specify the location and name of the keyfile using the KEYFILE configuration parameter, edit the configuration file that will be used by the v3.5 stone to include the location and name of the keyfile.

You may also put the keyfile in the default location, $GEMSTONE/sys/gemstone.key. This requires modifying the write permissions of the $GEMSTONE/sys directory; ensure you change this back to not writable, after this update.

Do you want the installation script to set up directories for server lock files and NetLDI logs?

The default location for server lock files and NetLDI log files is /opt/gemstone, although for compatibility with earlier products /usr/gemstone is used only if it exists. If the environment variable GEMSTONE_GLOBAL_DIR is defined to point to a valid directory, this overrides the default server lock files and log file location; however, all Gemstone processes that will interact on this machine must have this environment variable set to the same directory.

If these directories do not exist, the installation script offers to create /opt/gemstone and the subdirectories locks and log. Then, the script offers to set access (770) to these directories.

If you answer no to creating the directories, you must create them (or provide a symbolic link) before starting the server.

Do you want the installation script to set the owner and group for all the files in the GemStone distribution?

If you answer yes, the script will prompt you for the owner and group you want to use. Refer to Chapter 1 of the System Administration Guide for more information about setting owner and group permissions.

If you answer no, the permissions will remain the same as when the files were extracted from the distribution media.

Do you want the installation script to protect the repository file?

The default, which we recommend, gives only the owner read and write access (600) through ordinary UNIX commands. Other users can read and write the repository through a GemStone session. If you choose not to protect the repository, the setuid bit is cleared from all executables, which causes them to run under ownership of the user who invokes them.

Default: Set the repository permission to 600, and leave the setuid bit applied.

Allow NetLDI to Run as Root?

Do you want the installation script to allow non-root users to start a NetLDI that runs as root?

The NetLDI is a network server that permits remote processes to interact with the repository. There are two ways to set up a NetLDI so that it can provide services to all GemStone users: it can run as root, or it can run in guest mode with a captive account.

• To run NetLDIs as root, accept the default “yes” response. Ownership of the NetLDI executable is changed to root, and the setuid bit is set. Any GemStone user will be able to start a NetLDI process that is accessible to all GemStone users because it will always run as root. For certain services, users will need to authenticate themselves by supplying a password. Alternatively, answer “no” but log in as root before starting the NetLDI.

If the NetLDI uses a port number less than 1024, it must run as root.

• To run NetLDIs in guest mode with a captive account, answer “no” to the prompt, because those modes are not permitted if the NetLDI runs as root. “Guest mode” means that GemStone users do not have to supply a UNIX password to use NetLDI services. The “captive account” is an account that owns all processes the NetLDI starts; typically, it is the GemStone administrative account that owns the files. You must start the NetLDI while logged in as that account.

Default: Change ownership of the netldi executable to root, and set its setuid bit.

Set up an Extent?

Do you want the installation script to set up an extent now?

GemStone is distributed with a read-only copy of the initial repository in
$GEMSTONE/bin/extent0.dbf. Before you can start GemStone, this file must be copied to a suitable location and made writable. The script offers to copy the file to its default location of $GEMSTONE/data.

If you are a new GemStone user, we recommend that you answer y. If you are an existing GemStone user, you might prefer to answer n, then copy the extent to a different location yourself. (If you choose a location other than the default, you must edit your configuration file before starting GemStone. For information, see the System Administration Guide.)

Default: Place a writable copy of extent0.dbf in $GEMSTONE/data.

Start a NetLDI?

Do you want the installation script to start a NetLDI?

If you prefer, you can start these processes manually at any time.

Almost every host needs a NetLDI. You must start a NetLDI when the Stone repository monitor or Gem session processes will run on this machine.

You can start a NetLDI that runs as root by answering yes to this prompt and the confirmation that follows. However, if you want to start the NetLDI in guest mode with a captive account, you must do that after completing the installation. For more information about guest mode with captive account, see Chapter 3 of the System Administration Guide.

Default: Do not start a NetLDI at this time.

Start an Object Server?

As root, you cannot start an object server, but the script offers to start one as another user. You will start the server later in the installation, so answer no.

Default: Do not start an object server at this time.