Home » International » Russian » Настройка параметров памяти для ВПС
| Настройка параметров памяти для ВПС [message #634] |
Fri, 30 December 2005 19:43  |
 |
knutov
Messages: 79
Registered: December 2005
Location: Perm, Russia
|
Member |
|
|
Есть некоторая тестовая впс. На ней поднято много всего тестового, в частности есть ява, которая любит кушать память. Скажем, условно, она хочет 512 метров. В реальности ей надо, условно, 50 метров, а остальное [практически] не используется и можно спокойно загнать в свап.
После прочтения документации я так и не понял, как задать параметры свапа.
куски из /proc/user_beancounters тестовой впс.
kmemsize 1231902 2170686 2457600 2621440 0
privvmpages 62405 65536 65536 65536 36
shmpages 14 1950 8192 8192 0
physpages 8711 52670 0 2147483647 0
vmguarpages 0 0 6144 2147483647 0
oomguarpages 8711 52670 6144 2147483647 0
При создании впс я сделал privvmpages равным 256 метров, остальное оставил как оно было по умолчанию.
По тестам (например мусклем), внутри впс можно получить до 256 метров памяти. После этого память не дается.
Итак, я хочу
1) чтобы при наличии свободной памяти на ноде, память давалась впс (что изменить, чтобы это было так?)
2) чтобы если памяти не хватало, память внутри впс могла уходить в свап (что для этого сделать? Сейчас этого не происходит)
3) хочу ограничить размер свапа, который может использовать впс.
Подскажите пожалуйста, как это сделать?
Еще вопрос - какой параметр всё-таки отвечает за минимальное количество памяти, которое гарантированно будет дано ВПС? Я было подумал, что vmguarpages, но очень смущает то, что судя по статистике, оно не испольуется (первые два столбца по нулям).
|
|
|
|
| Re: Настройка параметров памяти для ВПС [message #753 is a reply to message #634] |
Mon, 09 January 2006 08:27  |
|
|
| Quote: |
Я было подумал, что vmguarpages, но очень смущает то, что судя по статистике, оно не испольуется (первые два столбца по нулям).
|
vmguarpages - это гарантия. она не аккаунтится, поэтому там и нули.
Most parameters provide both accounting of some system resource and allow controlling its consumption. The exceptions are physpages (accounting only) and vmguarpages (no accounting, control only).
Далее, вот подробное описание трёх параметров, которые вам нужны. К сожалению, на английском. Максимальный размер использованного свопа для VPS ограничен его privvmpages.
vmguarpages: memory allocation guarantee.
This parameter controls how much memory is available to the Virtual Private Server (i.e. how much memory its applications can allocate by malloc(3) or other standard Linux memory allocation mechanisms). The more clients are served or the more "heavy" the application is, the more memory it needs.
The amount of memory that Virtual Private Server's applications are guaranteed to be able to allocate is specified as the barrier of vmguarpages parameter. The current amount of allocated memory space is accounted into privvmpages parameter, and vmguarpages parameter does not have its own accounting. The barrier and the limit of privvmpages parameter impose an upper limit on the memory allocations. The meaning of the limit for the vmguarpages parameter is unspecified in the current version and should be set to the maximal allowed value (2147483647).
If the current amount of allocated memory space does not exceed the guaranteed amount (the barrier of vmguarpages), memory allocations of Virtual Private Server's applications always succeed. If the current amount of allocated memory space exceeds the guarantee but below the barrier of privvmpages, allocations may or may not succeed, depending on the total amount of available memory in the system.
Starting from the barrier of privvmpages, normal priority allocations and, starting from the limit of privvmpages, all memory allocations made by the applications fail.
The memory allocation guarantee (vmguarpages) is a primary tool for controlling the memory available to Virtual Private Servers, because it allows administrators to provide Service Level Agreements -- agreements guaranteeing certain quality of service, certain amount of resources and general availability of the service. The unit of measurement of vmguarpages values is memory pages (4KB) on 32-bit Intel-family processes).
The total memory allocation guarantees given to Virtual Private Servers are limited by the physical resources of the computer -- the size of RAM and the swap space.
privvmpages: memory allocation limit.
Privvmpages parameter allows controlling the amount of memory al located by applications.
The barrier and the limit of privvmpages parameter control the upper boundary of the total size of allocated memory. Note that this upper boundary doesn't guarantee that the Virtual Private Server will be able to allocate that much memory, neither does it guarantee that other Virtual Private Servers will be able to allocate their fair share of memory. The primary mechanism to control memory allocation is the vmguarpages guarantee.
Privvmpages parameter accounts allocated (but, possibly, not used yet) memory. The accounted value is an estimation how much memory will be really consumed when the Virtual Private Server's applications start to use the allocated memory. Consumed memory is accounted into oomguarpages parameter.
Since the memory accounted into privvmpages may not be actually used, the sum of current privvmpages values for all Virtual Private Servers may exceed the RAM and swap size of the computer.
There should be a safety gap between the barrier and the limit
for privvmpages parameter to reduce the number of memory alloca tion failures that the application is unable to handle. This gap will be used for "high-priority" memory allocations, such as process stack expansion. Normal priority allocations will fail when the barrier if privvmpages is reached.
Total privvmpages should match the physical resources of the computer. Also, it is important not to allow any Virtual Private Server to allocate a significant portion of all system RAM to avoid serious service level degradation for other VPSs.
Kir Kolyshkin
|
|
|
|
|
|
Goto Forum:
Current Time: Thu Oct 03 22:21:06 GMT 2024
Total time taken to generate the page: 0.05437 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
