Adventures in System Administration

Category: Linux

Articles dealing with the Linux operating system.

MySQL Configuration Files

Since I recently posted MariaDB client and sever options files, it’s only fitting that I post options files for MySQL. Since MariaDB and MySQL have diverged since version 5 when MariaDB was a drop-in replacement for MySQL, options files can no longer be shared between the two without modification.

MySQL has many options for both the client and server than can be adjusted (or tuned) to provide better performance. For most, the default settings are fine and never need to be adjusted. A few, however, should be adjusted for optimal performance. This is particular true for the InnoDB storage engine. The option innodb_buffer_pool_size, which sets the size of the in-memory buffer pool, is probably the most important option to boost performance. It can be set up to 80% of the total memory on the server, but the default is very inadequate 128 MB.

Another option is max_allowed_packet which is used by both client and the server. This sets the maximum size for a data packet or generated/intermediate string. It must be large enough to hold the largest record or BLOB. The client default is a very anemic 16 MB. The server default is better but only 64 MB.

MariaDB Configuration Files

MariaDB has many options for both the client and server than can be adjusted (or tuned) to provide better performance. For most, the default settings are fine and never need to be adjusted. A few, however, should be adjusted for optimal performance. This is particular true for the InnoDB storage engine. The option innodb_buffer_pool_size, which sets the size of the in-memory buffer pool, is probably the most important option to boost performance. It can be set up to 80% of the total memory on the server, but the default is very inadequate 128 MB.

Another option is max_allowed_packet which is used by both client and the server. This sets the maximum size for a data packet or generated/intermediate string. It must be large enough to hold the largest record or BLOB. The client default is not too shabby at 1 GB, but the server default is an anemic 16 MB.

The MariaDB packages for Debian and Red Hat based distributions do install options files (also known as defaults files) for both the client and server, but they are largely placeholders, setting very few or no options. And they have no comments about any of the options. This makes it difficult to know which options should be adjusted for best performance. The options are documented on the MariaDB Documentation site, but this means wading through a long list of options trying to find the ones of interest.

Backing Up MySQL and MariaDB Databases

Having regular backups of MySQL and MariaDB databases is vitally important to ensure that data can be recovered in the event of corruption (which could be caused by a system failure or malicious software such as ransomware) or human error (such as when a user accidentally deletes a row, table, or entire database). MySQL and MariaDB provide a utility program to back up the databases – namely mysqldump (which is mariadb-dump for MariaDB 1.5 and higher) – but neither provides a program or script that allows backups to be easily automated. Aptum Technologies (my employer) provides a script allowing customers to back up the databases from a cron job. The original was a very basic script which didn’t have much flexibility. Using this as foundation, I rewrote the backup script and enhanced it over the years to improve its functionality and add features.

The script – backup-mysql – uses mysqldump to create a logical backup of each database. Each database is backed up to a separate file and then compressed using gzip (or pigz on systems with two or more processors). The database backup files are then archived to a tar file. This archive file is not compressed since the individual database backup files are already compressed. And a log file is created with information about the backup operation. Any errors that occur are recorded in the log file.

Large Send Offload and Network Performance

An issue that I’ve encountered fairly often are complaints of slow network performance, especially when transferring large files. Although there are many issues that can affect network throughput, the most common issue is related to Large Send Offload.

Large Send Offload (also known as Large Segmentation Offload, and LSO for short) is a feature that allows the operating system TCP\IP network stack to build a large TCP message of up to 64KB in length before sending to the Ethernet adapter. Then the hardware on the Ethernet adapter — what I’ll call the LSO engine — segments it into smaller data packets (known as “frames” in Ethernet terminology) that can be sent over the wire. This is up to 1500 bytes for standard Ethernet frames and up to 9000 bytes for jumbo Ethernet frames. (The actual sizes are bit larger to accommodate the overhead – header and frame check sequence – in the packet). This is designed to free up the CPU on the server from having to handle segmenting large TCP messages into smaller packets required by the frame size. Sounds like a good deal. What could possibly go wrong?

Copyright © 2026 Charles Rutledge

Powered by WordPress & Theme by Anders Norén