next up previous
Next: Experiences Up: Cause-Effect Analysis of Parallel Previous: Protocol Analysis

Transaction Analysis

 

A parallel file system provides transparent access to data that is striped across multiple disk servers. Given that a single file operation can involve multiple servers in parallel, the file system must use some form of concurrency control to maintain consistency. The PIOUS file system [9], in which every file operation is a transaction, uses strict two-phase locking to ensure sequential consistency. When an application process issues a file operation, messages requesting the operation are sent to the appropriate disk servers, which perform the operation (when possible) and return a result. The results are collected from all the disk servers and, assuming all of them indicate successful completion of the operation, a commit message is sent to each participating disk server; otherwise, an abort message is sent. Commit messages cause the disk servers to make the changes permanent, while abort messages restore the previous state, after which the operation is typically tried again. Since aborts and retries are very expensive, they can easily become a major source of performance degradation.

Transaction analysis is a cause-effect analysis technique that identifies the causes of transaction retries in PIOUS. Although the proximate cause of a transaction retry is the abort that terminated the previous attempt, we want to understand why the abort occurred. Transactions may be aborted for one of two reasons: one of the servers in the transaction was too busy to respond within the timeout interval or a server could not give exclusive access to data to the transaction because the data was in use by another active transaction. Server contention may be alleviated by an alternative file layout scheme, while data access conflicts may be alleviated by changing the access granularity used by the application.

Transaction analysis only considers events related to file system operations. In analyzing a particular abort, we ignore any events from transactions that completed before the aborted transaction was initiated, and also ignore events that occurred on servers which did not abort the transaction. For each transaction that aborts, there is a set of servers who failed to commit. The explanation for the abort is the set of active transactions on those servers. Since transaction events in the trace file include information about the file range they access, we can distinguish between transactions that conflict for data and transactions that simply contend for the server.

We can combine explanations for aborts within a file, source code line, and application. In order to combine two explanations, they must be composed of transactions that access the same file and that were issued by the same application within the same basic block. Furthermore, the number of failed commits should be the same for the two transactions.

In our visualization (see figure 4) a transaction is represented by a table of potentially conflicting transactions. Each row in the table corresponds to a source of conflicting transactions (application, files, and basic block); each column represents a server. The entry may be light colored (no conflict), shaded (data access conflict), or dark (server contention).


next up previous
Next: Experiences Up: Cause-Effect Analysis of Parallel Previous: Protocol Analysis

Wagner Meira
Thu Jan 9 14:27:55 EST 1997