mtpti5iD/redhat-docs_dataset huggingface dataset:
4.5. Enhancements to NUMA in Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 6 includes a number of enhancements to capitalize on the full potential of today's highly scalable hardware. This section gives a high-level overview of the most important NUMA-related performance enhancements provided by Red Hat Enterprise Linux 6. 4.5.1. Bare-metal and Scalability Optimizations 4.5.1.1. Enhancements in topology-awareness The following enhancements allow Red Hat Enterprise Linux to detect low-level hardware and architecture details, improving its ability to automatically optimize processing on your system. enhanced topology detection This allows the operating system to detect low-level hardware details (such as logical CPUs, hyper threads, cores, sockets, NUMA nodes and access times between nodes) at boot time, and optimize processing on your system. completely fair scheduler This new scheduling mode ensures that runtime is shared evenly between eligible processes. Combining this with topology detection allows processes to be scheduled onto CPUs within the same socket to avoid the need for expensive remote memory access, and ensure that cache content is preserved wherever possible. malloc malloc is now optimized to ensure that the regions of memory that are allocated to a process are as physically close as possible to the core on which the process is executing. This increases memory access speeds. skbuff I/O buffer allocation Similarly to malloc , this is now optimized to use memory that is physically close to the CPU handling I/O operations such as device interrupts. device interrupt affinity Information recorded by device drivers about which CPU handles which interrupts can be used to restrict interrupt handling to CPUs within the same physical socket, preserving cache affinity and limiting high-volume cross-socket communication. 4.5.1.2. Enhancements in Multi-processor Synchronization Coordinating tasks between multiple processors requires frequent, time-consuming operations to ensure that processes executing in parallel do not compromise data integrity. Red Hat Enterprise Linux includes the following enhancements to improve performance in this area: Read-Copy-Update (RCU) locks Typically, 90% of locks are acquired for read-only purposes. RCU locking removes the need to obtain an exclusive-access lock when the data being accessed is not being modified. This locking mode is now used in page cache memory allocation: locking is now used only for allocation or deallocation operations. per-CPU and per-socket algorithms Many algorithms have been updated to perform lock coordination among cooperating CPUs on the same socket to allow for more fine-grained locking. Numerous global spinlocks have been replaced with per-socket locking methods, and updated memory allocator zones and related memory page lists allow memory allocation logic to traverse a more efficient subset of the memory mapping data structures when performing allocation or deallocation operations.

Commands:
Chapter 4. Validate the Completed Restore Use the following commands to perform a healthcheck of your newly restored environment: 4.1. Check Identity Service (Keystone) Operation This step validates Identity Service operations by querying for a list of users. When run from the controller, the output of this command should include a list of users created in your environment. This action demonstrates that keystone is running and successfully authenticating user requests. For example:

Commands:
source stackrc openstack user list
openstack user list +----------------------------------+------------+---------+----------------------+ | id | name | enabled | email | +----------------------------------+------------+---------+----------------------+ | 9e47bb53bb40453094e32eccce996828 | admin | True | root@localhost | | 9fe2466f88cc4fa0ba69e59b47898829 | ceilometer | True | ceilometer@localhost | | 7a40d944e55d422fa4e85daf47e47c42 | cinder | True | cinder@localhost | | 3d2ed97538064f258f67c98d1912132e | demo | True | | | 756e73a5115d4e9a947d8aadc6f5ac22 | glance | True | glance@localhost | | f0d1fcee8f9b4da39556b78b72fdafb1 | neutron | True | neutron@localhost | | e9025f3faeee4d6bb7a057523576ea19 | nova | True | nova@localhost | | 65c60b1278a0498980b2dc46c7dcf4b7 | swift | True | swift@localhost | +----------------------------------+------------+---------+----------------------+
Chapter 13. Configuring burst and QPS for net-kourier The queries per second (QPS) and burst values determine the frequency of requests or API calls to the API server. 13.1. Configuring burst and QPS values for net-kourier The queries per second (QPS) value determines the number of client requests or API calls that are sent to the API server. The burst value determines how many requests from the client can be stored for processing. Requests exceeding this buffer will be dropped. This is helpful for controllers that are bursty and do not spread their requests uniformly in time. When the net-kourier-controller restarts, it parses all ingress resources deployed on the cluster, which leads to a significant number of API calls. Due to this, the net-kourier-controller can take a long time to start. You can adjust the QPS and burst values for the net-kourier-controller in the KnativeServing CR: KnativeServing CR example apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: workloads: - name: net-kourier-controller env: - container: controller envVars: - name: KUBE_API_BURST value: "200" 1 - name: KUBE_API_QPS value: "200" 2 1 The QPS rate of communication between controller and the API Server. The default value is 200. 2 The burst capacity of communication between Kubelet and the API Server. The default value is 200.

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: workloads: - name: net-kourier-controller env: - container: controller envVars: - name: KUBE_API_BURST value: "200" 1 - name: KUBE_API_QPS value: "200" 2
5.60. espeak 5.60.1. RHBA-2012:1118 - espeak bug fix update Updated espeak packages that fix one bug are now available for Red Hat Enterprise Linux 6. The espeak packages contain a software speech synthesizer for English and other languages. eSpeak uses a "formant synthesis" method, which allows many languages to be provided in a small size. Bug Fix BZ# 789997 Previously, eSpeak manipulated the system sound volume. As a consequence, eSpeak could set the sound volume to maximum regardless of the amplitude specified. The sound volume management code has been removed from eSpeak, and now only PulseAudio manages the sound volume. All users of espeak are advised to upgrade to these updated packages, which fix this bug.

