FAQ
I've got an application I'm working on that's essentially a database with
strongly-typed, variable-length pages. I'd like to guarantee that the app
won't take up move than X amount of memory, e.g. 3/4 of main memory. In a
system with generic pages of well-known lengths, this is super easy:
Allocate n buffers of size page_length, if no buffer is free use some
strategy (LRU, for instance) to find one to overwrite.

When your buffers are of variable length, this gets more complicated. When
your buffers are actually strongly typed (e.g. the buffer has
variable-length fields), that makes it more complicated. And then when your
language has GC, it seems to me it'd be even *more* complicated--you can't
explicitly deallocate and/or don't have a lot of control over how you use
memory.

Has anyone worked on anything in golang like this? It's totally possible
I'm just thinking about the problem the wrong way, too. Anyone have
tips/ideas?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nick Craig-Wood at Apr 23, 2014 at 4:29 pm

    On 22/04/14 20:21, Brad Heller wrote:
    I've got an application I'm working on that's essentially a database
    with strongly-typed, variable-length pages. I'd like to guarantee that
    the app won't take up move than X amount of memory, e.g. 3/4 of main
    memory.
    If all you care about is a guarantee that the app won't use more than x
    ram, then I'd use ulimits, or LXC or Docker.


    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Evan Huus at Apr 24, 2014 at 9:44 pm

    On Tuesday, April 22, 2014 3:21:07 PM UTC-4, Brad Heller wrote:
    I've got an application I'm working on that's essentially a database with
    strongly-typed, variable-length pages. I'd like to guarantee that the app
    won't take up move than X amount of memory, e.g. 3/4 of main memory. In a
    system with generic pages of well-known lengths, this is super easy:
    Allocate n buffers of size page_length, if no buffer is free use some
    strategy (LRU, for instance) to find one to overwrite.

    When your buffers are of variable length, this gets more complicated. When
    your buffers are actually strongly typed (e.g. the buffer has
    variable-length fields), that makes it more complicated. And then when your
    language has GC, it seems to me it'd be even *more* complicated--you can't
    explicitly deallocate and/or don't have a lot of control over how you use
    memory.

    Has anyone worked on anything in golang like this? It's totally possible
    I'm just thinking about the problem the wrong way, too. Anyone have
    tips/ideas?
    I've thought about something similar before, and the best I've been able to
    come up with is regularly polling the OS to check the memory usage of the
    current process. Not a great solution, I know.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jeff R. Allen at Apr 25, 2014 at 12:51 pm
    If you:
      - control the allocation of these items
      - control the structure and implementation of them

    then you can keep track of current space in use due to them and when you
    need to allocate more, you can go back and steal space from existing items.
    Actually, you should ask them to give up the space themselves, so that they
    know they no longer have it, and can act accordingly, i.e. regenerate this
    apparently disposable data later.

    Here is an example: http://play.golang.org/p/4Unv7M4DdY

    Making this example threadsafe is left as an exercise to the reader. Unless
    you really want me to do it, in which case just ask and I'll show you how.
    :)

       -jeff

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 22, '14 at 7:21p
activeApr 25, '14 at 12:51p
posts4
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase