Results 1 to 6 of 6
  1. #1

    SLM vs Burst RAM

    Could someone explain in layman's terms a point on RAM for VPS? I always understood that you are allocated an amount of RAM with each plan. For example, 256MB on most lower packages. You are then allowed to reach some limit in case their is some spike and memory is required. That is called Burst RAM limit/amount. Like 1GB. I asked about this to my new host and they responded below. I'm not following it.

    SLM is a method of using dedicated physical RAM (RSS) versus a guaranteed (unknown) / burst (VSIZE). SLM is only accounting physical memory usage and you are silently swapping on the host (the VSIZE) -- in short, if you are running out of RAM it is because your VPS is physically trying to use more than your dedicated RAM limit.

    SLM implements a 2nd-level out of memory (OOM) manager. In the event a VPS uses all of its physical RAM SLM will first delay the execution of processes to wait for more RAM to become available. After this it intelligently decides which processes to kill to maintain a running system.

    On the kernel level it decides itself what should be preempted to swap in the system and which data is most rarely used. This is more efficient from overall performance point of view than having a separate swap space assigned to each VPS and used when VPS has exceeded their RAM limit which cause disk I/O bandwidth which is used for swapping is a scare resource, therefore it is not worth swapping out something when there is global RAM available still.
    Cheers
    Carlos

  2. #2
    From Douglas, owner(?) of SolarVPS:

    Burstable RAM: If your VPS has bursting and requires additional resources, it will pull them from the available resource pool (this is a burst) and return them when they are no longer needed. So if you have a temporary spike, the resource pool will normally cover you.

    SLM based RAM: If your VPS has SLM Management, in the event your VPS uses all of its physical RAM SLM will automatically delay the execution of processes to wait for more RAM to become available. After this it intelligently decides which processes to kill to maintain a running system. Kind of like having a manager watching your processes 24 hours a day.

    On the kernel level it also decides what should be preempted to swap in the system and which data is most rarely used. This is more efficient from overall performance point of view.
    Source: http://www.solarvps.com/forums/index.php?topic=346.0.

    That's a pretty good explanation right there.
    478east
    High Bandwidth Servers
    Custom Hosting Solutions

  3. #3
    Good explanation, but I am worried about 'After this it intelligently decides which processes to kill to maintain a running system. '

    I mean, I wouldn't mind the mail process being killed, but what if it is httpd, mysql or php it decides to kill?
    Carlos

  4. #4
    Unfortunately that's the nature of the beast. If this bothers you then consider a VPS based on Xen/KVM technology which are more fully virtualized systems. This means that they will behave completely like a real Linux machine (each VPS runs it's own kernel after all) where memory is "real" and a typically large swap file is present instead of the somewhat mythical burst pool.

    Of course you can still run out of memory once RAM + swap are exhausted then Linux will apply standard OOM practices; but this is very rare and I think more indicative of either improperly selected server (simply not enough memory) or something went horribly horribly wrong

    But at the end of the day, no matter what technology you choose, endeavor to have enough guaranteed/SLM memory that you need and don't count on swap/burst memory in order to improve robustness and reliability!
    Exceptional VPS Hosting. With love, 6sync.

  5. #5
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    5,842
    In layman's terms: UBC is fuzzy.

    Depending on the setup and exactly how your processes use memory, you may be able to use more or less (sometimes considerably less) than your "guaranteed memory". So in fact the word "guarantee" is a complete misnomer. You also need the misnamed "burst" memory to be able to use more than a fraction of the "guaranteed". Under no circumstances will you be able to use all the burst memory.

    And that's the best case - only considering your usage. If the host has oversold the memory then you'll have many more problems.

    That's not to say that UBC is inherently bad. On a properly set up system it's perfectly ok - you'll get what you're paying for and probably a bit more. But you have to trust the provider to set it up right.

    SLM is much simpler - you only see (and you're only limited by) the memory your processes are actually using. On personal experience I'd prefer it to either OpenVZ/UBC or Xen for most purposes.
    Chris

    "Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them." - Laurence J. Peter

  6. #6
    Join Date
    Jan 2004
    Location
    Pennsylvania
    Posts
    939
    The whole "burst" ram thing is a lie pretty much. From the names of the values, the naming seems right but from a technical perspective it's just marketing speak. It's just been used for so long new providers just go ahead using it.

    Under OpenVZ the "guaranteed" ram setting, oomguarpages, is only ever touched if the entire hardware nodes RAM + swap is filled and the node itself hits an OOM situation. If it DOES happen, it means it will try to make sure the OOM-killer doesn't kill off more than the guaranteed amount from each VPS. The gimmick part of it is that if a nodes RAM + SWAP is filled it doesn't really matter, the nodes performance is already so horrible your VPS is already considered "down".

    The "burst" RAM is just a limit on your VSIZE. This is what OpenVZ fakes /proc/meminfo to show. VSIZE is a measurement of the allocated (not used) memory of a process.

    What SLM does is measure the actual memory used (the RSS/RESident) and account for that. I've seen on VPS's where the resident is 300MB and VSIZE is 1GB+, especially in the case of java processes.

    It's kind of difficult to market competitively against providers using the guaranteed/burst method because of how it works and the perceived notion that the actual words represent -- when the truth is, our "small" 360MB VPS can run more actual programs than a guaranteed/burst providers 1GB plan.

    Now on the OOM-killer mentioned. Under the "burst" method, when you hit your limit processes just start dying, most often the process you're trying to run. The SLM OOM-killer is smart, first it will try to delay execution to allow another process to end and maybe free up RAM, hence is the situation with many fast-forking processes. Next it has an internal database (provider assigned) of important processes and priorities, processes such as init, cron, xinetd, ssh, etc are high priority and will be the last to be killed off an OOM situation. Taking all of this into account it tries to make an intelligent decision about what processes to kill -- it's actually more advanced than the default Linux OOM-killer.

    For reference, here is the default SLM priority config:

    Code:
    "init"          00000018       -1        9
    "httpd"         0000001c       -1        2
    "httpsd"        0000001c       -1        2
    "lighthttpd"    0000001c       -1        2
    "mysqld"        0000001c       -1        3
    "syslogd"       00000018        0        8
    "sshd"          00000018        0        8
    "inetd"         00000018        0        8
    "xinetd"        00000018        0        8
    "cron"          00000018        0        8
    "crond"         00000018        0        8
    ""              00000004        9        0
    ""              00000004        8        1
    ""              00000004        1        0
    Matt Ayres - togglebox.com
    Linux and Windows Cloud Virtual Datacenters powered by Onapp / Xen
    Instant Setup, Instant Scalability, Full Lifecycle Hosting Solutions

    www.togglebox.com

Similar Threads

  1. burst down ?
    By illimited.or in forum Colocation and Data Centers
    Replies: 5
    Last Post: 03-14-2008, 04:14 PM
  2. Replies: 12
    Last Post: 10-16-2007, 12:40 AM
  3. Replies: 24
    Last Post: 01-06-2006, 10:13 AM
  4. How fast does your burst.net server BURST
    By clocker1996 in forum Dedicated Server
    Replies: 12
    Last Post: 12-12-2001, 07:33 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •