Jump to content

# Improving performance

From ArchWiki

Related articles

- /Boot process
- Pacman/Tips and tricks#Performance
- OpenSSH#Speeding up SSH
- Openoffice#Speed up OpenOffice
- Laptop
- Preload

This article provides information on basic system diagnostics relating to performance as well as steps that may be taken to reduce resource consumption or to otherwise optimize the system with the end-goal being either perceived or documented improvements to a system's performance. See also Gaming#Improving performance for additional gaming and low latency specific advice.

## The basics

### Know your system

The best way to tune a system is to target bottlenecks, or subsystems which limit overall speed. The system specifications can help identify them.

- If the computer becomes slow when large applications (such as LibreOffice and Firefox) run at the same time, check if the amount of RAM is sufficient. Use the following command, and check the "available" column:

      $ free -h

- If boot time is slow, and applications take a long time to load at first launch (only), then the hard drive is likely to blame. The speed of a hard drive can be measured with the `hdparm` command:

      # hdparm -t /dev/sdX

  Note hdparm indicates only the pure read speed of a hard drive, and is not a valid benchmark. A value higher than 40MB/s (while idle) is however acceptable on an average system.
- If CPU load is consistently high even with enough RAM available, then try to lower CPU usage by disabling running daemons and/or processes. This can be monitored in several ways, for example with htop, `pstree` or any other system monitoring tool:

      $ htop

- If applications using direct rendering are slow (i.e those which use the GPU, such as video players, games, or even a window manager), then improving GPU performance should help. The first step is to verify if direct rendering is actually enabled. This is indicated by the `glxinfo` command, part of the mesa-utils package, which should return `direct rendering: Yes` when used:

      $ glxinfo | grep "direct rendering"

- When running a desktop environment, disabling (unused) visual desktop effects may reduce GPU usage. Use a more lightweight environment or create a custom environment if the current does not meet the hardware and/or personal requirements.
- Using an optimized kernel improves performance. Generally, linux-zen is a good option. However, the default kernel can be tweaked as shown in certain parts of this article to perform better.

### Benchmarking

The effects of optimization are often difficult to judge. They can however be measured by benchmarking tools.

## Storage devices

### Sector size

Check that your NVMe drives and Advanced Format hard disk drives are using the optimal logical sector size.

### Partitioning

Make sure that your partitions are properly aligned.

#### Multiple drives

If you have multiple disks available, you can set them up as a software RAID for serious speed improvements.

Creating swap on a separate disk can also help quite a bit, especially if your machine swaps frequently.

##### An SSD as a cache for an HDD

When forgoing hard disk drives is not an option, a solid state drive can be added as a caching layer to improve the read and/or write speeds and reduce the noise from random access. The options to accomplish this include LVM#Cache, Bcache and Bcachefs#SSD caching.

#### Layout on HDDs

If using a traditional spinning HDD, your partition layout can influence the system's performance. Sectors at the beginning of the drive (closer to the outside of the disk) are faster than those at the end. Also, a smaller partition requires less movements from the drive's head, and so speed up disk operations. Therefore, it is advised to create a small partition (15-20GiB, more or less depending on your needs) only for your system, as near to the beginning of the drive as possible. Other data (pictures, videos) should be kept on a separate partition, and this is usually achieved by separating the home directory (`/home`) from the system (`/`).

Note As with all advice on this page, measure what benefits are provided: unless short stroking the hard drive and using only a few percent of its total capacity, separating partitions will improve access time by only a few percent since the read/write operations will still be spread over the whole drive in general use. Comparatively, upgrading to an SSD will improve performance by more than an order of magnitude.

### Choosing and tuning your filesystem

Choosing the best filesystem for a specific system is very important because each has its own strengths. The File systems article provides a short summary of the most popular ones. You can also find relevant articles in Category:File systems.

#### Mount options

The various *atime options can mitigate the performance penalty of `strictatime`.

Other mount options are filesystem specific, therefore see the relevant articles for the filesystems:

- Ext3
- Ext4#Improving performance
- JFS#Optimizations
- XFS#Performance
- Btrfs#Defragmentation, Btrfs#Compression, and btrfs(5)
- ZFS#Tuning
- NTFS#Improving performance

### Tuning kernel parameters

There are several key tunables affecting the performance of block devices, see sysctl#Virtual memory for more information.

### Input/output schedulers

