vania-janet/multiturn-rag-retrieval-data huggingface dataset:
10iops-tier 10 IOPS/GB 3,000 - 48,000 1024 MB/s 10 GB - 4,800 GB 256 KB 
 custom 1 - 100 IOPS/GB 3,000 - 48,000 1024 MB/s 10 GB - 16,800 GB 256 KB 



Moving volumes across volume-profiles that belong to different families is not allowed.



 IOPS tiers 

When you create your storage volume, you can select from three predefined IOPS tiers. Choose the profile that provides optimal performance for your compute workloads. Table 2 describes the IOPS performance that you can expect for each tier.



Table 2. IOPS tier profiles and performance levels for each tier

 Name Purpose IOPS rate Capacity range (GB) Min IOPS Max IOPS Blocksize 

 general-purpose Workloads that host small databases for web applications or store virtual machine disk images for a hypervisor. 3 IOPS/GB 10 - 16,000 3,000 - 48,000 16 KB 
 5iops-tier High I/O intensity workloads - Workloads characterized by a large percentage of active data, such as transactional and other performance-sensitive databases. 5 IOPS/GB 10 - 9,600 3,000 - 48,000 16 KB 
 10iops-tier Demanding storage workloads - Data intensive workloads created by NoSQL databases, data processing for video, machine learning, and analytics. Bandwidth limits are calculated by using a 256 KB block size. 10 IOPS/GB 10 - 4,800 3000 - 48,000 256 KB 



Max IOPS for all tiers starts at 3,000 IOPS. Max IOPS then increases, based on the storage tier and volume size, up to the Max IOPS in Table 2.





 Custom IOPS profiles 

Custom IOPS is a good option when you have well-defined performance requirements that do not fall within a predefined IOPS tier. You can customize the IOPS by specifying the total IOPS for the volume within the range for its volume size. You can provision volumes with IOPS performance from 100 IOPS to 48,000 IOPS, based on volume size.

Table 2 shows the available IOPS ranges based on volume capacity for the custom profile.
The maximum amount of memory available to your deployment.



Table 16. Max allowed memory for an instance metric metadata

 Metadata Description 

 Metric Name ibm_databases-for-enterprisedb_memory_limit_bytes 
 Metric Type gauge 
 Value Type byte 
 Segment By Service instance 







 Read replica replication lag 

How far behind a PostgreSQL read-only replica is, in bytes.



Table 17. Read replica replication lag metric metadata

 Metadata Description 

 Metric Name ibm_databases-for-enterprisedb_read_replica_replication_lag_bytes 
 Metric Type gauge 
 Value Type count 
 Segment By Service instance 







 Successful archive rate 

Successful archive rate



Table 18: Successful archive rate metric metadata

 Metadata Description 

 Metric Name ibm_databases_for_enterprisedb_successful_archive_rate 
 Metric Type gauge 
 Value Type rate 
 Segment By Service instance 







 Temporary files size in bytes 

Temporary files size in bytes



Table 19: Temporary files size in bytes metric metadata

 Metadata Description 

 Metric Name ibm_databases_for_enterprisedb_temp_bytes_count 
 Metric Type gauge 
 Value Type none 
 Segment By Service instance 







 The total number of PostgreSQL connections in use 

The total number of PostgreSQL connections in use.



Table 20. The total number of PostgreSQL connections in use metric metadata

 Metadata Description 

 Metric Name ibm_databases-for-enterprisedb_total_connections 
 Metric Type gauge 
 Value Type count 
 Segment By Service instance 







 Total disk space for an instance 

Represents the total amount of disk available to your deployment.



Table 21. Total disk space for an instance metric metadata

 Metadata Description 

 Metric Name ibm_databases-for-enterprisedb_disk_total_bytes 
 Metric Type gauge 
 Value Type byte 
 Segment By Service instance 







 Transaction commit count 

Transaction commit count



Table 22: Transaction commit count metric metadata

 Metadata Description 

 Metric Name ibm_databases_for_enterprisedb_transaction_commit_count 
 Metric Type gauge 
 Value Type none 
 Segment By Service instance 







 Transaction commit rate 

Transaction commit rate



