Input-output performance problems are on every day agenda for DBAs since the databases exist. Volume of data grows rapidly and you need to get your data fast from the disk and moreover - fast to the disk. For most databases there is a more or less easy to find checklist of recommended Linux settings to maximize IO throughput. In most cases that checklist is good enough. But it is always better to understand how it works, especially if you run into some corner-cases. This talk is about how IO in Linux works, how database pages travel from disk level to database own shared memory and back and what kind of mechanisms exist to control this. We will discuss memory structures, swap and page-out daemons, filesystems, schedullers and IO methods. Some fundamental differences in IO approaches between PostgreSQL, Oracle and MySQL will be covered.

1. Linux IO internals
for database administrators
Ilya Kosmodemiansky
ik@postgresql-consulting.com

2. Why this talk
• Linux is a most common OS for databases
• DBAs often run into IO problems
• Most of the information on topic is written by kernel
developers (for kernel developers) or is checklist-style
• Checklists are useful, but up to certain workload

3. The main IO problem for databases
• How to maximize page throughput between memory and
disks
• Things involved:
Disks
Memory
CPU
IO Schedulers
Filesystems
Database itself
• IO problems for databases are not always only about disks

4. A typical database
DRAM
Disks
Shared memory
Database
Linux
Page cache
User space
Kernel space
WAL buffer
WAL Datafile

5. Key things about such workload
• Shared memory segment can be very large
• Keeping in-memory pages synchronized with disk generates
huge IO
• WAL should be written fast and safe
• One and every layer of OS IO stack involved

6. Memory allocation and mapping
CPU L1
MMU TLB
Memory
L2 L3
page
table
Virtual addressing
Translation
Physical addressing

7. DBAs takeaways:
• Database with huge shared memory segment benefits from
huge pages
• But not from transparent huge pages
Databases operate large continuous shared memory segments
THP defragmentation can lead to severe performance
degradation in such cases

8. Freeing memory
Page cache
Swap
Free list Free list Free list
alloc()free()
page-out
vm.min_free_kbytes
reclaim
vm.swapiness
OOM-killer
vm.panic_on_oom

9. Page-out
• Page-out happens if:
someone calls fsync
30 sec timeout exceeded (vm.dirty_expire_centisecs)
Too many dirty pages (vm.dirty_background_ratio and
vm.dirty_ratio)
• It is reasonable to tune vm.dirty_* on rotating disks with
RAID controller, but helps a little on server class SSDs

10. DBAs takeaways:
• vm.overcommit_memory
0 - heuristic overcommit, reduces swap usage
1 - always overcommit
2 - do not overcommit (vm.overcommit_ratio = 50 by
default)
• vm.min_free_kbytes - reasonably high (can be easy 1000000
on a server with enough memory)
• vm.swappiness = 1
0 - swap disabled
60 - default
100 - swap preffered instead of other reaping mechanisms
• Your database would not like OOM-killer

11. OOM-killer: plague and cholera
• vm.panic_on_oom effectively disables OOM-killer, but that is
probably not the result you desire
• Or for a certain process: echo -17 > /proc/12465/oom_adj
but again

12. Filesystems: write barriers
Journal
Kernel buffer
Journalated fylesystem
Data
Journal entry
Data

13. DBAs takeaways:
• ext4 or xfs
• Disable write barrier (only if SSD/controller cache is protected
by capacitor/battery)

14. IO stack
shared_buffers
Page cache
VFS
EXT4
Block device interface
Disks
Buffer cache
Elevator/IO Scheduler

15. Elevators
• noop or none - then disks throughput is so high, that it can
not benefit from keen scheduling
PCIe SSDs
SAN disk arrays
• deadline - rotating disks
• CFQ - universal, default one

16. Thanks
to my collegues Alexey Lesovsky and Max Boguk for a lot of
research on this topic

17. Questions?
ik@postgresql-consulting.com