#### Background information

The input/output (I/O) scheduler is the kernel component that decides in which order the block I/O operations are submitted to storage devices. It is useful to remind here some specifications of two main drive types because the goal of the I/O scheduler is to optimize the way these are able to deal with read requests:

- An HDD has spinning disks and a head that moves physically to the required location. Therefore, random latency is quite high ranging between 3 and 12ms (whether it is a high end server drive or a laptop drive and bypassing the disk controller write buffer) while sequential access provides much higher throughput. The typical HDD throughput is about 200 I/O operations per second (IOPS).

- An SSD does not have moving parts, random access is as fast as sequential one, typically under 0.1ms, and it can handle multiple concurrent requests. The typical SSD throughput is greater than 10,000 IOPS, which is more than needed in common workload situations.

If there are many processes making I/O requests to different storage parts, thousands of IOPS can be generated while a typical HDD can handle only about 200 IOPS. There is a queue of requests that have to wait for access to the storage. This is where the I/O schedulers plays an optimization role.

#### The scheduling algorithms

One way to improve throughput is to linearize access: by ordering waiting requests by their logical address and grouping the closest ones. Historically this was the first Linux I/O scheduler called elevator.

One issue with the elevator algorithm is that it is not optimal for a process doing sequential access: reading a block of data, processing it for several microseconds then reading next block and so on. The elevator scheduler does not know that the process is about to read another block nearby and, thus, moves to another request by another process at some other location. The anticipatory I/O scheduler overcomes the problem: it pauses for a few milliseconds in anticipation of another close-by read operation before dealing with another request.

While these schedulers try to improve total throughput, they might leave some unlucky requests waiting for a very long time. As an example, imagine the majority of processes make requests at the beginning of the storage space while an unlucky process makes a request at the other end of storage. This potentially infinite postponement of the process is called starvation. To improve fairness, the deadline algorithm was developed. It has a queue ordered by address, similar to the elevator, but if some request sits in this queue for too long then it moves to an "expired" queue ordered by expire time. The scheduler checks the expire queue first and processes requests from there and only then moves to the elevator queue. Note that this fairness has a negative impact on overall throughput.

The Completely Fair Queuing (CFQ) approaches the problem differently by allocating a timeslice and a number of allowed requests by queue depending on the priority of the process submitting them. It supports cgroup that allows to reserve some amount of I/O to a specific collection of processes. It is in particular useful for shared and cloud hosting: users who paid for some IOPS want to get their share whenever needed. Also, it idles at the end of synchronous I/O waiting for other nearby operations, taking over this feature from the anticipatory scheduler and bringing some enhancements. Both the anticipatory and the elevator schedulers were decommissioned from the Linux kernel replaced by the more advanced alternatives presented below.

The Budget Fair Queuing (BFQ) is based on CFQ code and brings some enhancements. It does not grant the disk to each process for a fixed time-slice but assigns a "budget" measured in number of sectors to the process and uses heuristics. It is a relatively complex scheduler, it may be more adapted to rotational drives and slow SSDs because its high per-operation overhead, especially if associated with a slow CPU, can slow down fast devices. The objective of BFQ on personal systems is that for interactive tasks, the storage device is virtually as responsive as if it was idle. In its default configuration it focuses on delivering the lowest latency rather than achieving the maximum throughput, which can sometimes greatly accelerate the startup of applications on hard drives.

Kyber is a recent scheduler inspired by active queue management techniques used for network routing. The implementation is based on "tokens" that serve as a mechanism for limiting requests. A queuing token is required to allocate a request, this is used to prevent starvation of requests. A dispatch token is also needed and limits the operations of a certain priority on a given device. Finally, a target read latency is defined and the scheduler tunes itself to reach this latency goal. The implementation of the algorithm is relatively simple and it is deemed efficient for fast devices.

#### Kernel's I/O schedulers

While some of the early algorithms have now been decommissioned, the official Linux kernel supports a number of I/O schedulers. The Multi-Queue Block I/O Queuing Mechanism (blk-mq) maps I/O queries to multiple queues, the tasks are distributed across threads and therefore CPU cores. Within this framework the following schedulers are available:

- None, where no queuing algorithm is applied.
- mq-deadline, the adaptation of the deadline scheduler (see below) to multi-threading.
- Kyber
- BFQ

#### Changing I/O scheduler

Note The best choice of scheduler depends on both the device and the exact nature of the workload. Also, the throughput in MB/s is not the only measure of performance: deadline or fairness deteriorate the overall throughput but may improve system responsiveness. Benchmarking may be useful to indicate each I/O scheduler performance.

To list the available schedulers for a device and the active scheduler (in brackets):

    $ cat /sys/block/sda/queue/scheduler

    mq-deadline kyber [bfq] none

To list the available schedulers for all devices:

    $ grep "" /sys/block/*/queue/scheduler

    /sys/block/pktcdvd0/queue/scheduler:none
    /sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
    /sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none

To change the active I/O scheduler to bfq for device sda, use:

    # echo bfq > /sys/block/sda/queue/scheduler

The process to change I/O scheduler, depending on whether the disk is rotating or not can be automated and persist across reboots. For example the udev rules below set the scheduler to bfq for rotational drives, bfq for SSD/eMMC drives and none for NVMe drives:

    /etc/udev/rules.d/60-ioschedulers.rules

    # HDD
    ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

    # SSD
    ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"

    # NVMe SSD
    ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

Reboot or force udev#Loading new rules.

#### Tuning I/O scheduler

Each of the kernel's I/O scheduler has its own tunables, such as the latency time, the expiry time or the FIFO parameters. They are helpful in adjusting the algorithm to a particular combination of device and workload. This is typically to achieve a higher throughput or a lower latency for a given utilization. The tunables and their description can be found within the kernel documentation.

To list the available tunables for a device, in the example below sdb which is using deadline, use:

    $ ls /sys/block/sdb/queue/iosched

    fifo_batch  front_merges  read_expire  write_expire  writes_starved

To improve deadline's throughput at the cost of latency, one can increase `fifo_batch` with the command:

    # echo 32 > /sys/block/sdb/queue/iosched/fifo_batch

### Power management configuration and write cache

When dealing with traditional rotational disks (HDDs) you may want to completely disable or lower power saving features, and check if the write cache is enabled.

See Hdparm#Power management configuration and Hdparm#Write cache.

Afterwards, you can make a udev rule to apply them on boot-up.

Tip GNOME allows the setting of some of these parameters through the Disks application and does not require a udev rule.
Note Some features might not be supported by your hard drive. If that's the case, Hdparm will notify you. Hence, simply ignore the configuration of this certain feature.

### Reduce disk reads/writes

Avoiding unnecessary access to slow storage drives is good for performance and also increasing lifetime of the devices, although on modern hardware the difference in life expectancy is usually negligible.

Note A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and 10GB of data written per day, would get an 8 years life expectancy. It gets better with bigger SSDs and modern controllers with less write amplification. See also this endurance experiment when considering whether any particular strategy to limit disk writes is actually needed.

#### Show disk writes

The iotop package can sort by disk writes, and show how much and how frequently programs are writing to the disk. See iotop(8) for details.

#### Relocate files to tmpfs

Relocate files, such as your browser profile, to a tmpfs file system, for improvements in application response as all the files are now stored in RAM:

- Refer to Profile-sync-daemon for syncing browser profiles. Certain browsers might need special attention, see e.g. Firefox on RAM.
- Refer to Anything-sync-daemon for syncing any specified folder.
- Refer to Makepkg#Improving build times for improving compile times by building packages in tmpfs.

#### File systems

Refer to corresponding file system page in case there were performance improvements instructions, see the list at #Choosing and tuning your filesystem.

#### Swap space

See Swap#Performance for details.

#### Writeback interval and buffer size

See Sysctl#Virtual memory for details.

#### Disable core dumps

See Core dump#Disabling automatic core dumps.

### Storage I/O scheduling with ionice

Many tasks such as backups do not rely on a short storage I/O delay or high storage I/O bandwidth to fulfill their task, they can be classified as background tasks. On the other hand quick I/O is necessary for good UI responsiveness on the desktop. Therefore it is beneficial to reduce the amount of storage bandwidth available to background tasks, whilst other tasks are in need of storage I/O. This can be achieved by making use of the Linux I/O scheduler BFQ, which allows setting different priorities for processes.

The I/O priority of a background process can be reduced to the "Idle" level by starting it with

    $ ionice -c 3 command

See a short introduction to ionice and ionice(1) for more information.

### Trimming

For optimal performance, empty blocks of solid state drives should be discarded (a.k.a. trimmed) periodically to optimize random write speeds. See Solid state drive#TRIM for more information.

## Network

### General information

- Kernel networking: see Sysctl#Improving performance
- NIC: see Network configuration#Set device MTU and queue length
- DNS: consider using a caching DNS resolver, see Domain name resolution#DNS servers
- Samba: see Samba#Improve throughput

### Regulatory domain

This article or section is a candidate for merging with Network configuration/Wireless#Respecting the regulatory domain.

Notes: We already have a good section on this at the target page, might be beneficial to move most of the content there and just leave this as a stub with emphasis on the kernel parameter to override the settings when applied incorrectly. (Discuss in Talk:Improving performance)

Different countries have different standards for wireless network services, and you will typically be able to achieve a stronger signal by setting the correct domain for your network configuration. This will typically be configured during setup, but in some cases the settings will not be applied correctly. Check the contents of `/sys/module/cfg80211/parameters/ieee80211_regdom`; if the value is `00` (a global setting that is generally more restrictive) or set to the incorrect region, try adding the following kernel parameter, replacing `XX` with the correct country code (e.g., `US` for the United States):

    cfg80211.ieee80211_regdom=XX

Then reboot your system.

### Power management

Certain devices have issues whereby their network adapters will incorrectly entering power saving mode while still in use, throttling performance or causing disconnections. If this happens to you, ensure that you upgrade your packages to the latest version to receive any necessary firmware updates, and see Power management#Network interfaces.

## CPU

### Overclocking

Overclocking improves the computational performance of the CPU by increasing its peak clock frequency. The ability to overclock depends on the combination of CPU model and motherboard model. It is most frequently done through the BIOS. Overclocking also has disadvantages and risks. It is neither recommended nor discouraged here.

Many Intel chips will not correctly report their clock frequency to acpi_cpufreq and most other utilities. This will result in excessive messages in dmesg, which can be avoided by unloading and blacklisting the kernel module `acpi_cpufreq`. To read their clock speed use i7z from the i7zAUR package. To check for correct operation of an overclocked CPU, it is recommended to do stress testing.

### Frequency scaling

See CPU frequency scaling.

### CPU scheduler

The default CPU scheduler in the mainline Linux kernel is EEVDF.

This article or section needs expansion.

Reason: Add CFS, the previous default scheduler, to the list. (Discuss in Talk:Improving performance)

- Project C — Cross-project for refactoring BMQ into Project C, with re-creation of PDS based on the Project C code base. So it is a merge of the two projects, with a subsequent update of the PDS as Project C. Recommended as a more recent development.

  https://cchalpha.blogspot.com/ || linux-prjcAUR

- BORE — The BORE scheduler focuses on sacrificing some fairness for lower latency in scheduling interactive tasks, it is built on top of CFS and is only adjusted for vruntime code updates, so the overall changes are quite small compared to other unofficial CPU schedulers.

  https://github.com/firelzrd/bore-scheduler || linux-cachyos-boreAUR

- SCX — Allows dynamic injection of various CPU schedulers without requiring a system reset.

  https://github.com/sched-ext/scx || scx-scheds

### Real-time kernel

Some applications such as running a TV tuner card at full HD resolution (1080p) may benefit from using a realtime kernel.

### Adjusting priorities of processes

See also nice(1) and renice(1).

#### Ananicy

Ananicy CPP is a daemon, available as ananicy-cpp or ananicy-cpp-gitAUR, for auto adjusting the nice levels of executables. The nice level represents the priority of the executable when allocating CPU resources.

Warning GameMode and Ananicy CPP both adjust the nice levels of processes. However, combining both tools is not recommended.[1]

#### cgroups

See cgroups.

#### LimitCPU

LimitCPU is a program to limit the CPU usage percentage of a specific process. After installing limitcpuAUR, you may limit the CPU usage of a process's PID using a scale of 0 to 100 times the number of CPU cores that the computer has. For example, with eight CPU cores the percentage range will be 0 to 800. Usage:

    $ limitcpu -l 50 -p 5081

### irqbalance

The purpose of irqbalance is to distribute hardware interrupts across processors on a multiprocessor system in order to increase performance. It can be controlled by the provided `irqbalance.service`.

Warning In some cases, irqbalance can interfere with power saving and can lead to stuttering or bad framerates in video games [2].

### Turn off CPU exploit mitigations

Warning Do not apply this setting without considering the vulnerabilities it opens up. Among other things, if this option is enabled, you must not rely on a virtual machine to isolate untrusted programs. See this and this for more information.

Turning off CPU exploit mitigations may improve performance. Use below kernel parameter to disable them all:

    mitigations=off

The explanations of all the switches it toggles are given at kernel.org. You can use spectre-meltdown-checkerAUR or lscpu(1) (from util-linux) for vulnerability check.

Note When using an Intel CPU from generation 10 and later, or AMD Ryzen series 1000 and later, the performance uplift from disabling mitigations is only up to 5% instead of the up to 25% for the previous CPU generations. See the general review from early 2021, the test on Rocket Lake and the test on Alder Lake

### Tuning compilation for your CPU

Depending on your CPU, you may be able to gain a small performance boost by compiling software tuned for your native CPU microarchitecture with the flag `-march=native`, but any binaries you compile with this flag will be slow or broken on other CPU microarchitectures. If you use this option and want to switch or upgrade your CPU, you need to either recompile your binaries or choose a new CPU that uses the same microarchitecture as your old one. You can apply this option by default for makepkg.

If you compile your own kernel, you can also enable this option during kernel compilation with the `CONFIG_X86_NATIVE_CPU` option. However, kernel improvements will be smaller as the kernel forbids extended vector instructions in generic code, which are responsible for the most of performance improvement in regular binaries, so most of the performance improvement will come from much smaller micro-optimizations.

## Graphics

### Xorg configuration

Graphics performance may depend on the settings in xorg.conf(5); see the NVIDIA, AMDGPU and Intel articles. Improper settings may stop Xorg from working, so caution is advised.

### Mesa configuration

The performance of the Mesa drivers can be configured via drirc. adriconf (Advanced DRI Configurator) is a GUI tool to configure Mesa drivers by setting options and writing them to the standard drirc file.

### Hardware video acceleration

Hardware video acceleration makes it possible for the video card to decode/encode video.

### Overclocking

As with CPUs, overclocking can directly improve performance, but is generally recommended against. There are several packages, such as rovclockAUR (ATI cards), rocm-smi-lib (recent AMD cards), nvclockAUR (old NVIDIA - up to Geforce 9), and nvidia-utils for recent NVIDIA cards.

See AMDGPU#Overclocking or NVIDIA/Tips and tricks#Enabling overclocking in nvidia-settings.

### Enabling PCIe resizable BAR

Note

- On some systems enabling PCIe resizable BAR can result in a significant loss of performance. Benchmark your system to make sure it increases performance. Note that on the newer Intel Arc dedicated GPUs, resizable BAR is officially recommended by Intel and will almost always improve performance.
- The Compatibility Support Module (CSM) must be disabled for this to take effect.

The PCI specification allows larger Base Address Registers (BARs) to be used for exposing PCI devices memory to the PCI Controller. This can result in a performance increase for video cards. Having access to the full video memory improves performance, but also enables optimizations in the graphics driver. The combination of resizable BAR, above 4G decoding and these driver optimizations are what AMD calls AMD Smart Access Memory, available at first on AMD Series 500 chipset motherboards, later expanded to AMD Series 400 and Intel Series 300 and later through UEFI updates. This setting may not be available on all motherboards, and is known to sometimes cause boot problems on certain boards.

If the BAR has a 256M size, the feature is not enabled or not supported:

    # dmesg | grep BAR=

    [drm] Detected VRAM RAM=8176M, BAR=256M

To enable it, enable the setting named "Above 4G Decode" or ">4GB MMIO" in your motherboard settings. Verify that the BAR is now larger:

    # dmesg | grep BAR=

    [drm] Detected VRAM RAM=8176M, BAR=8192M

## RAM, swap and OOM handling

### Clock frequency and timings

RAM can run at different clock frequencies and timings, which can be configured in the BIOS. Memory performance depends on both values. Selecting the highest preset presented by the BIOS usually improves the performance over the default setting. Note that increasing the frequency to values not supported by both motherboard and RAM vendor is overclocking, and similar risks and disadvantages apply, see #Overclocking.

### Root on RAM overlay

This article or section is out of date.

Reason: The liveroot script appears to be unmaintained, but this approach should still work. (Discuss in Talk:Improving performance#Section_5.2: liveroot hasn't been updated since 2016)

If running off a slow writing medium (USB, spinning HDDs) and storage requirements are low, the root may be run on a RAM overlay ontop of read only root (on disk). This can vastly improve performance at the cost of a limited writable space to root. See liverootAUR.

### Swap on zram or zswap

Similar benefits (at similar costs) can be achieved using zswap or swap on zram. The two are generally similar in intent although not operation:

- zswap operates as a compressed RAM cache and neither requires (nor permits) extensive userspace configuration. It works in conjunction with a swap device by acting as its cache. Pages that would normally enter swap can enter zswap instead.
- zram is a kernel module which can be used to create a compressed block device in RAM. This compressed block device can be used as a swap device, with no other swap device required to back it up. It comes with many options, including the possibility of using a backing device for holding cold pages.

Because both options involve the swap subsystem, configuration that affects swap also affects these systems. For example, swappiness determines whether the kernel should prioritize dropping file cache or moving pages to swap when memory pressure is high. Because zswap intercepts the action of moving pages to swap and zram acts as the swap, the option would also determine how often these two mechanisms are used.

### Using the graphics card's RAM

In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See Swap on video RAM.

### Improving system responsiveness under low-memory conditions

This article or section needs expansion.

Reason: The systemd.service(5) watchdog settings should be mentioned and crosslinked, see also Systemd#Notifying about failed services). (Discuss in Talk:Improving performance)

On traditional GNU/Linux system, especially for graphical workstations, when allocated memory is overcommitted, the overall system's responsiveness may degrade to a nearly unusable state before either triggering the in-kernel out-of-memory (OOM)-killer or a sufficient amount of memory got free (which is unlikely to happen quickly when the system is unresponsive, as you can hardly close any memory-hungry applications which may continue to allocate more memory). The behaviour also depends on specific setups and conditions, returning to a normal responsive state may take from a few seconds to more than half an hour, which could be a pain to wait in serious scenario like during a conference presentation.

While the behaviour of the kernel as well as the userspace things under low-memory conditions may improve in the future as discussed on kernel and Fedora mailing lists, users can use more feasible and effective options than hard-resetting the system or tuning the `vm.overcommit_*` sysctl parameters:

- Manually trigger the kernel OOM-killer with Magic SysRq key, namely `Alt+SysRq+f`.
- Use a userspace OOM daemon to tackle these automatically (or interactively).

Warning Triggering OOM killer to kill running applications may lose your unsaved works. It is up to you that either you are patient enough to wait in hope that applications will finally free the memory normally, or you want to bring back unresponsive system as soon as possible.

Sometimes a user may prefer OOM daemon to SysRq because with kernel OOM-killer you cannot prioritize the process to (or not) terminate. To list some OOM daemons:

- systemd-oomd — Provided by systemd as `systemd-oomd.service` that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space.

  https://github.com/systemd/systemd, systemd-oomd(8) || systemd

- earlyoom — Simple userspace OOM-killer implementation written in C.

  https://github.com/rfjakob/earlyoom || earlyoom

- oomd — OOM-killer implementation based on PSI, requires Linux kernel version 4.20+. Configuration is in JSON and is quite complex. Confirmed to work in Facebook's production environment.

  https://github.com/facebookincubator/oomd || oomdAUR

- nohang — Sophisticated OOM handler written in Python, with optional PSI support, more configurable than earlyoom.

  https://github.com/hakavlad/nohang || nohang-gitAUR

- low-memory-monitor — GNOME developer's effort that aims to provide better communication to userspace applications to indicate the low memory state, besides that it could be configured to trigger the kernel OOM-killer. Based on PSI, requires Linux 5.2+.

  https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-gitAUR

- uresourced — A small daemon that enables cgroup based resource protection for the active graphical user session.

  https://gitlab.freedesktop.org/benzea/uresourced || uresourcedAUR

- bustd — Very lightweight userspace OOM-killer, useful for slower machines. Based on PSI, requires Linux 4.2+.

  https://github.com/vrmiguel/bustd || bustdAUR

## See also

- Red Hat Performance Tuning Guide
- Linux Performance Measurements using vmstat

Categories:

- Hardware
- System administration

Hidden categories:

- Pages or sections flagged with Template:Merge
- Pages or sections flagged with Template:Expansion
- Pages or sections flagged with Template:Out of date

Improving performance
Add topic