Hi! I've been doing a lot of research on this..and are more confused than ever. vzsplit is basically useless..so I feel the time has come to ask for help here..since I've already searched on this..and came up basically empty. Ok..I already have the basics..per the UBC config table. I just am having problems figuring the metrics of kmemsize. The bad thing is..nobody will really want example A or B..most want at least 64MB RAM..if not 96MB RAM. That leaves me with one metric "C" and little understanding how to reduce or increase kmemsize. I'm not terribly worried about other resources...I have that solved. So..if we consider: Example "C"-248MB RAM --kmemsize 16384000:18022400 What would: "A"-62MB RAM --kmemsize ? "B"-124MB RAM --Kmemsize ? and a monster: Example "D" -496MB RAM --Kmemsize ? If I have an idea how to scale the numbers..I can go from there. Thanks! Bryon
Re: Help with calculating fair allocations
Hello, you wrote: Quote: So..if we consider: Example "C"-248MB RAM --kmemsize 16384000:18022400 What would: "A"-62MB RAM --kmemsize ? "B"-124MB RAM --Kmemsize ? and a monster: Example "D" -496MB RAM --Kmemsize ? kmemsize parameter is measured in bytes, as all parameters, which name is terminated by ...size. So if you want to set kmemsize limit to 248MB, limit/barrier should equal 248 * 1024 * 1024 = 260046848. I suppose you'll be able to calculate appropriate numbers for 62/124/496MB. Also, I would like to add, that kmemsize is not RAM. To get full information on user beancountes (UBC) visit this page and read detailed information about all parameters: http://wiki.openvz.org/UBC. Sorry, if I misunderstood you. HTH, vass.
Hi! No..you are correct. However..one more thing remains. Can I just half the recommendations..for each..and double the numbers for double the RAM: vmguarpages: 102,400 = 248MB RAM 51,200 = 124MB RAM 204,800 = 496MB RAM Would that work..or not? I'm still confused..because I can't figure a basis formula. That does..at least get me close to the recommendations- Doing that would give me 6400 vmguarpages for a 16KRAM VPS..which is darn close to the example..6144 vmguarpages. Do you agree this would be sound? Thanks Bryon
You wrote: Quote: vmguarpages: 102,400 = 248MB RAM 51,200 = 124MB RAM 204,800 = 496MB RAM You're not right. All parameters, which name is terminated by ...pages are measured in pages. On IA32 platforms page size equals 4Kb. So if you set vmguarpages limit to 102400, it means: (102400 * 4) / 1024 = 400Mb. In the same manner you can calculate other values. HTH, Vasily.
Hi! Ok..that makes sense. However...that example came from here: http://wiki.openvz.org/UBC_configuration_examples_table If I'm wrong..they're wrong too! vmguarpages = total memory, right? In the example..that's 248MB. privvmpages = user memory... which the example has at 262144:292912. I don't mean to make extra work for you..but...many hosts don't have a clue either. Thanks! Bryon
Bryan, I suggest you to read all the wiki pages about UBCs, dedicating at least a couple of hours for this task. Those pages do have something to say. Especially, please read the description of individual parameters, also wiki: UBC systemwide configuration, and generally all the other UBC-related articles. vmguarpages is NOT RAM limit. It is a _guarantee_ for allocations. privvmpages is NOT RAM limit. It is a limit of how many pages a VE can _allocate_ (using, say, malloc()), but not yet use -- as it often happens. The thing is, pages are allocated by applications, but not all of them are used, and in Linux (and any other modern OS), allocation does not yet leads to a page allocated in RAM. In fact, page in RAM is allocated later, when it's used for the first time, and _only_ if it's used. Also, some pages are swapped out. Again, please read all those articles first, and ask your questions only after you read and undestood that stuff. Regards, Kir.