Raymond Raymond wrote:
I ran a variant of the TPC-B benchmark with a large database (20 GB)
and a large page cache (1 GB). I do not think you need TPC-B
transactions to see this, but I think you need update-intensive
transactions that frequently needs to load pages from disk. For
example, single record updates where an index is used to locate the
record. You will also need several connections in parallel (e.g., 20).
--
Øystein
Thanks for your answer. Did you use some tools to know something like
"single write operations that took almost 12 seconds" and "read requests
that took more than 20 seconds". I downloaded TPC-B benchmark program,
it didn't give me those kind of information. I want to know how did you
know the time for reads and writes.^_^.
No special tools. Our TPCB-client writes the number of committed
transaction for each 10 second interval. That way, I observed regular
drops in throughput. I/O response times was measured by instrumenting
RAFContainer to measure the time it takes to do seek and read/write.
This was written to derby.log and inspected manually. (See attached
diff from RAFContainer.readPage for an example)
--
Øystein Grøvlen, Senior Staff Engineer
Sun Microsystems, Database Technology Group
Trondheim, Norway
+ long startTime = System.currentTimeMillis();
+ SanityManager.DEBUG_PRINT("RAFContainer",
+ startTime + " " + Thread.currentThread()
+ + ": Read: " + getIdentity()
+ + ", page=" + pageNumber);
synchronized (this) {
+ long waitTime = System.currentTimeMillis();
+ SanityManager.DEBUG_PRINT("RAFContainer",
+ waitTime + " " + Thread.currentThread()
+ + ": Wait finished: " + getIdentity()
+ + ", waitTime=" + (waitTime-startTime));
+
fileData.seek(pageOffset);
fileData.readFully(pageData, 0, pageSize);
+
+ long stopTime = System.currentTimeMillis();
+ SanityManager.DEBUG_PRINT("RAFContainer",
+ stopTime + " " + Thread.currentThread()
+ + ": Read completed:" + getIdentity() +
": "
+ + (stopTime-waitTime) + " msec.");
}
