You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Henry Robinson (JIRA)" <ji...@apache.org> on 2012/05/29 21:59:22 UTC
[jira] [Created] (ZOOKEEPER-1473) Committed proposal log retains
triple the memory it needs to
Henry Robinson created ZOOKEEPER-1473:
-----------------------------------------
Summary: Committed proposal log retains triple the memory it needs to
Key: ZOOKEEPER-1473
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1473
Project: ZooKeeper
Issue Type: Bug
Reporter: Henry Robinson
ZKDatabase.committedLog retains the past 500 transactions to enable fast catch-up. This works great, but it's using triple the memory it needs to by retaining three copies of the data part of any transaction.
* The first is in {{committedLog[i].request.request.hb}} - a heap-allocated {{ByteBuffer}}.
* The second is in {{committedLog[i].request.txn.data}} - a jute-serialised record of the transaction
* The third is in {{committedLog[i].packet.data}} - also jute-serialised, seemingly uninitialised data.
This means that a ZK-server could be using 1G of memory more than it should be in the worst case. We should use just one copy of the data, even if we really have to refer to it 3 times.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1473) Committed proposal log retains
triple the memory it needs to
Posted by "Henry Robinson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henry Robinson updated ZOOKEEPER-1473:
--------------------------------------
Description:
ZKDatabase.committedLog retains the past 500 transactions to enable fast catch-up. This works great, but it's using triple the memory it needs to by retaining three copies of the data part of any transaction.
* The first is in committedLog[i].request.request.hb - a heap-allocated {{ByteBuffer}}.
* The second is in committedLog[i].request.txn.data - a jute-serialised record of the transaction
* The third is in committedLog[i].packet.data - also jute-serialised, seemingly uninitialised data.
This means that a ZK-server could be using 1G of memory more than it should be in the worst case. We should use just one copy of the data, even if we really have to refer to it 3 times.
was:
ZKDatabase.committedLog retains the past 500 transactions to enable fast catch-up. This works great, but it's using triple the memory it needs to by retaining three copies of the data part of any transaction.
* The first is in {{committedLog[i].request.request.hb}} - a heap-allocated {{ByteBuffer}}.
* The second is in {{committedLog[i].request.txn.data}} - a jute-serialised record of the transaction
* The third is in {{committedLog[i].packet.data}} - also jute-serialised, seemingly uninitialised data.
This means that a ZK-server could be using 1G of memory more than it should be in the worst case. We should use just one copy of the data, even if we really have to refer to it 3 times.
> Committed proposal log retains triple the memory it needs to
> ------------------------------------------------------------
>
> Key: ZOOKEEPER-1473
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1473
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Henry Robinson
>
> ZKDatabase.committedLog retains the past 500 transactions to enable fast catch-up. This works great, but it's using triple the memory it needs to by retaining three copies of the data part of any transaction.
> * The first is in committedLog[i].request.request.hb - a heap-allocated {{ByteBuffer}}.
> * The second is in committedLog[i].request.txn.data - a jute-serialised record of the transaction
> * The third is in committedLog[i].packet.data - also jute-serialised, seemingly uninitialised data.
> This means that a ZK-server could be using 1G of memory more than it should be in the worst case. We should use just one copy of the data, even if we really have to refer to it 3 times.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira