diff options
author | hchiramm <hchiramm@redhat.com> | 2015-08-04 11:07:42 +0530 |
---|---|---|
committer | hchiramm <hchiramm@redhat.com> | 2015-08-04 11:07:42 +0530 |
commit | d7d3274c6f6cea46ad296fc6d1259ee9a4e9964f (patch) | |
tree | 8db500bcea5190101703ab2ebc4b28587a6e994c /Features/memory-usage.md | |
parent | 146b7ef7a31997634b29302a6e345ff5d9d7497a (diff) |
Adding Features and planning features to glusterfs-specs repo
As per the discussion (http://www.gluster.org/pipermail/gluster-users/2015-July/022918.html)
the specs are part of this repo.
Signed-off-by: hchiramm <hchiramm@redhat.com>
Diffstat (limited to 'Features/memory-usage.md')
-rw-r--r-- | Features/memory-usage.md | 49 |
1 files changed, 49 insertions, 0 deletions
diff --git a/Features/memory-usage.md b/Features/memory-usage.md new file mode 100644 index 0000000..4e1a8a0 --- /dev/null +++ b/Features/memory-usage.md @@ -0,0 +1,49 @@ +object expiry tracking memroy usage +==================================== + +Bitrot daemon tracks objects for expiry in a data structure known +as "timer-wheel" (after which the object is signed). It's a well +known data structure for tracking million of objects of expiry. +Let's see the memory usage involved when tracking 1 million +objects (per brick). + +Bitrot daemon uses "br_object" structure to hold information +needed for signing. An instance of this structure is allocated +for each object that needs to be signed. + + struct br_object { + xlator_t *this; + + br_child_t *child; + + void *data; + uuid_t gfid; + unsigned long signedversion; + + struct list_head list; + }; + +Timer-wheel requires an instance of the structure below per +object that needs to be tracked for expiry. + + struct gf_tw_timer_list { + void *data; + unsigned long expires; + + /** callback routine */ + void (*function)(struct gf_tw_timer_list *, void *, unsigned long); + + struct list_head entry; + }; + +Structure sizes: + +- sizeof (struct br_object): 64 bytes +- sizeof (struct gf_tw_timer_list): 40 bytes + +Together, these structures take up 104 bytes. To track all 1 million objects +at the same time, the amount of memory taken up would be: + +** 1,000,000 * 104 bytes: ~100MB** + +Not so bad, I think. |