pfo.pfo@hydra(10:54)_44 just_read RA Read 48931556 of 48931556 bytes Tic-Tac.... ending 1570310 micro-seconds pfo.pfo@node2(10:54)_2 cd /data/pfo/ b0208.cat b0605.cat RA pfo.pfo@node2(10:54)_5 just_read RA Read 52407504 of 52407504 bytes Tic-Tac.... ending 133296 micro-seconds pfo.pfo@node2(10:57)_9 cd /home/data/USNOB1/dz0001/ pfo.pfo@node2(10:57)_11 just_read RA Read 52407504 of 52407504 bytes Tic-Tac.... ending 4546726 micro-secondsIf I/O were the only consideration, I would prefer DB2 to work on locally stored data in each node and not work on shared disks. Notice that the just_read command opens the file and reads its contents into an array. I've run these tests after hours of having accessed the files, so no memory should remain in the OS regarding these files (linux does buffer some files upon opening them, so that further I/O is much faster). The reason in our case seems to be that communication lines run from each node to the master and to the RAID, in a heavy application I would expect this situation to worsen. In summary, DB2 is capable of running in our cluster without much effort. Fine tuning the system to get it to perform as fast as possible may take extra effort and it could possibly imply modifying the interconection between the nodes, the master and the RAID. -- PatricioOrtiz - 31 Jan 2003
![]() |
Click here for the AstroGrid Service Web |
This is the AstroGrid Development Wiki |
|