This section helps you to tune your system in order to increase system performances.
Available on Artica v.1.6.061621 or above.
The Linux kernel is flexible, and you can even modify the way it works on the fly by dynamically changing some of its parameters.
Click on System information on the tob toolbar
Click on "Kernel informations" icon.
- Select Parameters tab.
- You will see some values in "red". It's means that Artica suggest to change the value for best performances.
- If you did not want to setup a sepcific value, just empty the field.
- You have to reboot after saveing the form.
Available values are :
Sets the value of each page’s zone to min, low, or high, depending on themachine.
Default is 724.
For a small machine use 128 KB; for largemachines, use the maximum 4096 KB.
Example: For a machine with more than 8GByte RAM you can easily spare 128MByte (which would translate into a sysctl value of 131072, as it has to be given in kByte).
This variable controls the tendency of the kernel to reclaim the memory which is used for caching of VFS caches, versus pagecache and swap.
Increasing this value increases the rate at which VFS caches are reclaimed.
It is difficult to know when this should be changed, other than by experimentation.
The slabtop command (part of the package procps) shows top memory objects used by the kernel.
The vfs caches are the "dentry" and the "*_inode_cache" objects.
If these are consuming a large amount of memory in relation to pagecache, it may be worth trying to increase pressure.
Could also help to reduce swapping. The default value is 100.
Percentage of memory that is allowed for overcommit.
Default is 50.
It represents the percentage of physical RAM that along with the entire swap forms the total address space (allocatable memory).
Yes, the naming is confusing, since there is no overcommitting.
The default is 50 so, quite unintuitively, only half of the RAM will be used.
Seeing that the swap is the only component that can change dynamically it would have made sense to specify a percentage for that.
Anyway, there are 2 ways to ensure that the allocatable memory will be equal to the RAM size:
1. make the swap the same size as the RAM and set vm.overcommit_ratio=0 - that will work as long as the swap is in use, but as soon as a swapoff is done (manually or during shutdown), you`re in for a nasty surprise: no more memory can be allocated.
At all! New programs will fail to start.
2. Set vm.overcommit_ratio=100 and disable the swap.
This is a stable setup and the preferred method on a machine with enough RAM.
Web servers are slowed down anyway by swapping and careful planning will help ensuring that the memory usage limits won`t be reached (by setting cache sizes, maximum number of processes, etc.).
Processes commonly allocate memory by calling the function malloc().
The kernel decides if enough RAM is available and either grants or denies the allocation request.
Linux (and a few other Unix-variants) support the ability to over-commit memory; that is, to permit more memory to be allocated than is available in physical RAM plus swap.
This is scary, but sometime necessary since applications commonly allocate memory for "worst case" scenarios but never use it.
Determines how likely the VM subsystem is to swap to disk.
Default is 60 and typically is sufficient.
Valid values are 0 to 100.
Enable kernel detection and handling of any process that causes a crashand calls the panic() function at the end.
The kernel.panic parameter must also be set to 1. Default is 1 (enable).
The maximum number and size of semaphore sets that can be allocated
The maximum size in bytes of a shared memory segment
The maximum size of a shared memory segment on a Linux system
The maximum number of shared memory segments