mtpti5iD/redhat-docs_dataset huggingface dataset:
2.5.3. vmstat For a more concise understanding of system performance, try vmstat . With vmstat , it is possible to get an overview of process, memory, swap, I/O, system, and CPU activity in one line of numbers: The first line divides the fields in six categories, including process, memory, swap, I/O, system, and CPU related statistics. The second line further identifies the contents of each field, making it easy to quickly scan data for specific statistics. The process-related fields are: r -- The number of runnable processes waiting for access to the CPU b -- The number of processes in an uninterruptible sleep state The memory-related fields are: swpd -- The amount of virtual memory used free -- The amount of free memory buff -- The amount of memory used for buffers cache -- The amount of memory used as page cache The swap-related fields are: si -- The amount of memory swapped in from disk so -- The amount of memory swapped out to disk The I/O-related fields are: bi -- Blocks sent to a block device bo -- Blocks received from a block device The system-related fields are: in -- The number of interrupts per second cs -- The number of context switches per second The CPU-related fields are: us -- The percentage of the time the CPU ran user-level code sy -- The percentage of the time the CPU ran system-level code id -- The percentage of the time the CPU was idle wa -- I/O wait When vmstat is run without any options, only one line is displayed. This line contains averages, calculated from the time the system was last booted. However, most system administrators do not rely on the data in this line, as the time over which it was collected varies. Instead, most administrators take advantage of vmstat 's ability to repetitively display resource utilization data at set intervals. For example, the command vmstat 1 displays one new line of utilization data every second, while the command vmstat 1 10 displays one new line per second, but only for the ten seconds. In the hands of an experienced administrator, vmstat can be used to quickly determine resource utilization and performance issues. But to gain more insight into those issues, a different kind of tool is required -- a tool capable of more in-depth data collection and analysis.

Commands:
procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 5276 315000 130744 380184 1 1 2 24 14 50 1 1 47 0
Chapter 15. Red Hat build of Kogito microservice deployment troubleshooting Use the information in this section to troubleshoot issues that you might encounter when using the operator to deploy Red Hat build of Kogito microservices. The following information is updated as new issues and workarounds are discovered. No builds are running If you do not see any builds running nor any resources created in the relevant namespace, enter the following commands to retrieve running pods and to view the operator log for the pod: View RHPAM Kogito Operator log for a specified pod Verify KogitoRuntime status If you create, for example, KogitoRuntime application with a non-existing image using the following YAML definition: Example YAML definition for a KogitoRuntime application apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoRuntime # Application type metadata: name: example # Application name spec: image: 'not-existing-image:latest' replicas: 1 You can verify the status of the KogitoRuntime application using the oc describe KogitoRuntime example command in the bash console. When you run the oc describe KogitoRuntime example command in the bash console, you receive the following output: Example KogitoRuntime status At the end of the output, you can see the KogitoRuntime status with a relevant message.

