mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Monitoring and tuning Data Grid queries Data Grid exposes statistics for queries and provides attributes that you can adjust to improve query performance. 6.1. Getting query statistics Collect statistics to gather information about performance of your indexes and queries, including information such as the types of indexes and average time for queries to complete. Procedure Do one of the following: Invoke the getSearchStatistics() or getClusteredSearchStatistics() methods for embedded caches. Use GET requests to obtain statistics for remote caches from the REST API. Embedded caches // Statistics for the local cluster member SearchStatistics statistics = Search.getSearchStatistics(cache); // Consolidated statistics for the whole cluster CompletionStage<SearchStatisticsSnapshot> statistics = Search.getClusteredSearchStatistics(cache) Remote caches 6.2. Tuning query performance Use the following guidelines to help you improve the performance of indexing operations and queries. Checking index usage statistics Queries against partially indexed caches return slower results. For instance, if some fields in a schema are not annotated then the resulting index does not include those fields. Start tuning query performance by checking the time it takes for each type of query to run. If your queries seem to be slow, you should make sure that queries are using the indexes for caches and that all entities and field mappings are indexed. Adjusting the commit interval for indexes Indexing can degrade write throughput for Data Grid clusters. The commit-interval attribute defines the interval, in milliseconds, between which index changes that are buffered in memory are flushed to the index storage and a commit is performed. This operation is costly so you should avoid configuring an interval that is too small. The default is 1000 ms (1 second). Adjusting the refresh interval for queries The refresh-interval attribute defines the interval, in milliseconds, between which the index reader is refreshed. The default value is 0 , which returns data in queries as soon as it is written to a cache. A value greater than 0 results in some stale query results but substantially increases throughput, especially in write-heavy scenarios. If you do not need data returned in queries as soon as it is written, you should adjust the refresh interval to improve query performance.

Commands:
// Statistics for the local cluster member SearchStatistics statistics = Search.getSearchStatistics(cache); // Consolidated statistics for the whole cluster CompletionStage<SearchStatisticsSnapshot> statistics = Search.getClusteredSearchStatistics(cache)
GET /rest/v2/caches/{cacheName}/search/stats
Chapter 33. Editing or deleting columns in guided decision tables You can edit or delete the columns you have created at any time in the guided decision tables designer. Procedure In the guided decision tables designer, click Columns . Expand the appropriate section and click Edit or Delete to the column name. Figure 33.1. Edit or delete columns Note A condition column cannot be deleted if an existing action column uses the same pattern-matching parameters as the condition column. After any column changes, click Finish in the wizard to save.

Commands:
probe::ioscheduler_trace.elv_issue_request Name probe::ioscheduler_trace.elv_issue_request - Fires when a request is Synopsis Values disk_major Disk major no of request. rq Address of request. name Name of the probe point elevator_name The type of I/O elevator currently enabled. disk_minor Disk minor number of request. rq_flags Request flags. Description scheduled.

