News in one line: now clients can change the MOD parameters from the control panel.

A long time ago, in our mod-server, the ability to control memory allocation parameters was implemented. This was implemented at the level of the server itself and the parameters of the database.

... But this was not in the web interface. The most persistent customers asked to change the settings - and we changed them manually. Stupid right
')
Finally, we fixed the situation - the MOD-server settings were made available to clients. Most of them are applied on the go and do not require a restart or suspension of service.

Memory-on-Demand working principle

Depending on the number of running programs, a different amount of memory is required. Since the memory is paid in "gigabyte hours" (in fact, in kilobyte-nanoseconds), then it is a pity to spend extra money on unused memory. But to huddle in a small amount, getting into a swap is also not good.

The whole MOD system consists of three components: a server, a database (settings) and agents.

The agent - modd (mod daemon) is running inside the guest machine, it writes to the xenstore (a system through which the guest system can interact with the manager in the dom0 without using the network) information about the current state of the memory. More precisely, it simply writes data from / proc / meminfo to the xenstore in data / mod_meminfo.

The server looks at these numbers and decides whether to add more memory or reduce it. MOD-server operation algorithm (in general): the amount of free memory is considered (we correctly take into account buffers and cached), if it is more than necessary, then the memory is reduced. If less than needed, then increase.

Parameters that control the operation of the MOD

MOD has the following parameters:

• hard memory limits - the absolute minimum and maximum. These limits define the limits within which a change in the amount of memory is possible. The presence of these boundaries is a technical limitation of the hypervisor we use (Xen 3.4). The recommended minimum-to-maximum ratio is about 1 to 4, maximum 1 to 8. (For extreme values ​​like 128MB - 48GB, you can easily get the kernel panic due to the fact that the kernel does not have enough own memory to service the theoretical limit). These limits are not MOD parameters - we combined them into one page simply because taking them to a separate place would increase confusion.
• Galka "on" / "off", it just turns off (includes) MOD. If MOD is turned off, the memory is fixed at the last value set and no longer changes.
• "Soft limits" of memory. These limits determine the extent to which regulate memory. Note that these are not exactly “limits”; rather, this is a wish for the size of the memory. If these numbers are set too small, then xen will ignore them, if they are set too large, similarly.
• Borders free memory. This is the most interesting pair of numbers - it determines how much free memory should be in a virtual machine. More precisely, like a soft limit, it indicates which value the MOD server should strive for.
  These values ​​can not be equal to zero (if you have 0 free memory, then either you go to the swap, or the kernel falls). They also cannot be equal to each other - this has a very rather specific explanation - if the limits were equal to each other, then self-triggered oscillations could occur (let's say we lack 8kb. Algorithm: add 16kb, remove 16kb, add 16kb, remove 16kb ...). Since when a memory is returned to the hypervisor, the guest machine cleans the memory (it would be strange to give the memory along with its contents), this operation is not completely free for the client. Single add / remove memory occupy insignificant resources; however, if the memory began to twitch back and forth constantly, it would create a parasitic load. The default values ​​- minimum - 96MB, maximum 192MB. For the Mini pattern, the values ​​are 24 and 32Mb, respectively.

If the field is written zero (or nothing is written), then the default values ​​are used.

Exceptions

List of applications for which MOD is not needed. If the application is primary on the server, the memory limits can be set the same and do not torture the server in vain:

• JRE, JEEE, Tomcat and other Java-based - java uses its own memory allocation mechanism
• MongoDB - reads memory settings at startup, does not check and does not handle memory allocation errors

PS Previous topic on this topic: habrahabr.ru/company/selectel/blog/99157