System Tuning

The initial performance of a server is based on a number of parameters set by the supplier of the operating system. In the case of SLES, these parameters are chosen to satisfy a broad range of server types. Each service can require different resources. Some services are memory or bandwidth intensive, whereas others are CPU intensive. These various factors are balanced by default to provide a responsive server regardless of its initial tasking.

What cannot be anticipated, however, are the resources available from the hardware supplied. SUSE specifies a number of minimum requirements to provide a stable environment. In most cases, meeting these minimum requirements is not an issue. As resource limits start contributing to performance issues, memory or disk space can be added to a server.

In some situations, however, the tasking of a server is outside the designed norm. In these cases, you must entertain changes to the fundamental assumptions in the original configuration.

In Linux- and Unix-based systems, the core program of the operating system is called the kernel. The kernel is built just like any other program. It incorporates within its structure the original assumptions of the configuration team. These assumptions govern which device types are available such as IDE or SCSI disks, how memory will be managed, and if additional modules can be loaded dynamically. Adding and removing capabilities within the configuration of the kernel can increase flexibility and performance.

When such situations arise, you often need to alter the actual Linux kernel itself. This can be done in a couple of different ways. One option is to recompile the kernel to include additional functionality. The preferred method, when available, is to take advantage of the flexibility of the default kernel and simply tune some of its runtime parameters.

Tuning Kernel Parameters

A number of applications have been ported to Linux. Some of them, such as database applications, have resource requirements that are significantly different from those of typical Linux services. To satisfy these needs, you must make changes to the way the kernel operates by tuning application-specific parameters.

In older versions of Unix, these changes required a rebuild of the kernel itself. Though not an insurmountable feat, rebuilding the kernel is certainly a daunting task for someone who has never done it. Luckily, the Linux kernel is flexible and dynamic. Changes to the Linux kernel can be made in real-time without requiring a reboot.

As an example, let's look at the changes required to the Linux kernel for it to be able to run Oracle 10g. These changes are supplied in a script run at install time; for argument's sake, say you want to make these changes manually. The Oracle 10g requirements are shown in Table 7.3.

Table 7.3. Oracle 10g SUSE LINUX Kernel Requirements

KERNEL PARAMETER	MINIMUM VALUE REQUIRED (UNITS DEPEND ON PARAMETER)	DESCRIPTION
kernel.shmall	2097152	Available memory for shared memory in 4KB blocks
kernel.shmmax	2147483648	Maximum size of a shared memory segment
kernel.shmmni	4096	Maximum number of shared segments
kernel.sem	250 32000 100 128	Semaphores
fs.file-max	65536	Maximum number of file handles allocated by the kernel
net.ipv4.ip_	1024 65000	Required available ports local_port_range

NOTE

Tuning the kernel is a task that should only be undertaken with great care. Changes made could generate an environment that is unable to function. There are a number of sites on the Internet that discuss the Linux kernel and its parameters. Visit one of these for more information:

http://www.suse.de/~agruen/kernel-doc/

http://www.kernelnewbies.org/

http://www.bb-zone.com/SLGFG/chapter4.html

You can use the sysctl command to query the values currently in use by the running kernel. Specifying the -a switch lists all the parameters. Each individual parameter can be checked using syntax similar to the following:

 Athena:~ # sysctl kernel.shmmax kernel.shmmax = 33554432 

As you can see, this parameter value is well below the minimum required for Oracle. To set the value, use the following syntax:

 Athena:~ # sysctl -w kernel.shmmax=2147483648 kernel.shmmax = 2147483648 

This syntax sets the new value for the kernel parameter and acknowledges the new value.

Most typical installations of SLES come with well-configured kernel parameters. It is not necessary to change these values unless the server in question is running an atypical configuration. In most cases, like Oracle, you will be given the necessary minimum values and most probably a script to make the changes. If not, following the procedure shown here, you can check for compliance to the minimum recommended values as well as set the parameters as recommended.

Tuning Filesystem Access

Previously, we discussed how the Linux filesystem is considered one large logical tree. Table 7.2 identifies the directories created under the root in a standard installation. Sometimes, however, the default install does not satisfy your needs.

In Chapter 2, we presented an overview on how to migrate two of the standard directories in the root to a different disk resource. This process is typically performed when the disk consumption in those branches is expected to impact the overall system. When these directories are part of the same physical partition as the root, should they fill all available space, the system would become unresponsive. The process of adjusting the availability of different directories is known as tuning the filesystem.

When the disk makeup of a production server is designed, directories with dynamic content such as /usr, /home, and /var are often placed on separate physical disk partitions. When possible, they are also placed on different physical devices to distribute I/O operations. Though modern disk subsystems are very fast, extracting every bit of performance possible is a good practice. One added benefit to placing them on separate physical devices is that in the event of a disk subsystem failure, fewer partitions may need to be restored.

