Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

class_save_database(3) [osf1 man page]

class_save_database(3)					     Library Functions Manual					    class_save_database(3)

NAME
class_save_database - Write the in-memory database to disk. LIBRARY
Standard C Library (libclass.a) SYNOPSIS
#include <apar_types.h> #include <sys/class.h> class_save_database (class_apar_handle_t handle, dbase_name); PARAMETERS
The partition descriptor returned by class_open(). An optional file name in which the database will be saved. DESCRIPTION
The class scheduler database is memory shared by the administration command, the class scheduler daemon, and runclass(). Administrative changes (such as adding a gid to a class) need to be saved to disk so that the changes are available at the next reboot. Note that class scheduler administrative changes take effect immediately whether they are written to disk or not. If the dbase_name argument is supplied, the database will be written to the specified file name. The current database name will be used by default if dbase_name is null. Note that the calling process must have root access privileges. RETURN VALUES
The operation successfully completed. An invalid partition handle was specified. The dbase_name size limit is exceeded. Error in writing the file, indicated by ERRNO SEE ALSO
Functions:class_add(3), class_init(3), class_create(3), class_close(3), class_change(3), class_configure(3), class_get_config_stats(3), class_delete(3), class_destroy(3), class_disable(3), class_enable(3), class_restore_database(3), class_load_database(3), class_change_name(3), class_database_file_exists(3), class_database_name(3), class_database_modified(3), class_get_classes(3), class_get_class_members(3), Commands:class_admin(8), runclass(1), class_scheduling(4) Other: The System Administration guide. delim off class_save_database(3)

Check Out this Related Man Page

class_scheduling(4)					     Kernel Interfaces Manual					       class_scheduling(4)

