Christopher Negus

Linux Bible


Скачать книгу

      You can use the nice command to run a command with a particular nice value. When a process is running, you can change the nice value using the renice command, along with the process ID of the process, as in the example that follows:

       # nice -n +5 updatedb &

      The updatedb command is used to generate the locate database manually by gathering names of files throughout the filesystem. In this case, I just wanted updatedb to run in the background (&) and not interrupt work being done by other processes on the system. I ran the top command to make sure that the nice value was set properly:

       PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20284 root 25 5 98.7m 932 644 D 2.7 0.0 0:00.96 updatedb

      Notice that under the NI column, the nice value is set to 5. Because the command was run as the root user, the root user can lower the nice value later by using the renice command. (Remember that a regular user can't reduce the nice value or ever set it to a negative number.) Here's how you would change the nice value for the updatedb command just run to –5:

       # renice -n -5 20284

      You can use a feature like “nice” to give a single process more or less access to CPU time. Setting the nice value for one process, however, doesn't apply to child processes that a process might start up or any other related processes that are part of a larger service. In other words, “nice” doesn't limit the total amount of resources a particular user or application can consume from a Linux system.

      As cloud computing takes hold, many Linux systems will be used more as hypervisors than as general-purpose computers. Their memory, processing power, and access to storage will become commodities to be shared by many users. In that model, more needs to be done to control the amount of system resources to which a particular user, application, container, or virtual machine running on a Linux system has access.

      That's where cgroups come in.

      Cgroups can be used to identify a process as a task, belonging to a particular control group. Tasks can be set up in a hierarchy where, for example, there may be a task called daemons that sets default limitations for all daemon server processes, then subtasks that may set specific limits on a web server daemon (httpd) for FTP service daemon (vsftpd).

      As a task launches a process, other processes that the initial process launches (called child processes) inherit the limitations set for the parent process. Those limitations might say that all the processes in a control group only have access to particular processors and certain sets of RAM. Or they may only allow access to up to 30 percent of the total processing power of a machine.

      The types of resources that can be limited by cgroups include the following:

       Storage (blkio): Limits total input and output access to storage devices (such as hard disks, USB drives, and so on).

       Processor scheduling (cpu): Assigns the amount of access a cgroup has to be scheduled for processing power.

       Process accounting (cpuacct): Reports on CPU usage. This information can be leveraged to charge clients for the amount of processing power they use.

       CPU assignment (cpuset): On systems with multiple CPU cores, assigns a task to a particular set of processors and associated memory.

       Device access (devices): Allows tasks in a cgroup to open or create (mknod) selected device types.

       Suspend/resume (freezer): Suspends and resumes cgroup tasks.

       Memory usage (memory): Limits memory usage by task. It also creates reports on memory resources used.

       Network bandwidth (net_cls): Limits network access to selected cgroup tasks. This is done by tagging network packets to identify the cgroup task that originated the packet and having the Linux traffic controller monitor and restrict packets coming from each cgroup.

       Network traffic (net_prio): Sets priorities of network traffic coming from selected cgroups and lets administrators change these priorities on the fly.

       Name spaces (ns): Separates cgroups into namespaces, so processes in one cgroup can only see the namespaces associated with the cgroup. Namespaces can include separate process tables, mount tables, and network interfaces.

      At its most basic level, creating and managing cgroups is generally not a job for new Linux system administrators. It can involve editing configuration files to create your own cgroups (/etc/cgconfig.conf) or set up limits for particular users or groups (/etc/cgrules.conf). Or you can use the cgcreate command to create cgroups, which results in those groups being added to the /sys/fs/cgroup hierarchy. Setting up cgroups can be tricky and, if done improperly, can make your system unbootable.

      The reason I bring up the concept of cgroups here is to help you understand some of the underlying features in Linux that can be used to limit and monitor resource usage. In the future, you will probably run into these features from controllers that manage your cloud infrastructure. You will be able to set rules like “Allow the Marketing department's virtual machines to consume up to 40 percent of the available memory” or “Pin the database application to a particular CPU and memory set.”

      Knowing how Linux can limit and contain the resource usage by the set of processes assigned to a task will ultimately help you manage your computing resources better. If you are interested in learning more about cgroups, you can refer to the following:

       Red Hat Enterprise Linux Resource Management and Linux Containers Guide:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/resource:management_guide/index

       Kernel documentation on cgroups: Refer to files in the /usr/share/doc/kernel-doc-*/Documentation/cgroups directory after installing the kernel-doc package.

      Even on a Linux system where there isn't much activity, typically dozens or even hundreds of processes are running in the background. Using the tools described in this chapter, you can view and manage the processes running on your system.

      In the next chapter, you learn how to combine commands and programming functions into files that can be run as shell scripts.

      Use these exercises to test your knowledge of viewing running processes and then changing them later by killing them or changing processor priority (nice value). These tasks assume that you are running a Fedora or Red Hat Enterprise Linux system (although some tasks work on other Linux systems as well). If you are stuck, solutions to the tasks are shown in Appendix B (although in Linux, you can often use multiple ways to complete a task).

      1 List all processes running on your system, showing a full set of columns. Pipe that output to the less command so that you can page through the list of processes.

      2 List all processes