An additional aspect to filesystem tuning is that of granting access to portions of the directory tree. The initial owner and the group membership of a mount point are root. The rights mask allows for nonroot users to access the contents of directories under the mount point. This is a necessary condition when a mount point contains portions of the standard tree.

Previously, we constrained ourselves to the default directory structure in the root of the filesystem. Because this is just a simple directory, there are no set limitations on the creation of additional directories or mount points in the root. Additionally, there are no limitations that state all mount points must be in the root. It is an important system management practice to keep the root as clean a possible, but that doesn't mean it must be pristine. The following two examples explore methods for adding additional storage to a server and limiting access to the new resource.

If a group of research users are working on a collaborative project, they may need to be segregated onto separate storage for the server to reduce their impact on other users. As part of the process, they should have their home directories placed there. Also, due to the nature of the research, only members of the group may have access to the mount point.

This result can be accomplished by specifying a new mount point in the root /research. A number of filesystems permit restricting access to the mounted partition to specific UID and GID. Mount does not support these features for ext3 or Reiser partitions. Access to specific individuals or groups therefore must be restricted a different way. The following steps can serve as a guide to creating a directory structure specific to the research group:

1.	Create a group called research for the project.
2.	Prepare the new partition using fdisk and mkfs.
3.	Create a standard directory named /research for mounting the new resource.
4.	Modify /etc/fstab to allow the partition to be mounted at boot time.
5.	Execute a mount -a command to verify that the partition is mounted correctly.
6.	Change the group membership of the mount point directory using chgrp research /research.
7.	Change the access permissions on the mount point directory using chmod 6770 /research.
8.	Create containers for the home directories of the users and one for the project data using mkdir /research/home and mkdir /research/project.
9.	Adjust the permissions on these directories using chmod 6770 /research/home and chmod 6770 /research/project.

NOTE

In the preceding set of steps, the ownership of the root directory is left as root. This might seem counter-intuitive because you would probably like it to belong to a member of the group.

Making a group member the owner of the directory generates another issue. If the selected individual leaves, his or her account will be deleted and the UID orphaned. Any new account accidentally given the same UID would automatically be granted access.

You could create a placeholder account, set it so that it is not allowed to log on, and make it a member of the group. Since this service account is never used and unable to log in, the UID associated would remain in service. If, however, the account is changed, maliciously or not, access to the information would be granted without any way of tracking the access.

It is best in this case to leave the ownership as root. Individuals will have access to the directory structure through the group permissions.

At this stage, you can relocate existing users to the new location for their home directories by updating their account information and moving the contents of their directories. Existing users will also have to be added to the group research. New users can be created directly into the new structure and added to the research group. The resulting directories will look like the following:

 Athena:~ # ls -ld /research drwsrws---  4 root research 4096 Feb 27 06:55 /research Athena:~ # ls -l /research total 25 drwsrws---   4 root research  4096 Feb 27 06:55 . drwxr-xr-x  24 root root       568 Feb 27  2005 .. drwsrws---   4 root research  4096 Feb 27 06:59 home drwx------   2 root root     16384 Feb 27 06:14 lost+found Athena:~ # ls -l /research/home total 16 drwsrws---   4 root research 4096 Feb 27 06:59 . drwsrws---   4 root research 4096 Feb 27 06:55 .. drwsrws---   7 mark research 4096 Feb 27 07:05 mark drwxr-sr-x  12 pol  research 4096 Feb 27 07:06 pol Athena:~ # 

The protection on these directories allows for full access to root and members of the group research. At the same time, all other users of the system are denied access. It is imperative to adjust the backup utility to permit access to the contents of the structure.

NOTE

The man page for mount goes into more detail about the various options available for the various filesystem types. A number of filesystem types allow for the ownership of a mounted volume to be specified by UID/GID. This certainly makes things easier for restricting access. In some cases, however, the ownership of all files is forced to the same user or group as that specified in the mount options. In addition, the robustness of Reiserfs and ext3 are lost. We certainly encourage choosing the more robust filesystem.

Another typical request is for a large dataset to be made available to everyone on the system. The catch is that the dataset must be available in a read-only format. You can accomplish this by creating a mount point off the rootfor example, /gisdataand specifying that the partition in question be mounted using the ro option in fstab. It would look something like this:

 /dev/sdc1 /gisdata ext3 ro 1 2 

The resulting directory will be available to all users for read access. If additional information needs to be added to the structure, the partition can be dismounted, remounted on a different mount point with write privileges, and updated. mount can also use the user option to specify an individual who is allowed to mount/umount the mount point. Combined with the sudo granting of mount/umount, the maintenance of the dataset could be delegated to an individual within the user group responsible for the data.

This section examined the splitting of the typical root directory structure across multiple disk partitions. This is often done to segregate dynamic directory structures from the more static ones. Multiple devices also allow for distributing I/O operations, resulting in improved performance. The other aspect of filesystem management is restricting access to certain areas of the directory. This restriction can be applied across the board or to a specific group. The flexibility this capability offers allows you, the system administrator, more granularity in delivering storage to your customers.