COMPETENCIA COMUNICATIVA

As already mentioned in 6.1.3, “Communication and message flow” on page 113, the secondary SDS node will apply all changes extracted from the logical log files until the current LSN is moved from the primary server to the buffer pool. Any dirty buffers will not be written to disk, since this can only be done by the primary server. In case of a parallel workload on the secondary server with connected user sessions, it is possible that a dirtied page has to be flushed out by a LRU_MAX_DIRTY event or by a foreground write. In such a case, the buffer will be written to a file referred to as a page file. Two page files have to be specified for secondary SDS servers in your file system with the ONCONFIG parameter SDS_PAGING. At startup time on the SDS secondary, the database server will check to see if the files exist. If they do not, they will be automatically created. The intention of the page files is to keep the flushed dirty buffers for the case that they need to be used again during the actual checkpoint period, either from the application of the logs or from read requests for existing user sessions. Two files also must be specified to support the non-blocking checkpoints feature. At the beginning of the checkpoint, the current page file will be swapped with the non-current file. After the swap, all flushed new dirty files will be written to the new page file. The content of the old file will not be reset until the checkpoint is finished. This is to make sure that in the non-blocking phase of the checkpoint where the primary SDS database server writes out all the pages to disk, the secondary node is able to provide the latest version to potential readers. After the checkpoint is finished on the primary server, the secondary will receive a special log entry and remove all the dirty buffer flags in the buffer pool that were dirtied in the last checkpoint interval. After that, the write position in the old page file will be reset to position 0. The size of the page file will not shrink.

While setting up the location of the page file, the DBA has to keep in mind that the page file size will most likely grow over the secondary SDS servers’ uptime. The reset of a swapped page file as described above does not really mean that the file size will be reset to 0, but only that the current offset will be reset to 0. That means that depending on the workload and the buffer pool settings, the page file sizes can be larger.

Be aware that having a large page file does not need to be considered as an I/O bottleneck in case of heavy page in and page out activities of dirty buffers. The server does not sequentially read the page file to determine the requested page. Instead, each page written to the page file will be stored in a server maintained hash table with the additional information about the offset. In the case of a read, the hash table will read and the offset is determined. After that, the read will be requested.

If the optimization goal is to minimize the page file utilization to achieve disk space use reduction, you should configure the buffer pool size appropriately. Look at peak use times for the particular server and try to find the optimal value for the amount of buffer.

You can keep track utilization and size of the page files by running onstat -g sds on a SDS secondary. To give you an idea of how the output looks, refer to Example 6-4.

Example 6-4 onstat -g sds verbose

informix@Linux:/vobs/IDS11/sds11_prim> onstat -g sds verbose

IBM Informix Dynamic Server Version 11.10.UC1 -- Read-Only (SDS) -- Up 01:00:25 -- 42140 Kbytes

SDS server control block: 0x10a5f588 Local server type: SDS

Server Status : Active

Source server name: sds_prim_11 Connection status: Connected

Last log page received(log id,page): 9,298 Next log page to read(log id,page):9,299 Last LSN acked (log id,pos):9,1220864 Sequence number of last buffer received: 0 Sequence number of last buffer acked: 0 Current paging file:/files/sds11_sec1/pagefile Current paging file size:6144

Old paging file:/files/sds11_sec1/pagefile1 Old paging file size:0

Another way to monitor the utilization based on the I/O for the particular page files is to run onstat -g iof. Example 6-5 shows a sample output. Please look at the statistics for the files named pagefile and pagefile1.

Example 6-5 onstat -g iof on a secondary SDS server

informix@Linux:/vobs/IDS11/sds11_prim> onstat -g iof

IBM Informix Dynamic Server Version 11.10.UC1 -- Read-Only (SDS) -- Up 01:06:11 -- 42140 Kbytes

AIO global files:

gfd pathname bytes read page reads bytes write page writes io/s 3 ./chunk_prim 165888 81 0 0 68435.3

op type count avg. time seeks 0 N/A

writes 0 N/A kaio_reads 0 N/A kaio_writes 0 N/A

4 pagefile 2048 1 1058816 517 3465.1

op type count avg. time seeks 0 N/A reads 1 0.0000 writes 21 0.0003 kaio_reads 0 N/A kaio_writes 0 N/A 5 pagefile1 0 0 1050624 513 3756.1

op type count avg. time seeks 0 N/A reads 0 N/A writes 17 0.0003 kaio_reads 0 N/A kaio_writes 0 N/A