Table 23: Transaction commit rate metric metadata
I/O size (minimum/optimal): 512 bytes / 65536 bytes
Disklabel type: dos
Disk identifier: 0x92c0322a

Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-2097151, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-2097151, default 2097151):

Created a new partition 1 of type 'Linux' and of size 1023 MiB.

Command (m for help): w
The partition table has been altered.
Show more
2. Create the file system.

$ sudo mkfs.ext4 /dev/mapper/mpatha-part1
mke2fs 1.45.5 (07-Jan-2020)
Creating filesystem with 261888 4k blocks and 65536 inodes
Filesystem UUID: cdb70b1e-c47c-47fd-9c4a-03db6f038988
Superblock backups stored on blocks:
32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
3. Mount the block device.

sudo mount /dev/mapper/mpatha-part1 /mnt
4. Access the data to confirm that the new partition and file system are ready for use.

ls /mnt
A minimum transaction size, one that contains no endorsements, is around 1KB. If you add 1KB per required endorsement, a typical transaction size is approximately 3-4KB. Therefore, it is recommended to set the value of Preferred max bytes to be around Max message count * expected averaged tx size. At run time, whenever possible, blocks will not exceed this size. If a transaction arrives that causes the block to exceed this size, the block is cut and a new block is created for that transaction. But if a transaction arrives that exceeds this value without exceeding the Absolute max bytes, the transaction will be included. If a block arrives that is larger than Preferred max bytes, then it will only contain a single transaction, and that transaction size can be no larger than Absolute max bytes.



Together, these parameters can be configured to optimize throughput of your orderer.





 Batch timeout 

Set the Timeout value to the amount of time, in seconds, to wait after the first transaction arrives before cutting the block. If you set this value too low, you risk preventing the batches from filling to your preferred size. Setting this value too high can cause the orderer to wait for blocks and overall performance to degrade. In general, we recommend that you set the value of Batch timeout to be at least max message count / maximum transactions per second.

When you modify these parameters, you do not affect the behavior of existing channels on the orderer; rather, any changes you make to the orderer configuration apply only to new channels you create on this orderer.





 Other performance considerations 

In addition to the previous topics, the following considerations can help optimize your network performance:



* Ensure persistent storage IOPS is not a bottleneck. Persistent storage IO requests can become a bottleneck in some solutions. 10 IOPS/GB+ is recommended.
* Performance generally scales with CPU allocated to peer nodes. Providing each peer and CouchDB (if used) with the maximum CPU capacity is recommended.
* Use Fabric 2.x so chaincode runs as a separate process.
* Increasing the ordering node sendBufferSize default of 10 can improve ordering service performance (100 is the recommended starting point).
app-concurrency The maximum number of requests that can be processed concurrently per instance. The default value is 100. 
 app-deployment-timeout The amount of time, in seconds, that can pass before the build must succeed or fail. 
 app-health-endpoint The app health endpoint; for example, /health. 
 app-max-scale The maximum number of instances that can be used for this application. If you set this value to 0, the application scales as needed. The application scaling is limited only by the instances per the resource quota for the project of your application. See [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits). The default value is 10. 
 app-min-scale The minimum number of instances that can be used for this application. This option is useful to ensure that no instances are running when not needed. This value is optional. The default value is 0. 
 app-name The name of the application. Use a name that is unique within the project. 
 app-port The port where the application listens for incoming connections. The format is [NAME:]PORT, where [NAME:] is optional. If [NAME:] is specified, valid values are h2c or http1. By default, Code Engine assumes apps listen for incoming connections on port 8080. 
 app-visibility The visibility for the application. Valid values are public, private, and project. Setting a visibility of public means that your app can receive requests from the public internet or from components within the Code Engine project. See [Options for visibility for a Code Engine application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsoptionsvisibility). 
 branch The branch in the repository that contains the buildpacks file or the Dockerfile. The default value is main. 
 build-size The size for the build, which determines the amount of resources used. Valid values are small, medium, large, xlarge.
NAME: nvidia-devicequery-ppkd4
Namespace: default
...
Limits:
nvidia.com/gpu: 1
Requests:
nvidia.com/gpu: 1
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 1m default-scheduler Successfully assigned nvidia-devicequery-ppkd4 to 10.xxx.xx.xxx
...



5. To verify that the job used the GPU to compute its workload, you can check the logs.

