[
https://issues.apache.org/jira/browse/HADOOP-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Shvachko updated HADOOP-2149:
----------------------------------------
Attachment: NNThroughput.patch
I included one more benchmark for file opens.
> Pure name-node benchmarks.
> --------------------------
>
> Key: HADOOP-2149
> URL: https://issues.apache.org/jira/browse/HADOOP-2149
> Project: Hadoop
> Issue Type: Improvement
> Components: dfs
> Affects Versions: 0.16.0
> Reporter: Konstantin Shvachko
> Assignee: Konstantin Shvachko
> Fix For: 0.16.0
>
> Attachments: NNThroughput.patch, NNThroughput.patch
>
>
> h3. Pure name-node benchmark.
> This patch starts a series of name-node benchmarks.
> The intention is to have a separate benchmark for every important name-node
> operation.
> The purpose of benchmarks is
> # to measure the throughput for each name-node operation, and
> # to evaluate changes in the name-node performance (gain or degradation) when
> optimization
> or new functionality patches are introduced.
> The benchmarks measure name-node throughput (ops per second) and the average
> execution time.
> The benchmark does not involve any other hadoop components except for the
> name-node.
> The name-node server is real, other components are simulated.
> There is no RPC overhead. Each operation is executed by calling directly the
> respective name-node method.
> The benchmark is multi-threaded, that is one can start multiple threads
> competing for the
> name-node resources by executing concurrently the same operation but with
> different data.
> See javadoc for more details.
> The patch contains implementation for two name-node operations: file creates
> and block reports.
> Implementation of other operations will follow.
> h3. File creation benchmark.
> I've ran two series of the file create benchmarks on the name-node with
> different number of threads.
> The first series is run on the regular name-node performing an edits log
> transaction on every create.
> The transaction includes a synch to the disk.
> In the second series the name-node is modified so that the synchs are turned
> off.
> Each run of the benchmark performs the same number 10,000 of creates equally
> distributed between
> running threads. I used a 4 core 2.8Ghz machine.
> The following two tables summarized the results. Time is in milliseconds.
> || threads || time (msec)\\with synch || ops/sec\\with synch ||
> | 1 | 13074 | 764 |
> | 2 | 8883 | 1125 |
> | 4 | 7319 | 1366 |
> | 10 | 7094 | 1409 |
> | 20 | 6785 | 1473 |
> | 40 | 6776 | 1475 |
> | 100 | 6899 | 1449 |
> | 200 | 7131 | 1402 |
> | 400 | 7084 | 1411 |
> | 1000 | 7181 | 1392 |
> || threads || time (msec)\\no synch || ops/sec\\no synch ||
> | 1 | 4559 | 2193 |
> | 2 | 4979 | 2008 |
> | 4 | 5617 | 1780 |
> | 10 | 5679 | 1760 |
> | 20 | 5550 | 1801 |
> | 40 | 5804 | 1722 |
> | 100 | 5871 | 1703 |
> | 200 | 6037 | 1656 |
> | 400 | 5855 | 1707 |
> | 1000 | 6069 | 1647 |
> The results show:
> # (Table 1) The new synchronization mechanism that batches synch calls from
> different threads works well.
> For one thread all synchs cause a real IO making it slow. The more threads is
> used the more synchs are
> batched resulting in better performance. The performance grows up to a
> certain point and then stabilizes
> at about 1450 ops/sec.
> # (Table 2) Operations that do not require disk IOs are constrained by memory
> locks.
> Without synchs the one-threaded execution is the fastest, because there are
> no waits.
> More threads start to intervene with each other and have to wait.
> Again the performance stabilizes at about 1700 ops/sec, and does not degrade
> further.
> # Our default 10 handlers per name-node is not the best choice neither for
> the io bound nor for the pure
> memory operations. We should increase the default to 20 handlers and on big
> classes 100 handlers
> or more can be used without loss of performance. In fact with more handlers
> more operations can be handled
> simultaneously, which prevents the name-node from dropping calls that are
> close to timeout.
> h3. Block report benchmark.
> In this benchmarks each thread pretends it is a data-node and calls
> blockReport() with the same blocks.
> All blocks are real, that is they were previously allocated by the name-node
> and assigned to the data-nodes.
> Some reports can contain fake blocks, and some can have missing blocks.
> Each block report consists of 10,000 blocks. The total number of reports sent
> is 1000.
> The reports are equally divided between the data-nodes so that each of them
> sends equal number of reports.
> Here is the table with the results.
> || data-nodes || time (msec) || ops/sec ||
> | 1 | 42234 | 24 |
> | 2 | 9412 | 106 |
> | 4 | 11465 | 87 |
> | 10 | 15632 | 64 |
> | 20 | 17623 | 57 |
> | 40 | 19563 | 51 |
> | 100 | 24315 | 41 |
> | 200 | 29789 | 34 |
> | 400 | 23636 | 42 |
> | 600 | 39682 | 26 |
> I did not have time to analyze this yet. So comments are welcome.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