NAME
class_scheduling - Allocate CPU resources based on class. DESCRIPTION
The Class Scheduler provides you with a method of controlling the execution of tasks or applications, by restricting the length of time that they can access the processor (CPU). For example, background daemons such as the print spooler can be given less access time. The CPU will then have more time available to perform other tasks. To do this, you specify that the print daemon, /usr/lbin/lpd is allowed to use no more than a certain percentage of the available CPU time. You can group resource user identifiers, such as a user's UID (User Identification), into classes and assign the required CPU access time to each class. This feature can help you to allocate system resources so that the most important work receives the required processing time. For example, you may want to run two versions of a production database on your system. One version is used as part of your business operations, while the other is a test copy, with different tuning parameters. The test database can be assigned to a different class so that your daily operations are not impacted by the testing. Users, groups, process groups, pids, and sessions can be collected into a class that is allotted a percentage of the CPU time. There may be a number of classes on a system. The program class_admin(8) maintains a database of classes, class members, and percentage of CPU time for the class. The database can be modified while the system is running and using class scheduling - changes take effect immediately. Changes made by class_admin(8) may be saved to the disk with one exception: temporary data such as sessions and process groups, that have no meaning on reboot, are kept only in memory. In addition, a program may be forced to run in a specific class via the runclass(1) command with the restriction that the class must have already been created by class_admin(8). The kernel has very little knowledge of class scheduling. Much of the work is done in user space. A class, in the kernel, is an element in an array of integers and a thread that is subject to class scheduling has knowledge of its' index in the array. Each time the thread uses CPU time, the number of clock ticks used is decremented from the array element. When the count reaches zero, the thread is prevented from running. When class scheduling is enabled by class_admin(8), a daemon is started. The daemon wakes up periodically and calculates the total number of clock ticks in the interval (wakeup interval seconds times clock ticks per second times number of CPUs). It then, for each class in the database, divides the total by the percentage allocated to the class and places it into an array. When done, the array is written to the kernel. Should the daemon terminate or fail to run, the system will automatically disable class scheduling. Classes previously scheduled will then run free and unhampered. A process may be represented in the database by more than one class. For instance: a group id representing the group "staff" may be in class "A" and the user id representing the user "guest" may be in class "B". If user "guest" belongs to group "user", should the user then belong to class "A" or to class "B"? The policy is that the class precedence goes from "broadest" to "narrowest". Therefore, in increas- ing precedence the order is: group id, user id, session id, process group id, and process id. In the above example, user "guest" would be placed in class "B". Using Class Scheduling To use the class scheduler, you must first create a database file and populate the file with one or more classes. Each class is assigned a CPU value that controls its access to processing time, expressed as a percentage of the total CPU time availability. One or more applica- tions or groups of applications can be assigned to a class, identified according to a unique system process identifier such as a PID or UID. Note that identifiers that are temporary, such as a PID do not persist across a reboot and cease to exist when a task is completed. is not stored in the database and has no effect when the system or task is restarted. Once the database is established, you can enable class scheduling to start a class scheduling daemon and put the CPU access restrictions into effect. Other commands enable you to review classes, change contents or scheduling parameters and delete components or entire classes. When a class scheduling database is configured and enabled, you can: Execute a task (process) according to the CPU access value set for a specific class using runclass. For example, you might set a value for interactive operations that is much higher than background processes such as print daemons. To temporarily use the higher value for a print job, you can execute the lpr command in the same class as interac- tive operations. Execute class scheduling commands from within scripts using the command line version of class_admin. Execute class scheduling commands from within programs, using the classcntl function. The general process for setting up and using class scheduling is as follows: Decide how you want to allocate the CPU resources. Use class_admin to set up and maintain the class database: Create classes and add members to the classes. Verify class entries using the show command Save the entries to the /etc/class database Enable class scheduling, to start the daemon Use the stat command to check CPU usage Execute class_admin commands from the command line or a shell script without running an interactive session Use the runclass command to execute a task according to the priorities set for a particular class Use the classcntl function from within a program. Note that it is not be necessary to perform tasks in this specific sequence. You can simply execute a series class_admin command from the command line to configure a default database, add classes and class members, and enable the class scheduling daemon. The following sec- tions suggest a systematic approach to using class scheduling, although you can use it equally well to create a quick fix to a CPU resource sharing problem. Planning Class Scheduling. How you allocate CPU resources will depend on your system environment and what resources and priorities must be considered. A typical sce- nario is to assign a higher priority to interactive tasks so that users do not encounter long response times. Most batch or background processes will be assigned a lower priority, while some specific background processes may require a higher priority. For example, if a nightly back up is being performed, you might not want it to have such a low priority that it does not complete in a reasonable time. An alternative scenario is if there are critical realtime tasks that should take priority over interactive processes. For example, in process control applications. For this scenario, you should design a baseline, assigning processes to classes and then monitor tasks and user feedback to tune the database by moving tasks from class to class or changing the CPU access time of the classes. Configuring Class Scheduler The class_admin utility provides: An interactive command with sub-commands that enable you to create and administer a database of classes. The database is stored in the file /etc/class, which cannot be edited manually. A command mode that allows you to execute class_admin commands at the command prompt, or include commands in shell scripts. A database must be configured before you can enable class scheduling with the enable command. If a database does not exist when you enter the class_admin command, the command will invoke an interactive session and prompt you to configure a database. If the class_admin com- mand is invoked by a script, a database is configured automatically using the system defaults. The following example shows an interactive configuration session: # class_admin Class Scheduler Administration configure: Shall processes that have not been explicitly assigned to a defined class be assigned to a 'default' class? Enter (y/n) [n]: y Enforce class scheduling when the CPU is otherwise idle? (y/n) [n]: y How often do you want the system to reset class usage? Enter number of seconds (2): 5 class> The configuration values have the following effect: To be scheduled, a process must be assigned to a class. If you answer y to the first prompt, a special class called the "default" class is created. Any process that has not been explicitly assigned to a defined classes will be assigned to the default class. If you answer n to this prompt, then only those processes which are explicitly assigned to a defined class will be class scheduled. If you answer y to the second prompt, you allow classes to exceed their allotted CPU time percentage when the system is otherwise idle. If you answer no, classes are restricted to their allotted percentage even if the CPU has no other work. The third prompt allows you to set the standard reset time for all classes. For example, if you choose the short default time of 2 seconds, each class will have more frequent, but shorter opportunities to access the CPU. Use a small number (several seconds) if there are interactive jobs subject to class scheduling to give them a quick response time. If only batch jobs are class scheduled, response time is not an issue and larger values may be used. In the example, a default class was created and all current processes were assigned to that class. Class scheduling will be enforced even when the CPU is idle and class usage will be reset every five seconds. To review the current configuration, use the following command: class> show This command will produce output similar to the following: Con- figuration: -Processes not explicitly defined in the database are class scheduled. -If the processor has some idle time, class scheduled processes are not allowed to exceed their cpu percentage. -The class scheduler will check class CPU usage every 5 seconds. Class scheduler status: disabled (For information on all class_admin command options, see the class_admin(8) reference page.) The next step in the process is to create classes and populate the classes with system processes such as tasks, daemons, or user accounts. Creating and Managing Classes When the database has been configured, you can manage classes as follows: Create a class add processes to the class delete processes from a class Change the CPU access value (time percentage) of any class Destroy an entire class, whether empty or populated Show details of class members and configuration settings View statistics of actual CPU use against current priority settings Creating a Class To create a class, either use the command mode or enter an interactive session as follows: # class_admin class> create high_users 50 The command mode version is entered as follows: # class_admin create batch_jobs 10 batch_jobs created at 10% cpu usage changes saved The first command creates a class named high_users and assigns a CPU usage restriction of 50%. The second command creates a class named batch_jobs and assigns a CPU usage restriction of 10%. Note that in command mode the changes are automatically saved to the database in /etc/class. When making changes to classes interactively, you use the command save to commit changes to the database. If you attempt to end the ses- sion with the quit command and there are unsaved changes, you will be prompted to save or discard the changes before quitting the interac- tive session as follows: class> quit Class scheduler database modified. Save changes? (y/n) [y]: y changes saved Managing Processes within a Class Once you have created classes, you can add processes or sets of process to one or more classes using the add command. You must specify the type of identifier (id) used and enter one or more unique identifiers. Identifiers can be obtained from system files or by using a command such as the ps 1 command. For example: # ps aj Types allowed are: gid A group identification number from the /etc/group file. This number will add all resource users that are assigned that number. uid A user identification number from the /etc/passwd file. This number will add only the specific resource user to which the UID is assigned. pgrp A process group identifier, In the output from the ps command, see the entries under the PGID table heading session The session identifier, obtained by using the ps command. In the output from this command, see the entries under the SESS table heading. pid The process identifier, obtained by using the ps In the output from this command, see the entries under the PID table heading. It is most likely that you will use types uid and gid in your established classes, as these values will persist across a reboot or when class scheduling is stopped and restarted. The identifiers associated with types pgrp, session, and pid are temporary, and will not exist on reboot, or when a process terminates. You may want to use these types with the command runclass, or for temporarily adding certain pro- cesses to a class by the use of a script. The following command shows a sample of the system output that enables you to find the identifier for a running task or process: # ps -aj USER PID PPID PGID SESS JOBC S TTY TIME COMMAND root 536 1 536 536 0 I + console 0:00.21 /usr/sbin/g dem 24884 24874 24884 24884 0 I + ttyp1 0:00.30 -csh (csh) root 7720 24371 7720 24371 1 R + ttyp2 0:00.03 ps aj walt 24371 24455 24371 24371 0 S ttyp2 0:00.98 -csh (csh) corc 24880 24903 24880 24903 1 R + ttyp3 0:37.57 sh /home/bi corc 24903 24894 24903 24903 0 I ttyp3 0:00.26 -csh (csh) Adding Members to a Class To add a process to a class, you use the add command as shown in the following interactive mode example: class> add batch_jobs uid 234 457 235 Note that you must use one of the unique identifiers previously specified and you cannot add the same identifier to a class more than once. The same procedure can be performed in command mode or from a script as follows: # add batch_jobs uid 234 457 235 uid 234 457 235 added to high_users. In command mode, additions to a class are automatically saved to the /etc/class database. Deleting Processes From a Class To delete one or more processes from a class, use the delete command in interactive or command mode. For example: class> delete high_users uid 11" uid 11 deleted from high_users Other Class Management Options Consult the class_admin(8) reference page for information on the following options: Change the priority of a class. For example: class> change batch_jobs 20 batch_jobs retargeted at 20%. Destroy an entire class, whether empty or full. For example: class> destroy high_users high_users is not empty. to destroy anyway? [y/n]: y high_users destroyed View statistics of actual CPU use against cur- rent priority settings. For example: class> stats Class scheduler status: enabled class name target percentage actual percentage high_users 50% 40.0% batch_jobs 10% 2.0% Using the runclass Command Once you have established scheduler classes and enabled class-scheduling, you can use the runclass(1) command to execute a command in a particular class. You must have root privileges to use this command if you want a higher CPU percentage than is currently assigned to you. The following command uses the runclass command to open a terminal window and assign it to the previously-created high_users class: # runclass high_users xterm The following command shows that the pgrp number for the terminal process is now identified as a member of that class: # class_admin show . . . class members: pgrp 24330 pgrp 24351 pgrp 24373 In this example, the identifier for the xterm process has been added to the class. You can use the following command to view the running process: # ps agx | grep xterm FILES
/etc/class, /usr/include/sys/class.h RELATED INFORMATION
Commands: runclass(1), classcntl(2), class_admin(8). delim off class_scheduling(4)
Man Page