Commands:
7.46. elfutils 7.46.1. RHEA-2015:1302 - elfutils bug fix and enhancement update Updated elfutils packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The elfutils packages contain a number of utility programs and libraries related to the creation and maintenance of executable code. Note The elfutils packages have been upgraded to upstream version 0.161, which provides a number of bug fixes and enhancements over the version. (BZ# 1167724 ) Bug Fix BZ# 1167724 The eu-stack utility supports showing inlined frames and it is now able to produce backtraces even for processes that might have some of their on-disk libraries updated or deleted. Improved DWZ compressed DWARF multi-file support with new functions, "dwarf_getalt" and "dwarf_setalt", has been introduced. Support for ARM 64-bit architecture and Red Hat Enterprise Linux for POWER, little endian has been added. The libdw library now supports LZMA-compressed (.ko.xz) kernel modules. Support for ".debug_macro" has been added; new functions has been introduced: "dwarf_getmacros_off", "dwarf_macro_getsrcfiles", "dwarf_macro_getparamcnt", and "dwarf_macro_param". New GNU extensions to the DWARF format are now recognized. New functions have been added to the libdw library: "dwarf_peel_type", "dwarf_cu_getdwarf", "dwarf_cu_die", "dwelf_elf_gnu_debuglink", "dwelf_dwarf_gnu_debugaltlink", "dwelf_elf_gnu_build_id". Users of elfutils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Appendix A. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ Streams entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2021-04-19 16:15:39 UTC

Commands:
Chapter 94. XML Tokenize The XML Tokenize language is a built-in language in camel-xml-jaxp , which is a truly XML-aware tokenizer that can be used with the Split EIP as the conventional Tokenize to efficiently and effectively tokenize XML documents.. XML Tokenize is capable of not only recognizing XML namespaces and hierarchical structures of the document but also more efficiently tokenizing XML documents than the conventional Tokenize language. Additional dependency In order to use this component, an additional dependency is required as follows: <dependency> <groupId>org.codehaus.woodstox</groupId> <artifactId>woodstox-core-asl</artifactId> <version>4.4.1</version> </dependency> or <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-stax-starter</artifactId> </dependency> 94.1. XML Tokenizer Options The XML Tokenize language supports 4 options, which are listed below. Name Default Java Type Description headerName String Name of header to tokenize instead of using the message body. mode Enum The extraction mode. The available extraction modes are: i - injecting the contextual namespace bindings into the extracted token (default) w - wrapping the extracted token in its ancestor context u - unwrapping the extracted token to its child content t - extracting the text content of the specified element. Enum values: i w u t group Integer To group N parts together. trim Boolean Whether to trim the value to remove leading and trailing whitespaces and line breaks. 94.2. Example See Split EIP which has examples using the XML Tokenize language. 94.3. Spring Boot Auto-Configuration When using xtokenize with Spring Boot make sure to use the following Maven dependency to have support for auto configuration: <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-xml-jaxp-starter</artifactId> </dependency> The component supports 3 options, which are listed below. Name Description Default Type camel.language.xtokenize.enabled Whether to enable auto configuration of the xtokenize language. This is enabled by default. Boolean camel.language.xtokenize.mode The extraction mode. The available extraction modes are: i - injecting the contextual namespace bindings into the extracted token (default) w - wrapping the extracted token in its ancestor context u - unwrapping the extracted token to its child content t - extracting the text content of the specified element. String camel.language.xtokenize.trim Whether to trim the value to remove leading and trailing whitespaces and line breaks. true Boolean

Commands:
<dependency> <groupId>org.codehaus.woodstox</groupId> <artifactId>woodstox-core-asl</artifactId> <version>4.4.1</version> </dependency>
<dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-stax-starter</artifactId> </dependency>
<dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-xml-jaxp-starter</artifactId> </dependency>
3.6. Additional Resources See the following resources for more information about managing users and groups. 3.6.1. Installed Documentation For information about various utilities for managing users and groups, see the following manual pages: chage (1) - A command to modify password aging policies and account expiration. gpasswd (1) - A command to administer the /etc/group file. groupadd (8) - A command to add groups. grpck (8) - A command to verify the /etc/group file. groupdel (8) - A command to remove groups. groupmod (8) - A command to modify group membership. pwck (8) - A command to verify the /etc/passwd and /etc/shadow files. pwconv (8) - A tool to convert standard passwords to shadow passwords. pwunconv (8) - A tool to convert shadow passwords to standard passwords. useradd (8) - A command to add users. userdel (8) - A command to remove users. usermod (8) - A command to modify users. For information about related configuration files, see: group (5) - The file containing group information for the system. passwd (5) - The file containing user information for the system. shadow (5) - The file containing passwords and account expiration information for the system. login.defs (5) - The file containing shadow password suite configuration. useradd (8) - For /etc/default/useradd , section "Changing the default values" in manual page.

Commands:
Chapter 1. New features This section highlights new features in Red Hat Developer Hub 1.4. 1.1. Added an individual mountPath This update adds an individual mountPath for extra ConfigMaps or Secrets . 1.2. PersistentVolumeClaims support is available With this update, PersistentVolumeClaims (PVC) support is available. 1.3. Enhanced use of kube-rbac-proxy This update removes the kube-rbac-proxy sidecar container from the RHDH Operator Pod. This sidecar container protected the operator metrics endpoint. However, the main container now provides this functionality out-of-the-box. Removing this sidecar container allows for reducing the resources required to run the Operator. 1.4. Identifying Backstage flavor for plugins by using the developerHub.flavor field With this update, you can use the developerHub.flavor field to identify whether plugins are running on RHDH, RHTAP, or vanilla Backstage, as shown in the following example: app-config.yaml fragment with the developerhub.flavor field developerHub: flavor: <flavor> flavor Identify the flavor of Backstage that is running. Default value: rhdh 1.5. Ability to manage Persistent Volume Claim (PVCs) in RHDH Operator You can now mount directories from pre-created PersistentVolumeClaims (PVCs) using the spec.application.extraFiles.pvcs field, while configuring RHDH Operator. For more information, see Configuring Red Hat Developer Hub deployment when using the Operator . 1.6. Authenticating with Red Hat Build of Keycloak With this update, you can use Red Hat Build of Keycloak as an authentication provider. The Keycloak plugin will now support ingesting users and groups with Red Hat Build of Keycloak. For more details, see Authenticating with Red Hat Build of Keycloak . 1.7. Ability to install third-party plugins in RHDH You can now install third-party plugins in Red Hat Developer Hub without rebuilding the RHDH application. For more information, see Installing third-party plugins in Red Hat Developer Hub . 1.8. The catalog backend module logs plugin is enabled With this update, the backstage-plugin-catalog-backend-module-logs is enabled and converted to a static plugin improving performance and stability. The dynamic plugin was disabled in version 1.3 . 1.9. Google Kubernetes Engine now supported Google Kubernetes Engine (GKE) is out of Developer Preview and is now fully supported as of RHDH 1.4. See the full list of supported platforms on the Life Cycle page . 1.10. Manage concurrent writing when installing dynamic plugins Previously, running multi-replica RHDH with a Persistent Volume for the Dynamic Plugins cache was not possible due to potential write conflicts. This update mitigates that risk.

Commands:
developerHub: flavor: <flavor>
2.2. Creating CacheManagers 2.2.1. Create a New RemoteCacheManager Procedure 2.1. Configure a New RemoteCacheManager Use the ConfigurationBuilder() constructor to create a new configuration builder. The .addServer() method adds a remote server, configured via the .host(<hostname|ip>) and .port(<port>) properties. Create a new RemoteCacheManager using the supplied configuration. Retrieve the default cache from the remote server. Report a bug 2.2.2. Create a New Embedded Cache Manager Use the following instructions to create a new EmbeddedCacheManager without using CDI: Procedure 2.2. Create a New Embedded Cache Manager Create a configuration XML file. For example, create the my-config-file.xml file on the classpath (in the resources/ folder) and add the configuration information in this file. Use the following programmatic configuration to create a cache manager using the configuration file: The outlined procedure creates a new EmbeddedCacheManager using the configuration specified in my-config-file.xml . Report a bug 2.2.3. Create a New Embedded Cache Manager Using CDI Use the following steps to create a new EmbeddedCacheManager instance using CDI: Procedure 2.3. Use CDI to Create a New EmbeddedCacheManager Specify a default configuration: Inject the default cache manager. Report a bug

Commands:
import org.infinispan.client.hotrod.RemoteCache; import org.infinispan.client.hotrod.RemoteCacheManager; import org.infinispan.client.hotrod.configuration.Configuration; import org.infinispan.client.hotrod.configuration.ConfigurationBuilder; Configuration conf = new ConfigurationBuilder().addServer().host("localhost").port(11222).build(); RemoteCacheManager manager = new RemoteCacheManager(conf); RemoteCache defaultCache = manager.getCache();
EmbeddedCacheManager manager = new DefaultCacheManager("my-config-file.xml"); Cache defaultCache = manager.getCache();
public class Config @Produces public EmbeddedCacheManager defaultCacheManager() { ConfigurationBuilder builder = new ConfigurationBuilder(); Configuration configuration = builder.eviction().strategy(EvictionStrategy.LRU).maxEntries(100).build(); return new DefaultCacheManager(configuration); } }
<!-- Additional configuration information here --> @Inject EmbeddedCacheManager cacheManager; <!-- Additional configuration information here -->
23.2. Userspace Access Always take care to use properly aligned and sized I/O. This is especially important for Direct I/O access. Direct I/O should be aligned on a logical_block_size boundary, and in multiples of the logical_block_size . With native 4K devices (i.e. logical_block_size is 4K) it is now critical that applications perform direct I/O in multiples of the device's logical_block_size . This means that applications will fail with native 4k devices that perform 512-byte aligned I/O rather than 4k-aligned I/O. To avoid this, an application should consult the I/O parameters of a device to ensure it is using the proper I/O alignment and size. As mentioned earlier, I/O parameters are exposed through the both sysfs and block device ioctl interfaces. For more details, refer to man libblkid . This man page is provided by the libblkid-devel package. sysfs Interface /sys/block/ disk /alignment_offset /sys/block/ disk / partition /alignment_offset /sys/block/ disk /queue/physical_block_size /sys/block/ disk /queue/logical_block_size /sys/block/ disk /queue/minimum_io_size /sys/block/ disk /queue/optimal_io_size The kernel will still export these sysfs attributes for "legacy" devices that do not provide I/O parameters information, for example: Example 23.1. sysfs interface Block Device ioctls BLKALIGNOFF : alignment_offset BLKPBSZGET : physical_block_size BLKSSZGET : logical_block_size BLKIOMIN : minimum_io_size BLKIOOPT : optimal_io_size

Commands:
alignment_offset: 0 physical_block_size: 512 logical_block_size: 512 minimum_io_size: 512 optimal_io_size: 0
Chapter 17. Installing a three-node cluster on AWS In OpenShift Container Platform version 4.13, you can install a three-node cluster on Amazon Web Services (AWS). A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. Note Deploying a three-node cluster using an AWS Marketplace image is not supported. 17.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: compute: - name: worker platform: {} replicas: 0 If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 17.2. steps Installing a cluster on AWS with customizations Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates

Commands:
compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 13. Viewing Threads You can view and monitor the state of threads. Procedure : Click the Runtime tab and then the Threads subtab. The Threads page lists active threads and stack trace details for each thread. By default, the thread list shows all threads in descending ID order. To sort the list by increasing ID, click the ID column label. Optionally, filter the list by thread state (for example, Blocked ) or by thread name. To drill down to detailed information for a specific thread, such as the lock class name and full stack trace for that thread, in the Actions column, click More .

Commands: