Results 1 to 7 of 7
  1. #1

    Real memory allocation in OpenVZ

    Got an OpenVZ VPS at 1G/2G memory spec. "free" shows 1.8G memory used, pretty impressive, but it's awfully slow. "top" shows only 1.6G/300M in VIRT/RES for java (running tomcat app). Guess they only guaranteed <400M, not 1G.

    Is this how most OpenVZ VPS is for your guys? Guess how they make money by oversubscribing

  2. #2
    Join Date
    Feb 2010
    Location
    Lisbon, Portugal
    Posts
    1,184
    Can you post the output of the command "free -m" here?

    I guess maybe your VPS has vswap enabled and you are looking at the wrong place to see your RAm amount,or you can also have guaranteed RAM/Burstable RAM.
    Best Regards / Melhores Cumprimentos,
    Bernardo Andrade
    Need a system Administrator?Contact me at email@bernardoa.pt
    Visit me at www.bernardoa.pt

  3. #3
    How to check guaranteed/burstable?

    {code}
    total used free shared buffers cached
    Mem: 2048 1856 191 0 0 0
    -/+ buffers/cache: 1856 191
    Swap: 0 0 0
    {/code}

  4. #4
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    5,849
    It's nothing to do with what's "guaranteed". In OpenVZ (pre-vswap) the only real limit is burst / allocated memory and Java, left to itself, allocates way too much. Search for other threads on this topic - it's a common problem whenever OpenVZ and Java meet.

    Edit: To see real memory usage / limits / fails
    Code:
    cat /proc/user_beancounters
    Last edited by foobic; 02-18-2012 at 12:20 AM.
    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

  5. #5
    Chris, thanks for comments. Somehow, a simple search shows most of people don't believe OpenVZ itself would have any impact to java performance, as long as memory is concerned. It is more about oversubscription. For example, http://www.webhostingtalk.com/showth...highlight=java

    Anyway, here is user_beancounters

    Code:
    Version: 2.5
           uid  resource                     held              maxheld              barrier                limit              failcnt
          776:  kmemsize                  7828103              8428110           2147483646           2147483646                    0
                lockedpages                     0                    0               999999               999999                    0
                privvmpages                474903               521307               524288               524288                    0
                shmpages                      671                 1007               262400               262400                    0
                dummy                           0                    0                    0                    0                    0
                numproc                        93                  104               999999               999999                    0
                physpages                  108119               275083                    0           2147483647                    0
                vmguarpages                     0                    0               262400           2147483647                    0
                oomguarpages               285730               322981               262400           2147483647                    0
                numtcpsock                     19                   40              7999992              7999992                    0
                numflock                        9                   10               999999               999999                    0
                numpty                          1                    1               500000               500000                    0
                numsiginfo                      0                    3               999999               999999                    0
                tcpsndbuf                  346912              1234816            214748160            396774400                    0
                tcprcvbuf                  327960              1626352            214748160            396774400                    0
                othersockbuf                 9312                26872            214748160            396774400                    0
                dgramrcvbuf                     0                16944            214748160            396774400                    0
                numothersock                   16                   37              7999992              7999992                    0
                dcachesize                      0                    0           2147483646           2147483646                    0
                numfile                      2221                 2353             23999976             23999976                    0
                dummy                           0                    0                    0                    0                    0
                dummy                           0                    0                    0                    0                    0
                dummy                           0                    0                    0                    0                    0
                numiptent                      24                   24               999999               999999                    0

  6. #6
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    5,849
    Quote Originally Posted by xkey View Post
    Chris, thanks for comments. Somehow, a simple search shows most of people don't believe OpenVZ itself would have any impact to java performance, as long as memory is concerned. It is more about oversubscription. For example, http://www.webhostingtalk.com/showth...highlight=java
    Try searching on "java openvz xmx", since using the option "-xMx 128M" (or whatever amount of memory you think it can run in), is the usual way to tame Java's hungry memory-allocation habits.

    At least your beancounters shows you're not yet hitting any of the limits, although you're close on privvmpages (burst), inevitably.
    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

  7. #7
    Sure, vms, vmx and MaxPermSize are all set. This is just to prevent tomcat from being prematurely terminated in VPS environment. It not necessarily improve the performance.

    the privvmpages are very misleading. The OpenVZ VPS instance was given a Virtual Memory size of 2G (which is burstable), however, the physical memory it has access to really show up in "RES" field of top, I think.

    The performance is really bad when RES is low, all other VIRT memory might have been swapped to disk, esp the tomcat has been actively used within last few hours due to LRU algorithm. If tomcat being used actively, the RES slowly grows if lucky (have to steal mem from other VPS), and performance starts to get a little better.

    My experience strongly tells me that the actual physical memory it has access to can be really indicated by "RES" field of top command.

Similar Threads

  1. Memory Allocation in VPS
    By mommaroodles in forum VPS Hosting
    Replies: 5
    Last Post: 11-14-2011, 03:56 PM
  2. Memory Allocation Issue
    By tetrahost in forum Hosting Security and Technology
    Replies: 2
    Last Post: 10-09-2011, 08:10 AM
  3. memory allocation problems
    By bryonhost1 in forum Hosting Security and Technology
    Replies: 2
    Last Post: 12-26-2007, 01:53 PM
  4. Check Memory Allocation
    By evangelia in forum VPS Hosting
    Replies: 7
    Last Post: 04-29-2007, 09:16 PM
  5. memory allocation errors
    By Whoa in forum VPS Hosting
    Replies: 6
    Last Post: 01-10-2007, 06:00 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
  •