Commands:
// Retrieves running pods oc get pods NAME READY STATUS RESTARTS AGE kogito-operator-6d7b6d4466-9ng8t 1/1 Running 0 26m // Opens RHPAM Kogito Operator log for the pod oc logs -f kogito-operator-6d7b6d4466-9ng8t
apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoRuntime # Application type metadata: name: example # Application name spec: image: 'not-existing-image:latest' replicas: 1
[user@localhost ~]USD oc describe KogitoRuntime example Name: example Namespace: username-test Labels: <none> Annotations: <none> API Version: rhpam.kiegroup.org/v1 Kind: KogitoRuntime Metadata: Creation Timestamp: 2021-05-20T07:19:41Z Generation: 1 Managed Fields: API Version: rhpam.kiegroup.org/v1 Fields Type: FieldsV1 fieldsV1: f:spec: .: f:image: f:replicas: Manager: Mozilla Operation: Update Time: 2021-05-20T07:19:41Z API Version: rhpam.kiegroup.org/v1 Fields Type: FieldsV1 fieldsV1: f:spec: f:monitoring: f:probes: .: f:livenessProbe: f:readinessProbe: f:resources: f:runtime: f:status: .: f:cloudEvents: f:conditions: Manager: main Operation: Update Time: 2021-05-20T07:19:45Z Resource Version: 272185 Self Link: /apis/rhpam.kiegroup.org/v1/namespaces/ksuta-test/kogitoruntimes/example UID: edbe0bf1-554e-4523-9421-d074070df982 Spec: Image: not-existing-image:latest Replicas: 1 Status: Cloud Events: Conditions: Last Transition Time: 2021-05-20T07:19:44Z Message: Reason: NoPodAvailable Status: False Type: Deployed Last Transition Time: 2021-05-20T07:19:44Z Message: Reason: RequestedReplicasNotEqualToAvailableReplicas Status: True Type: Provisioning Last Transition Time: 2021-05-20T07:19:45Z Message: you may not have access to the container image "quay.io/kiegroup/not-existing-image:latest" Reason: ImageStreamNotReadyReason Status: True Type: Failed
Chapter 10. Managing custom software repositories You can configure a repository in the /etc/yum.conf file. or in a .repo file in the /etc/yum.repos.d/ directory. Note It is recommended to define your repositories in the new or existing .repo file in /etc/yum.repos.d/ because all files with the .repo file extension are read by YUM . The /etc/yum.conf file contains the [main] sections and can contain one or more repository sections ( [ <repository_ID> ] ) that you can use to set repository-specific options. The values you define in individual repository sections of the /etc/yum.conf file override values set in the [main] section. 10.1. YUM repository options The /etc/yum.conf configuration file contains the repository sections with a repository ID in brackets ( [ <repository_ID> ] ). You can use these sections to define individual YUM repositories. Important Repository IDs must be unique. For a complete list of available repository ID options, see the [ <repository_ID> ] OPTIONS section of the dnf.conf(5) man page on your system. 10.2. Adding a YUM repository You can add a YUM repository to your system by defining it in the .repo file in the /etc/yum.repos.d/ directory. Procedure Add a repository to your system: Note that repositories added by this command are enabled by default. Review and, optionally, update the repository settings that the command has created in the /etc/yum.repos.d/ <repository_URL> .repo file: Warning Obtaining and installing software packages from unverified or untrusted sources other than Red Hat certificate-based Content Delivery Network ( CDN ) is a potential security risk, and can lead to security, stability, compatibility, and maintainability issues. 10.3. Enabling a YUM repository Once you added a YUM repository to your system, enable it to ensure installation and updates. Procedure Enable a repository: 10.4. Disabling a YUM repository To to prevent particular packages from installation or update, you can disable a YUM repository that contains these packages. Procedure Disable a repository:

Commands:
yum-config-manager --add-repo <repository_URL>
cat /etc/yum.repos.d/ <repository_URL> .repo
yum-config-manager --enable <repository_id>
yum-config-manager --disable <repository_id>
4.118. kdeutils 4.118.1. RHBA-2011:1206 - kdeutils bug fix update Updated kdeutils packages that fix one bug are now available for Red Hat Enterprise Linux 6. KDE is a graphical desktop environment for the X Window System. The kdeutils packages include several utilities for the KDE desktop environment. Bug Fix BZ# 625116 Prior to this update, the icon for the Sweeper utility did not appear correctly in GNOME Application's Accessories menu. This bug has been fixed in this update so that the icon is now displayed as expected. All users of kdeutils are advised to upgrade to these updated packages, which fix this bug.

Commands:
14.4. Steal Time Accounting Steal time is the amount of CPU time desired by a guest virtual machine that is not provided by the host. Steal time occurs when the host allocates these resources elsewhere: for example, to another guest. Steal time is reported in the CPU time fields in /proc/stat as st . It is automatically reported by utilities such as top and vmstat , and cannot be switched off. Large amounts of steal time indicate CPU contention, which can reduce guest performance. To relieve CPU contention, increase the guest's CPU priority or CPU quota, or run fewer guests on the host.

Commands:
Chapter 1. Building applications overview Using Red Hat OpenShift Service on AWS, you can create, edit, delete, and manage applications using the web console or command line interface (CLI). 1.1. Working on a project Using projects, you can organize and manage applications in isolation. You can manage the entire project lifecycle, including creating, viewing, and deleting a project in Red Hat OpenShift Service on AWS. After you create the project, you can grant or revoke access to a project and manage cluster roles for the users using the Developer perspective. You can also edit the project configuration resource while creating a project template that is used for automatic provisioning of new projects. As a user with dedicated administrator permissions, you can choose to prevent an authenticated user group from self-provisioning new projects . 1.2. Working on an application 1.2.1. Creating an application To create applications, you must have created a project or have access to a project with the appropriate roles and permissions. You can create an application by using either the Developer perspective in the web console , installed Operators , or the OpenShift CLI ( oc ) . You can source the applications to be added to the project from Git, JAR files, devfiles, or the developer catalog. You can also use components that include source or binary code, images, and templates to create an application by using the OpenShift CLI ( oc ). With the Red Hat OpenShift Service on AWS web console, you can create an application from an Operator installed by a cluster administrator. 1.2.2. Maintaining an application After you create the application, you can use the web console to monitor your project or application metrics . You can also edit or delete the application using the web console. When the application is running, not all applications resources are used. As a cluster administrator, you can choose to idle these scalable resources to reduce resource consumption. 1.2.3. Deploying an application You can deploy your application using Deployment or DeploymentConfig objects and manage them from the web console. You can create deployment strategies that help reduce downtime during a change or an upgrade to the application. You can also use Helm , a software package manager that simplifies deployment of applications and services to Red Hat OpenShift Service on AWS clusters. 1.3. Using the Red Hat Marketplace The Red Hat Marketplace is an open cloud marketplace where you can discover and access certified software for container-based environments that run on public clouds and on-premises.

