Debian 13 Trixie: Key Updates and Recommendations for Users

Debian 13 “Trixie” introduces a range of improvements that enhance performance and modernize system management. Some of these changes may significantly affect server operations. This article provides an overview of the most important updates, along with practical recommendations to help you configure your system for stability and optimal performance.

What’s New in Debian 13

Debian 13 “Trixie” was released in August 2025. It is a stable, secure, and high-performance modern operating system with guaranteed five-year support until 2030.

Version 13 delivers new configuration options for higher performance, better responsiveness, and improved flexibility. Key highlights include:

• Modern Linux kernel 6.x LTS with optional PREEMPT_RT support for real-time applications requiring fast and predictable response times (e.g., industrial or multimedia workloads).
• The EEVDF scheduler for modern latency-sensitive applications and processes.
• A new sched_ext framework, enabling customized process scheduling and system performance distribution.
• Storage of /tmp (temporary files) in memory using the tmpfs filesystem.
• Automatic QR code display for graphics subsystem errors (DRM panic), simplifying diagnostics and bug reporting.
• Enhanced security with CET (on Intel processors) and PAC-BTI (on ARM v8.5+ processors), blocking advanced exploit techniques such as ROP, JOP, and COP.
• A 64-bit time_t format now used across all architectures except 32-bit (i386), ensuring compatibility with dates beyond 2038 (older 32-bit systems may face limitations).
• Support for the latest hardware and official inclusion of the 64-bit RISC-V architecture (riscv64).

Changes in process scheduling and /tmp storage may affect performance if not configured properly. The sections below provide details and recommendations for optimal settings.

EEVDF Scheduler

The Linux kernel in Debian 13 introduces the EEVDF (Earliest Eligible Virtual Deadline First) scheduler, replacing the older CFS (Completely Fair Scheduler) as of kernel 6.6.

EEVDF is designed to meet the needs of modern applications. It allows prioritization of latency-sensitive processes, improving system responsiveness. Its key benefits include:

• Better application responsiveness: Interactive and multimedia apps run more smoothly.
• Predictable CPU time distribution: Running processes receive balanced and efficient CPU allocation.
• Protection against CPU monopolization: The “decaying lag” mechanism prevents processes from overusing system resources, preserving stability for other workloads.
• Measurable performance gains: Benchmarks show up to 13% overall performance improvement in some workloads.

Optimization for SQL Databases and Server Workloads

While EEVDF generally improves performance, certain workloads such as heavily loaded SQL databases (e.g., PostgreSQL, MariaDB) may experience performance degradation with default settings.

This is caused by fairness mechanisms designed for desktop use, which may negatively affect specialized servers.

1. Disable Automatic Grouping Process

The grouping process combines all processes started from one terminal or service, allocating CPU time collectively. On database servers, the performance of all processes may be limited, even though some could run faster. To ensure maximum performance, we recommend disabling this feature:

• To disable persistently (across reboots), add the following to /etc/sysctl.conf or a new .conf file in /etc/sysctl.d/: kernel.sched_autogroup_enabled=0
• Run the following command to disable immediately (effective until reboot): sudo sysctl -w kernel.sched_autogroup_enabled=0.

2. Advanced Latency Settings

For systems requiring ultra-low latency is critical (e.g., real-time systems, financial trading, high-load databases), EEVDF provides additional configuration options.

There are two default features that may delay critical processes, which can be disabled:

• RUN_TO_PARITY: This feature ensures fair distribution of CPU time, allocating more time to processes with lower CPU usage. For tasks requiring extremely low latency, however, it may cause unwanted delays, as a critical process might have to wait for a lower-usage process to complete.
• PLACE_LAG: his mechanism determines how newly awakened processes are handled. By default, it may slightly reduce the priority of these processes to maintain balanced CPU usage among all other processes.

Disabling these features causes the scheduler to prioritize low latency over strict fairness in CPU allocation. Critical processes will then gain immediate access to the CPU.

These features can be temporarily disabled via the debugfs interface. Changes are not persistent; the settings must be reapplied after each system restart (e.g., using a script in rc.local).

To disable the features, use the following commands:

• For RUN_TO_PARITY: echo NO_RUN_TO_PARITY > /sys/kernel/debug/sched/features
• For PLACE_LAG: echo NO_PLACE_LAG > /sys/kernel/debug/sched/features

Sched_ext Framework

Debian 13 includes the sched_ext framework, which allows CPU scheduling decisions for specific processes to be delegated to external eBPF programs.

This means that:

• Users and administrators can modify the scheduler’s logic without recompiling the entire kernel.
• Specialized scheduling policies can be created and loaded dynamically (e.g., for gaming, web server operation, or scientific computations).
• Policies can be changed and adjusted without restarting the system.

Storing /tmp in RAM

Starting with Debian 13 “Trixie”, the /tmp directory is stored in RAM by default using the tmpfs filesystem. This location speeds up operations on temporary files, which are heavily used by many applications. In practice, this change provides:

• Faster data operations: The tmpfs filesystem stores temporary files directly in RAM instead of on disk. Accessing data in memory is significantly faster than reading from or writing to an SSD or HDD.
• Improved disk longevity: Fewer writes to SSDs/HDDs reduce wear and extend the lifespan of the drives.
• Automatic cleanup: The contents of /tmp are cleared on system restart, so there is no need to manually delete old temporary files. Data is not preserved between reboots.
• Efficient memory usage: tmpfs can use up to 50% of available RAM, but memory is consumed only for files actually stored in /tmp.

Impact on Database Servers (MySQL/MariaDB)

Storing /tmp in RAM can be problematic for database servers. Systems such as MySQL, MariaDB, and their derivatives are designed with the assumption that the /tmp directory resides on physical storage.

During complex operations (e.g., ALTER TABLE, complex JOINs, or GROUP BY queries), temporary data is written to /tmp. These operations often require large amounts of memory, which can lead to two critical issues:

1. Memory exhaustion: A large database operation can completely fill the tmpfs, causing the operation to fail and potentially crashing the entire database server due to insufficient memory.
2. Double memory usage: Databases expect to store temporary data on disk. If /tmp is in RAM, the data is stored in another part of memory instead. This results in memory being used twice, without solving the underlying memory limitation problem.