kubectl logs nvidia-devicequery-ppkd4

Example output

/cuda-samples/sample Starting...

CUDA Device Query (Runtime API) version (CUDART static linking)

Detected 1 CUDA Capable device(s)

Device 0: "Tesla P100-PCIE-16GB"
CUDA Driver Version / Runtime Version 11.4 / 11.7
CUDA Capability Major/Minor version number: 6.0
Total amount of global memory: 16281 MBytes (17071734784 bytes)
(056) Multiprocessors, (064) CUDA Cores/MP: 3584 CUDA Cores
GPU Max Clock rate: 1329 MHz (1.33 GHz)
Memory Clock rate: 715 Mhz
Memory Bus Width: 4096-bit
L2 Cache Size: 4194304 bytes
Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384)
Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers
Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 49152 bytes
Running your Connector agent as a service in Docker Swarm Mode for high availability 

In addition to running the container standalone as shown in the previous example, you can use Docker Swarm mode to run a cluster of up to 3 containers on multiple machines to provide high availability of the Satellite Connector agent.

To configure Satellite Connectors, you must have Administrator access to the Satellite service in IAM access policies.



1. Create a Satellite Connector agent compose file called satellite-connector-agent.yaml on your Swarm manager system and copy the following content to it:

version: '3.9'
services:
agent:
image: icr.io/ibm/satellite-connector/satellite-connector-agent:latest
environment:
- SATELLITE_CONNECTOR_ID=/satellite-connector-id
- SATELLITE_CONNECTOR_REGION=/satellite-connector-region
- SATELLITE_CONNECTOR_IAM_APIKEY=/run/secrets/satellite-connector-iam-apikey
- SATELLITE_CONNECTOR_TAGS={{.Node.Hostname}}
deploy:
replicas: 3
restart_policy:
condition: any
update_config:
parallelism: 2
delay: 20s
failure_action: rollback
order: start-first
resources:
limits:
cpus: '0.40'
memory: 500M
reservations:
cpus: '0.04'
memory: 200M
configs:
- source: satellite-connector-id
uid: '1000'
gid: '1000'
mode: 0400
- source: satellite-connector-region
uid: '1000'
gid: '1000'
mode: 0400
secrets:
- source: satellite-connector-iam-apikey
uid: '1000'
gid: '1000'
mode: 0400
logging:
driver: "json-file"
options:
max-size: ${JSON_FILE_MAX_SIZE:-1m}
max-file: ${JSON_FILE_MAX_FILE:-10}
For more information, see [MySQL innodb_flush_log_at_trx_commit documentation](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.htmlsysvar_innodb_flush_log_at_trx_commit).





 innodb_log_buffer_size 



* Description: The size in bytes of the buffer that InnoDB uses to write to the log files on disk.
* Default setting: 32 MiB
* Max: 4294967295
* Min: 1048576
* Requires restart: True



For more information, see [MySQL innodb_log_buffer_size documentation](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.htmlsysvar_innodb_flush_log_at_trx_commit).





 innodb_log_file_size 



* Description: InnoDB log file size in bytes.
* Default setting: 64 MB
* Max: 274877906900
* Min: 4194304
* Requires restart: True



For more information, see [MySQL innodb_log_file_size documentation](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.htmlsysvar_innodb_log_file_size).





 innodb_lru_scan_depth 



* Description: A parameter that influences the algorithms and heuristics for the flush operation for the InnoDB buffer pool.
* Default setting: 1024
* Max: no max value
* Min: 100
* Requires restart: True



