Downloaded 50 times
Uploaded byPostgreSQL-Consulting
Linux internals for Database administrators at Linux Piter 2016
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.
More Related Content
Similar to Linux internals for Database administrators at Linux Piter 2016
Linux internals for Database administrators at Linux Piter 2016
- 1. Linux IO internals fordatabase 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 IOproblem 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 Sharedmemory Database Linux Page cache User space Kernel space WAL buffer WAL Datafile
- 5. Key things aboutsuch 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 andmapping CPU L1 MMU TLB Memory L2 L3 page table Virtual addressing Translation Physical addressing
- 7. DBAs takeaways: • Databasewith 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 Freelist 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 happensif: 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 andcholera • 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 Kernelbuffer Journalated fylesystem Data Journal entry Data
- 13. DBAs takeaways: • ext4or xfs • Disable write barrier (only if SSD/controller cache is protected by capacitor/battery)
- 14. IO stack shared_buffers Page cache VFS EXT4 Blockdevice interface Disks Buffer cache Elevator/IO Scheduler
- 15. Elevators • noop ornone - 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 colleguesAlexey Lesovsky and Max Boguk for a lot of research on this topic
- 17.