Commands:
ioscheduler_trace.elv_issue_request
7.180. perl-Sys-Virt 7.180.1. RHBA-2013:0377 - perl-Sys-Virt bug fix and enhancement update Updated perl-Sys-Virt packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The perl-Sys-Virt packages provide application programming interfaces (APIs) to manage virtual machines from Perl with the libvirt library. Note The perl-Sys-Virt package has been upgraded to upstream version 0.10.2, which provides a number of enhancements over the version. (BZ#836955) Bug Fixes BZ# 848309 Previously, the Perl binding was setting an incompatible flag for the set_blkio_parameters() function. Consequently, it was impossible to use this function to apply block tuning. The incorrect flag has been removed and set_blkio_parameters() can now be used as expected. BZ# 861581 Prior to this update, an incorrect string length was used when setting hash keys, and thus names of certain hash keys were truncated. The correct string lengths were provided for hash keys and the hash keys for the get_node_memory_stats() function now match their documentation. BZ# 865310 When setting memory parameters, the set_node_memory_parameters() function was trying to also update some read-only values. Consequently, set_node_memory_parameters() always returned an error message. To fix this bug, the method has been changed to only set parameters, and set_node_memory_parameters() now works as expected. BZ# 869130 Previously, the API documentation contained formatting errors. This update provides correction of the API documentation, which formats the documentation correctly. BZ# 873203 Due to missing default values for parameters in the pm_suspend_for_duration() and pm_wakeup() functions, callers of the API had to supply the parameters even though they were supposed to be optional. With this update, the default values have been added to these functions, which now succeed when called. BZ# 882829 Prior to this update, mistakes were present in the Plain Old Documentation (POD) for the list_all_volumes() parameters, which could mislead users. The documentation has been updated and, for list_all_volumes() now describes the API usage correctly. BZ# 883775 Previously, an incorrect class name was used with the list_all_nwfilters() function. Consequently, the objects returned from list_all_nwfilters() could not be used. Now, the object name has been fixed and the list_all_nwfilters() function works as expected. BZ# 886028 When checking return value of the screenshot() and current_snapshot() functions, a wrong data type was assumed. Consequently, certain errors were not handled properly and applications could eventually terminate unexpectedly. With this update, API errors are correctly handled in screenshot() and current_snapshot(), and the applications no longer crash. Users of perl-Sys-Virt are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 18. The camel-jbossdatagrid-fuse Quickstart This quickstart shows how to use the component described in Section 5.1, "The camel-jbossdatagrid Component" on JBoss Fuse to interact with JBoss Data Grid. This quickstart will deploy two bundles, local_cache_producer and local_cache_consumer , on Fuse, one on each container child1 and child2 respectivity. Below is a description of each of the bundles: local_cache_producer : Scans a folder (/tmp/incoming) for incoming CSV files of the format "id, firstName, lastName, age". If a file is dropped with entries in the given format, each entry is read and transformed into a Person POJO and stored in the data grid. local_cache_consumer : Lets you query for a POJO using a RESTful interface and receive a JSON representation of the Person POJO stored in the data grid for the given key The bundles reside in two different containers; the consumer is able to extract what the producer has put in due to the same configuration being used in the infinispan.xml and jgroups.xml files. The infinispan.xml file defines a REPL (replicated) cache named camel-cache , and both the consumer and producer interact with this cache. Report a bug 18.1. Quickstart Prerequisites The prerequisites for this quickstart are as follows: Java 7.0 (Java SDK 1.7) or better Maven 3.0 or better JBoss Fuse 6.2.0 or better Configure the Maven Repository. For details, see Chapter 3, Install and Use the Maven Repositories Report a bug

Commands:
Chapter 1. Customizing your taxonomy tree You can modify the taxonomy tree with knowledge data in your RHEL AI environment to create your own custom Granite Large Language Model (LLM). On RHEL AI, knowledge data sets are formatted in YAML. This YAML configuration is called a qna.yaml file, where "qna" stands for question and answer. The following documentation sections describe how to create skill and knowledge sets for your taxonomy. Adding knowledge to your taxonomy tree Adding skills to your taxonomy tree There are a few supported knowledge document types that you can use for training the base Granite LLM. The current supported document types include: Markdown PDF Note RHEL AI currently only supports training with skills and knowledge. Skills only model customization is not supported. 1.1. Overview of skill and knowledge You can use skill and knowledge sets and specify domain-specific information to teach your custom model. Knowledge A dataset that consists of background information and facts. When creating knowledge sets for a model, you are providing it with additional data and information so the model can answer questions more accurately. Skills A dataset where you can teach the model how to do a task. Skills on RHEL AI are split into categories: Compositional skill: Compositional skills allow AI models to perform specific tasks or functions. There are two types of composition skills: Freeform compositional skills: These are performative skills that to not require additional context or information to function. Grounded compositional skills: These are performative skills that require additional context. For example, you can teach the model to read a table, where the additional context is an example of the table layout. Foundation skills: Foundational skills are skills that involve math, reasoning, and coding. Important Ensure your server is not running before you start customizing your Granite starter model. Additional Resources Sample knowledge specifications

Commands:
Chapter 4. Metrics data retention The storage capacity required by PCP data logging is determined by the following factors: The logged metrics The logging interval The retention policy The default logging (sampling) interval is 60 seconds. The default retention policy is to compress archives older than one day and to keep archives for the last 14 days. You can increase the logging interval or shorten the retention policy to save storage space. If you require high-resolution sampling, you can decrease the logging interval. In such case, ensure that you have enough storage space. PCP archive logs are stored in the /var/log/pcp/pmlogger/ satellite.example.com directory. 4.1. Changing default logging interval You can change the default logging interval to either increase or decrease the sampling rate, at which the PCP metrics are logged. A larger interval results in a lower sampling rate. Procedure Open the /etc/pcp/pmlogger/control.d/local configuration file. Locate the LOCALHOSTNAME line. Append -t XX s , where XX is the required time interval in seconds. Save the file. Restart the pmlogger service: 4.2. Changing data retention policy You can change the data retention policy to control after how long the PCP data are archived and deleted. Procedure Open the /etc/sysconfig/pmlogger_timers file. Locate the PMLOGGER_DAILY_PARAMS line. If the line is commented, uncomment the line. Configure the following parameters: Ensure the default -E parameter is present. Append the -x parameter and add a value for the required number of days after which data is archived. Append the -k parameter and add a value for the number of days after which data is deleted. For example, the parameters -x 4 -k 7 specify that data will be compressed after 4 days and deleted after 7 days. Save the file. 4.3. Viewing data storage statistics You can list all available metrics, grouped by the frequency at which they are logged. For each group, you can also view the storage required to store the listed metrics, per day. Example storage statistics: Procedure To view data storage statistics, enter the following command on your Satellite Server:

Commands:
systemctl restart pmlogger
logged every 60 sec: 61752 bytes or 84.80 Mbytes/day
less /var/log/pcp/pmlogger/ satellite.example.com /pmlogger.log
28.3.2. Reporting Problems To report a certain problem, use the command: abrt-cli report directory ...where directory stands for the problem data directory of the problem that is being reported. For example: ABRT prompts you to select an analyzer event for the problem that is being reported. After selecting an event, the problem is analyzed. This can take a considerable amount of time. When the problem report is ready, abrt-cli opens a text editor with the content of the report. You can see what is being reported, and you can fill in instructions on how to reproduce the crash and other comments. You should also check the backtrace, because the backtrace might be sent to a public server and viewed by anyone, depending on the problem reporter event settings. Note You can choose which text editor is used to check the reports. abrt-cli uses the editor defined in the ABRT_EDITOR environment variable. If the variable is not defined, it checks the VISUAL and EDITOR variables. If none of these variables is set, vi is used. You can set the preferred editor in your .bashrc configuration file. For example, if you prefer GNU Emacs, add the following line to the file: When you are done with the report, save your changes and close the editor. You will be asked which of the configured ABRT reporter events you want to use to send the report. After selecting a reporting method, you can proceed with reviewing data to be sent with the report. The following table shows options available with the abrt-cli report command. Table 28.4. The abrt-cli report command options Option Description With no additional option, the abrt-cli report command provides the usual output. -v , --verbose abrt-cli report provides additional information on its actions.

Commands:
~]USD abrt-cli report /var/spool/abrt/ccpp-2011-09-13-10:18:14-2895 How you would like to analyze the problem? 1) Collect .xsession-errors 2) Local GNU Debugger Select analyzer: _
export VISUAL = emacs
How would you like to report the problem? 1) Logger 2) Red Hat Customer Support Select reporter(s): _