zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrico Olivelli (Jira)" <j...@apache.org>
Subject [jira] [Updated] (ZOOKEEPER-1473) Committed proposal log retains triple the memory it needs to
Date Fri, 06 Sep 2019 15:45:07 GMT

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Enrico Olivelli updated ZOOKEEPER-1473:
---------------------------------------
    Fix Version/s:     (was: 3.5.6)

> 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
>          Components: server
>            Reporter: Henry Robinson
>            Assignee: Thawan Kooburat
>            Priority: Major
>             Fix For: 3.6.0, 3.5.7
>
>         Attachments: ZOOKEEPER-1473.patch, ZOOKEEPER-1473.patch, ZOOKEEPER-1473.patch
>
>
> 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 was sent by Atlassian Jira
(v8.3.2#803003)

Mime
View raw message