Commands:
Chapter 5. Planning for Installation on 64-bit AMD, Intel, and ARM Systems This chapter outlines the decisions and preparations you will need to make when deciding how to proceed with the installation. 5.1. Upgrade or Install? There are two procedures available for upgrading your current system to the major version of Red Hat Enterprise Linux. To decide which procedure is the right one for your system, read the following descriptions: Clean Install A clean install is performed by backing up all data from the system, formatting disk partitions, performing an installation of Red Hat Enterprise Linux from installation media, and then restoring any user data. Note This is the recommended method for upgrading between major versions of Red Hat Enterprise Linux. In-Place Upgrade An in-place upgrade is a way of upgrading your system without removing the older version first. The procedure requires installing the migration utilities available for your system and running them as any other software. In Red Hat Enterprise Linux, the Preupgrade Assistant assesses your current system and identifies potential problems you might encounter during or after the upgrade. It also performs minor fixes and modifications to the system. The Red Hat Upgrade Tool utility downloads the packages and performs the actual upgrade. An in-place upgrade requires a lot of troubleshooting and planning and should only be done if there is no other choice. For more information on the Preupgrade Assistant , see Chapter 29, Upgrading Your Current System . Warning Never perform an in-place upgrade on a production system without first testing it on a cloned backup copy of the system.

Commands:
20.2. Shared Quota and Individually Defined Quota Users with SuperUser permissions can create quotas for individual users or quotas for groups. Group quotas can be set for Active Directory users. If a group of ten users are given a quota of 1 TB of storage and one of the ten users fills the entire terabyte, then the entire group will be in excess of the quota and none of the ten users will be able to use any of the storage associated with their group. An individual user's quota is set for only the individual. Once the individual user has used up all of his or her storage or runtime quota, the user will be in excess of the quota and the user will no longer be able to use the storage associated with his or her quota.

Commands:
7.200. python-virtinst 7.200.1. RHBA-2013:0463 - python-virtinst bug fix and enhancement update Updated python-virtinst package that fixes one bug and adds two enhancements is now available for Red Hat Enterprise Linux 6. The python-virtinst package contains several command-line utilities, including virt-install for building and installing new virtual machines, and virt-clone for cloning existing virtual machines. Bug Fix BZ#834495 Prior to this update, executing the "virt-install --cpuset=auto" command led to a backtrace, and the optimal configuration of the "cpuset" string was not formed. With this update, a patch has been backported from upstream and the described error no longer occurs. Enhancements BZ# 803631 With this update, Red Hat Enterprise Linux 7 has been added to the list of known Linux distributions in both the virt-manager and virt-install utilities. BZ#832339 Previously, the virt-install utility supported only the first security label listed in the libvirt capabilities. With this update, support for more labels has been added. All users of python-virtinst are advised to upgrade to this updated package, which fixes this bug and adds these enhancements.

Commands:
7.269. virt-what 7.269.1. RHEA-2013:0483 - virt-what enhancement update Updated virt-what packages that add one enhancement are now available for Red Hat Enterprise Linux 6. The virt-what packages provide a command-line tool that is used to detect whether the operating system is running inside a virtual machine. Enhancement BZ#829427 This enhancement adds support for the Virtage hardware partitioning system to the virt-what utility. All users of virt-what are advised to upgrade to these updated packages, which add this enhancement.