For more information, see [MySQL innodb_lru_scan_depth documentation](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.htmlsysvar_innodb_lru_scan_depth).
For more information, see [Modifying a Linux OS for expanding boot volumes](https://cloud.ibm.com/docs/vpc?topic=vpc-modifying-the-linux-os-expanded-boot-volume).







 Requirements 



 Data volume requirements 

You must meet the following requirements to increase a data volume's capacity.



* The volume is expanded based on their predefined IOPS profile or custom IOPS range.
* The volume must be attached to a virtual server instance.
* The volume must be in an available state.
* The instance must be powered on and in a running state.
* To realize maximum [volume bandwidth](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-bandwidth), you must detach and reattach the volume from the instance.







 Boot volume requirements 

You must meet these requirements to resize a boot volume:



* When an instance is provisioned, the size of the boot volume can be larger than the existing image size but not smaller. The maximum boot volume size is 250 GB.
* For an existing instance, you can increase the size of the boot volume up to the maximum size that was allowed during instance provisioning.
* Encrypted boot volumes have no special requirements.
* Supported operating systems are x86 and Linux.









 Limitations 

Limitations for resizing boot and data volumes apply in this release.



 Data volume limitations 



* You cannot expand a volume that is at its maximum capacity for its [IOPS tier profile](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profilestiers-beta) or [Custom](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profilescustom) volume range.
* Data volumes can expand to 16,000 GB, with the following limitations:
If an error message is found, excluding INFO messages, increase the memory resource by using the following command:

oc patch wd wd --type=merge --patch='{"spec":{"elasticsearch":{"dataNode":{"maxHeap":"6g","resources":{"limits":{"memory":"10Gi"},"requests":{"memory":"8Gi"}}}}}}'
18. After you run this command, the Elasticsearch client pod is restarted about 20 minutes later. Monitor the "AGE" of the pod by using the following command:

oc get pod -l tenant=wd,ibm-es-data=True,ibm-es-master=False
19. After the pod is restarted successfully, check the new value of ES_JAVA_OPTS and the container memory requests/limit by using the following command:

oc describe $(oc get po -l tenant=wd,ibm-es-data=True,ibm-es-master=False -o name)

For both nodes (client and data), set the resources.limits.memory equal to 2 * maxHeap.

If the pod cannot be restarted after 30 mins by applying the oc patch command, collect logs to share with IBM Support by using the following command:

oc logs -l control-plane=ibm-es-controller-manager --tail=-1



For both issues, where document status cannot be promoted to Processing and where documents are stuck in Processing status, if you are using Portworx storage, you can check whether the Elasticsearch disk is full.



1. Run the following command to check whether the Elasticsearch disk is full:

oc logs -l tenant=wd,run=elastic,ibm-es-master=True -c elasticsearch --tail=100000|grep 'disk watermark'
2. If the log shows a message such as watermark exceeded on x-data-1, it means the disk on the node that is specified is full and you need to increase the disk size by using the following command:
kind: IBPConsole
metadata:
name: ibpconsole
namespace: your-project
labels:
app.kubernetes.io/name: "ibp"
app.kubernetes.io/instance: "ibp"
app.kubernetes.io/managed-by: "ibm-ibp"
spec:
email: <EMAIL>
password: <PASSWORD>
imagePullSecrets:
- regcred
registryURL: cp.icr.io/cp
license:
accept: <ACCEPT>
networkinfo:
domain: <DOMAIN>
storage:
console:
class: default
size: 5Gi
serviceAccountName: ibm-blockchain
usetags: true
version: 2.5.4
clusterdata:
zones:
resources:
console:
requests:
cpu: 500m
memory: 1000Mi
limits:
cpu: 500m
memory: 1000Mi
configtxlator:
limits:
cpu: 25m
memory: 50Mi
requests:
cpu: 25m
memory: 50Mi
couchdb:
limits:
cpu: 500m
memory: 1000Mi
requests:
cpu: 500m
memory: 1000Mi
deployer:
limits:
cpu: 100m
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
Show more



* You can use the resources: section to allocate more resources to your console. The values in the example file are the default values allocated to each container. Allocating more resources to your console allows you to operate a larger number of nodes or channels.
* If you plan to use the console with a multizone Kubernetes cluster, you need to add the zones to the clusterdata.zones: section of the file. When zones are provided to the deployment, you can select the zone that a node is deployed to using the console or the APIs.
Then use the POST /v1/environments/{environment_id}/collections/{collection_id}/documents method to add documents to your collection.







 Crawling URLs 

You can crawl URLs and index them using the Web Crawl connector. See [Connecting to data sources](https://cloud.ibm.com/docs/discovery?topic=discovery-sourcesconnectwebcrawl).





 Troubleshooting ingestion issues 

Learn about steps you can take to mitigate issues that you might encounter when you are adding documents.



* Microsoft Office document is too large

If a document is large or complex, the step in the ingestion process that extracts the document structure can take too long to complete. If a message is displayed that indicates that a document is too large for content structure extraction to occur, decrease the size of the document. To decrease the document size, you can split the document into many smaller documents. For example, if you are adding an Excel spreadsheet, split a large XLXS file by sheets or rows into several smaller XLXS files. For a DOC file, split the document by pages. How small should each chunk of the document be? There is no one size that is best for all documents; it depends on the document. Aim to make each chunk as small as possible, while keeping plan-based document limits in mind.
Throughput is expressed as the number of bytes per second that can be both sent and received in a service instance.

Throughput capacity cannot be scaled down. To move to a lower throughput capacity, requires creating a new Event Streams service instance at the lower capacity unit.

The following figures are not verified. They are guidelines only.

The recommended maximum figure is based on a typical workload and considers the possible impact of operational actions such as internal updates or failure modes, like the loss of an availability zone. If the average throughput exceeds the recommended figure, a loss in performance might be experienced during these conditions. It is recommended to plan your maximum throughput capacity as two-thirds of the peak maximum. For example, two-thirds of the 150 MB/s peak maximum with one capacity unit are 100 MB/s.





 Partitions 

The maximum number of partitions is related to the number of capacity units, so 3000 for 150 MB/s in Satellite.

It is a hard limit for the Satellite plan. If you reach this limit, you can no longer create topics.





 Retention 

You must implement mechanisms to back up your data to meet your retention requirements.





 Schema Registry 

The Schema Registry is not supported on the Satellite plan.





 Other limits 



* Maximum message size: 1 MB
* Maximum concurrently active Kafka clients: 10000
Launch [Access (IAM) Overview](https://cloud.ibm.com/iam/overview).
2. Select Manage > Account > Resource Groups > Create resource group.
3. Create a resource group; for example, CodeEngine_servicebindings_resourcegroup.



2. Create the service instances that you want to bind to in the same resource group. For this example, create an IBM Cloudant service instance in the CodeEngine_servicebindings_resource group resource group.
3. [Create an IAM access group](https://cloud.ibm.com/docs/account?topic=account-groups&interface=ui) for users who create Code Engine service bindings.



1. Launch [Access (IAM) Overview](https://cloud.ibm.com/iam/overview).
2. Select Manage > Access(IAM) > Access groups.
3. Create a group; for example, CodeEngine_servicebindings_accessgroup.
4. From within this new access group, click the Access tab and assign the following access policy for the Code Engine service.



* For Service, select Code Engine.
* For Resources, select the specific resource group that you created in the previous step; for example, CodeEngine_servicebindings_resourcegroup.
* For Resource group access, select Viewer.
* For Roles and actions, select Service access of Writer and Platform access of Operator.
* Click Add to add the access policy to this access group.



5. Click Assign to assign the access policies to this access group.
6. Create the service instances that you want to bind to in the same resource group. For this example, create an IBM Cloudant service instance in the CodeEngine_servicebindings_resource group resource group.



4. Add the my-user user to this access group.
5. Create a service ID for the service instance that you want to bind to.



1. Launch [Access (IAM) Overview](https://cloud.ibm.com/iam/overview).
2.
For more information, see [Managing access](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-managing-access-for-cloudant) or legacy [authentication](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-work-with-your-accountauthentication) and [authorization](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-work-with-your-accountauthorization) documentation.

Using the form, define the source and target databases, then click Start Replication.

The status of each replication task can be seen by clicking Replication. Each job changes state from Running to Completed as it progresses. The following screen capture shows the Completed state.

Zoom

![Under the State field in the table, you see Completed.](https://cloud.ibm.com/docs-content/v1/content/522c6f62358b063f921283400a601c3f9bc66f08/Cloudant/images/replication_guide_4.png)

Figure 3. Completed state





 How to replicate across different IBM Cloudant accounts 

The source and target of a replication are URLs of IBM Cloudant databases, as shown in the following example.

See the following example that defines source and target URLs for replication:

{
"source": "https://myfirstaccount.cloudant.com/a",
"target": "https://mysecondaccount.cloudant.com/b"
}

The source and target do not need to be on the same account. The source and target database names do not need to match. You must be authorized to access both the source and target, and you must be authorized to write to the target.





 Is replication run on the source or the destination? 

Replication can be started at either the source or the destination end.