Linux internals for Database administrators at Linux Piter 2016
9 likes1,519 views
The document discusses Linux I/O internals relevant to database administrators, focusing on I/O problems encountered when operating databases on Linux systems. It emphasizes the importance of configurations such as memory allocation, page synchronization between memory and disks, and tuning various Linux kernel parameters to optimize performance. Key takeaways include the management of shared memory segments, the impact of I/O schedulers, and recommendations for handling potential out-of-memory situations.
Linux internals for Database administrators at Linux Piter 2016
- 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