Commands:
2.5.4.4. The sar command The sar command produces system utilization reports based on the data collected by sadc . As configured in Red Hat Enterprise Linux, sar is automatically run to process the files automatically collected by sadc . The report files are written to /var/log/sa/ and are named sar <dd> , where <dd> is the two-digit representations of the day's two-digit date. sar is normally run by the sa2 script. This script is periodically invoked by cron via the file sysstat , which is located in /etc/cron.d/ . By default, cron runs sa2 once a day at 23:53, allowing it to produce a report for the entire day's data. 2.5.4.4.1. Reading sar Reports The format of a sar report produced by the default Red Hat Enterprise Linux configuration consists of multiple sections, with each section containing a specific type of data, ordered by the time of day that the data was collected. Since sadc is configured to perform a one-second measurement interval every ten minutes, the default sar reports contain data in ten-minute increments, from 00:00 to 23:50 [7] . Each section of the report starts with a heading describing the data contained in the section. The heading is repeated at regular intervals throughout the section, making it easier to interpret the data while paging through the report. Each section ends with a line containing the average of the data reported in that section. Here is a sample section sar report, with the data from 00:30 through 23:40 removed to save space: In this section, CPU utilization information is displayed. This is very similar to the data displayed by iostat . Other sections may have more than one line's worth of data per time, as shown by this section generated from CPU utilization data collected on a dual-processor system: There are a total of seventeen different sections present in reports generated by the default Red Hat Enterprise Linux sar configuration; some are explored in upcoming chapters. For more information about the data contained in each section, refer to the sar(1) man page. [7] Due to changing system loads, the actual time at which the data was collected may vary by a second or two.

Commands:
00:00:01 CPU %user %nice %system %idle 00:10:00 all 6.39 1.96 0.66 90.98 00:20:01 all 1.61 3.16 1.09 94.14 ... 23:50:01 all 44.07 0.02 0.77 55.14 Average: all 5.80 4.99 2.87 86.34
00:00:01 CPU %user %nice %system %idle 00:10:00 0 4.19 1.75 0.70 93.37 00:10:00 1 8.59 2.18 0.63 88.60 00:20:01 0 1.87 3.21 1.14 93.78 00:20:01 1 1.35 3.12 1.04 94.49 ... 23:50:01 0 42.84 0.03 0.80 56.33 23:50:01 1 45.29 0.01 0.74 53.95 Average: 0 6.00 5.01 2.74 86.25 Average: 1 5.61 4.97 2.99 86.43
10.2. NATIVE This is only applicable on source models (also default). When used, the metadata for the model is retrieved from the source database itself. Example 10.1. Sample vdb.xml file <vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="NATIVE"></metadata> </model> </vdb> Note If a user implements the getMetadata method on the ExecutionFactory class, NATIVE uses this method to retrieve the metadata from source.

Commands:
<vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="NATIVE"></metadata> </model> </vdb>
1.2.3.2. Storage An environment that uses distributed computing uses multiple instances of shared storage. This can mean one of two things: Multiple systems storing data in a single location A storage unit (e.g. a volume) composed of multiple storage appliances The most familiar example of storage is the local disk drive mounted on a system. This is appropriate for IT operations where all applications are hosted on one host, or even a small number of hosts. However, as the infrastructure scales to dozens or even hundreds of systems, managing as many local storage disks becomes difficult and complicated. Distributed storage adds a layer to ease and automate storage hardware administration as the business scales. Having multiple systems share a handful of storage instances reduces the number of devices the administrator needs to manage. Consolidating the storage capabilities of multiple storage appliances into one volume helps both users and administrators. This type of distributed storage provides a layer of abstraction to storage pools: users see a single unit of storage, which an administrator can easily grow by adding more hardware. Some technologies that enable distributed storage also provide added benefits, such as failover and multipathing. NFS Network File System (NFS) allows multiple servers or users to mount and use the same instance of remote storage via TCP or UDP. NFS is commonly used to hold data shared by multiple applications. It is also convenient for bulk storage of large amounts of data. SAN Storage Area Networks (SANs) use either Fibre Channel or iSCSI protocol to provide remote access to storage. Fibre Channel infrastructure (such as Fibre Channel host bus adapters, switches, and storage arrays) combines high performance, high bandwidth, and massive storage. SANs separate storage from processing, providing considerable flexibility in system design. The other major advantage of SANs is that they provide a management environment for performing major storage hardware administrative tasks. These tasks include: Controlling access to storage Managing large amounts of data Provisioning systems Backing up and replicating data Taking snapshots Supporting system failover Ensuring data integrity Migrating data GFS2 The Red Hat Global File System 2 (GFS2) file system provides several specialized capabilities. The basic function of GFS2 is to provide a single file system, including concurrent read/write access, shared across multiple members of a cluster. This means that each member of the cluster sees exactly the same data "on disk" in the GFS2 filesystem. GFS2 allows all systems to have concurrent access to the "disk". To maintain data integrity, GFS2 uses a Distributed Lock Manager (DLM), which only allows one system to write to a specific location at a time. GFS2 is especially well-suited for failover applications that require high availability in storage. For further information about GFS2, refer to the Global File System 2 . For further information about storage in general, refer to the Storage Administration Guide . Both are available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ .

Commands: