TESING INFORMIX RESTORES WITH ONBAR

Steps to find where the slow-down is (backup):
  1. Reduce the restore process to managable size which still exposes the throughput problem. Use the same dbspace set the you used in the backup tests
  2. Ideally you would want to initally test restoring BAR_MAX_BACKUP number of dbspaces.
  3. Time an initial restore to act as a baseline for future timings. When performing these timings be sure to time only the physical restore (not the logical resore). We are only working on data transfer throughput at this point. Use the BAR_ACT_LOG to find the time at which physical restore began and ended.
  4. Using the Disk Writer program we will measure the speed in which the OS can write the disk(s) associated with the dbspace which is being tested. Remember to use the same block size that informix uses (8 * BUFFSIZE).
  5. Using the XBSAReader Utility, Measure how fast the storage manager can send data to ON-Bar through the XBSA interface.
Run each of the 3 tests a few times so you can gain an average time. Your results should look like the following:

	REGULAR restore			XBSAReader
	tabdbs1	tabdbs2	tabdbs3		tabdbs1	tabdbs2	tabdbs3
Time#1	85	87	85		84	88	91	
Time#2	85	86	85		84	88	88
Time#3	91	92	92		91	84	85

	DISKWriter		
	tabdbs1	tabdbs2	tabdbs3		
Time#1	42	42	42	
Time#2	42	42	42	
Time#3	42	42	42
From the results above (taken from a sample test) you can see that the bottleneck lies in the Storage manager. The Storage manager can only send ON-Bar data at a rate of approximately 87 secs per dbspace. While the OS can write data to the chunks at a rate of 42 secs per dbspace. Informix's speed is usually with in 10-15% of the Diskwriter speeds (assuming you are restoring an archive which was taken while the engine was under very low usage).

If we had found that the XBSAreader was as fast as the diskreader and the regular restore time were the same then we would conclude that the Informix/ON-Bar peice is the bottleneck.

If we found that the average time for the diskreader was (lets say) 150 secs per dbspace and so was the resgular restore time, Then we would conclude that the bottleneck lies with the disk I/O system.

Hosted by www.Geocities.ws

1