Performance Analysis and Optimization of the Hurricane File System ...

More documents

Recommendations

Info

CHAPTER 7. MACROBENCHMARK 71 For simplicity, the K42 padding facilities were used rather than manually padding and aligning the data structures. Performance was similar between 1 to 4 processors for the unoptimized and optimized versions of HFS. Beyond 4 processors, the unoptimized version exhibited extremely poor scalability. Although scalability was much better in the optimized version, it was not ideal. In the unoptimized version, there appeared to be a correlation between the number of hash lists in the block cache system (4) and the resulting knee of the curve (at approximately 4 processors). A brief experiment was conducted using the unoptimized version augmented with 32 rather than 4 hash lists in the block cache system. Results for 8 processors (not shown) did not have any performance improvement, signifying that scalability could not be achieved by simply increasing the size of the hash tables in the unoptimized version. Due to the nature of the Web server workload, many files are accessed by each thread (one thread per processor), causing their associated meta-data to be scattered randomly and uniformly across all hash lists in the ORS cache. In contrast, the microbenchmark read test consisted of each thread accessing only one file, and hence utilizing approximately two hash lists per thread in the ORS cache. The scattered hash list usage caused by the Web server workload led to a greater number of hash collisions between threads. In addition, as the number of processors, and hence threads, were increased, the number of hash collisions increased further. The macrobenchmark enabled us to examine the impact of the hash function on a more realistic workload. It highlighted the inadequacies of the hash function in the ORS cache. 7.3.2 Optimizations A modified hash function in the ORS cache was implemented along with a larger hash table. The new hash function assigns an exclusive group of hash lists to each disk and an offset within the group depending on the physical file number that is embedded in the file token of the request. The number of hash lists per group was set to 64. Under a general workload, this scheme eliminates any chance of hash collisions from requests targetted at different disks. However, if two requests are targetted to the same disk, there is the possibility of a collision, but the probability is reduced since there are 64 available hash lists. The distribution within a hash list group should be fairly uniform because a simple modulo function is applied to the physical file number of a request to determine the target hash list, which is equivalent to taking the 6 lower-order bits of the file number. The logical organization and physical implementation of the new hashing scheme is shown in Figure 7.2. Although logically organized into 2 levels, it is physically implemented in one level. For simplicity, we statically sized the ORS hash table to the maximum configuration of 12 processors and 12 disks. Ideally, the size of the hash table should scale accordingly to the size of the multiprocessor, as implied by Peacock et al. [56, p. 86]. Calculating the target hash list involves simple bit shifting, masking, and assembly.
CHAPTER 7. MACROBENCHMARK 72 Logical Organization of Hash Table for ORS 0 0 1 63 1 11 0 1 63 0 1 63 Physical Implentation of Hash Table for ORS 0 1 file # 63 0 1 file # 63 0 1 file # 63 0 1 63 disk # file# modulo 64 64n+0 64n+1 disk #0 disk #n disk #11 Constructing Hash Index Value for ORS global hash index value = 7 6 5 4 3 disk # 2 1 0 64n+63 9 17 start here 8 7 6 5 4 3 global index 2 6 file# (embedded in file token) Figure 7.2: Modified ORS hash function. 1 5 0 4 3 2 1 0 703 704 767 In the microbenchmarks, the modified hash function in the block cache system simply assigned one hash list to each disk. However, on the Web server workload, this hash function had a detrimental effect on performance because the number of entries in each hash list was fairly large since many files were accessed. For each request, after hashing to a particular hash list, a linear search through an extremely long hash list was necessary, leading to poor absolute performance. To solve this problem, hash function modifications and a larger hash table were applied to the block cache system as well. For the block cache system, the new hash function assigns an exclusive group of hash lists to each disk and an offset within the group depending on the physical file number and logical file block number, as with the ORS cache hash table. The number of hash lists per group was set to 256. Within each group of hash lists, 16 subgroups were designated for physical file number indexing. Finally, each subgroup contained 16 hash lists that were indexed by file block number. The logical organization and physical implementation of the new hashing scheme is shown in Figure 7.3. Once again for simplicity, we statically sized the block cache hash table to the maximum configuration of
Page 1 and 2:
Performance Analysis and Optimizati
Page 3 and 4:
Acknowledgements This thesis has be
Page 5 and 6:
4.6 Measurements Taken and Graph In
Page 7 and 8:
List of Tables 3.1 File system inte
Page 9 and 10:
6.1 Create. . . . . . . . . . . . .
Page 11 and 12:
CHAPTER 1. INTRODUCTION AND MOTIVAT
Page 13 and 14:
CHAPTER 1. INTRODUCTION AND MOTIVAT
Page 15 and 16:
CHAPTER 2. BACKGROUND AND RELATED W
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Chapter 3 HFS Architecture This cha
Page 25 and 26:
CHAPTER 3. HFS ARCHITECTURE 16 3.1.
Page 27 and 28:
CHAPTER 3. HFS ARCHITECTURE 18 ORS
Page 29 and 30: CHAPTER 3. HFS ARCHITECTURE 20 dirt
Page 31 and 32: CHAPTER 3. HFS ARCHITECTURE 22 dire
Page 33 and 34: CHAPTER 3. HFS ARCHITECTURE 24 1. 2
Page 35 and 36: CHAPTER 3. HFS ARCHITECTURE 26 curr
Page 37 and 38: CHAPTER 4. EXPERIMENTAL SETUP 28 1
Page 39 and 40: CHAPTER 4. EXPERIMENTAL SETUP 30 de
Page 41 and 42: CHAPTER 4. EXPERIMENTAL SETUP 32 av
Page 43 and 44: Chapter 5 Microbenchmarks - Read Op
Page 45 and 46: CHAPTER 5. MICROBENCHMARKS - READ O
Page 61 and 62: Chapter 6 Microbenchmarks - Other F
Page 63 and 64: CHAPTER 6. MICROBENCHMARKS - OTHER
Page 75 and 76: Chapter 7 Macrobenchmark 7.1 Purpos
Page 77 and 78: CHAPTER 7. MACROBENCHMARK 68 server
Page 79: CHAPTER 7. MACROBENCHMARK 70 avg #
Page 83 and 84: CHAPTER 7. MACROBENCHMARK 74 avg #
Page 85 and 86: CHAPTER 7. MACROBENCHMARK 76 avg #
Page 87 and 88: CHAPTER 7. MACROBENCHMARK 78 7.5 Ot
Page 89 and 90: CHAPTER 7. MACROBENCHMARK 80 to deq
Page 91 and 92: CHAPTER 8. CONCLUSIONS 82 8.1 Gener
Page 93 and 94: CHAPTER 8. CONCLUSIONS 84 read-only
Page 95 and 96: Bibliography [1] Gene M. Amdahl. Va
Page 97 and 98: BIBLIOGRAPHY 88 [33] David Kotz, So
Page 99: BIBLIOGRAPHY 90 [71] Keith A. Smith
show all

Performance Analysis and Optimization of the Hurricane File System ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?