x_cons <database_name> show io
Displays the number of read and write operations per volume as well as the number of 8 KB page reads. These numbers are independent of whether the I/O is synchronous or asynchronous.
- Devspace : Name of the media which the thread is currently accessing.
- Devs. No. : Id of the devspace
- Read Count : Read count
- Read Pages : Number of pages read
- Write Count : Write count
- Write Pages : Number of pages written
In MaxDB 7.6, several data volumes and log volumes can be configured. For each data volume, several worker threads exist and each worker thread has its own request queue protected by spinlock. The number of queues for a volume can be configured using database parameter, _IOPROCS_PER_DEV. For log volumes, even though there can be multiple log voumes, logging is serialized so only one is active at a time.
In MaxDB 7.7, volume job queues are separated from worker threads and operate without spinlocks. By implementing lock-free mechanism, the scalability problem that could be caused by lock based operation can be avoided. Instead of assigning a fixed number of worker threads to each volume, there is a worker pool with a special FIFO queue which manages tickets that trigger actual operations in I/O. When I/O is done, the worker thread goes back to the pool. By having a pool of worker threads instead of assigning worker threads to each volume, MaxDB can configure any number of queues per volume without using many resources. If one volume is heavily used, large number of workers can be allocated for that volume since workers are shared by all volumes. Therefore, you do not have to split a data volume to several small volumes to achieve good parallelism. Also, the new I/O mechanism allows asynchronous operations for tasks for log writing and data cache handling and better job priority handling.