![Disabling Transparent Huge pages
# cat /proc/meminfo | grep AnonHuge
AnonHugePages: 2048 kB
# ps aux | grep huge
root 42 0.0 0.0 0 0 ? SN Jan17 0:00 [khugepaged]
To disable it:
• at runtime:
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# echo never > /sys/kernel/mm/transparent_hugepage/defrag
• at boot time:
GRUB_CMDLINE_LINUX_DEFAULT="(...) transparent_hugepage=never"](https://image.slidesharecdn.com/slides20190909sqlsess3-190919050738/85/PGConf-ASIA-2019-Bali-Tune-Your-LInux-Box-Not-Just-PostgreSQL-Ibrar-Ahmed-25-320.jpg)
PGConf.ASIA 2019 Bali - Tune Your LInux Box, Not Just PostgreSQL - Ibrar Ahmed
- 1. Tune Box Linux Anda, bukan hanya PostgreSQL
- 2. Ibrar Ahmed Tune your Linux Box, not just PostgreSQL Linux Kernel Tuning for PostgreSQL performance Senior Database Architect - Percona LLC September 08 – 12, 2019
- 3. Database Performance • Choose better Hardware • Operating System Selection and Tuning • Choose Database Depend based on Workload • Tune your Database. • Tune your Queries • Tune your Application SELECT * FROM foo
- 4. PostgreSQL Modules Clients Processes PostgreSQL Memory Kernel Memory Disk Management Background Writer Shared Buffers Default = 128MB WAL Writer Checkpointer Archiver Logger Postmaster Port = 5432 Postgres Postgres Client - psql Client - JDBC Client - ODBC base/ Datafiles pg_wal/ WAL files global Configuration Files Table Spaces$PGDATA /dev/sda /dev/sdb WAL Buffers Default = 16MB work_mem maintancework_mem 4K 2MB/1GB Huge Pages THP
- 6. PostgreSQL Tuning • shared_buffers • wal_buffers • effective_cache_size • work_mem • maintenance_work_mem • synchronous_commit • checkpoint_timeout • checkpoint_completion_target PostgreSQL Memory Shared Buffers Default = 128MB WAL Buffers Default = 16MB work_mem maintancework_mem Disk Management base/ Datafiles pg_wal/ WAL files global Configuration Files Table Spaces$PGDATA /dev/sda /dev/sdb
- 7. shared_buffer • PostgreSQL uses its own buffer and also uses kernel buffered I/O. • PostgreSQL does not change the information on disk directly then how? • Writes the data to shared buffer cache. • The backend process write that these blocks kernel buffer. postgresql=# SHOW shared_buffers; shared_buffers ---------------- 128MB (1 row) The proper size for the POSTGRESQL shared buffer cache is the largest useful size that does not adversely affect other activity. —Bruce Momjian How/When data written to disk actually?
- 8. PostgreSQL Tuning / shared_buffer
- 9. Configuraing WAL • Do you have Transaction? Obviously • WAL – (Write Ahead LOG) Log your transactions • Size of WAL files 16MB with 8K Block size (can be changed at compile time) • PostgreSQL writes WAL into the buffers(wal_buffer ) and then these buffers are flushed to disk. Tip: Bigger value for wal_buffer in case of lot of concurrent connection gives better performance.
- 10. effective_cache_size • This used by the optimizer to estimate the size of the kernel's disk buffer cache. • The effective_cache_size provides an estimate of the memory available for disk caching. • It is just a guideline, not the exact allocated memory or cache size. TIP: It should be large enough to hold most accessed tables, but at the same time small enough to avoid swap.
- 11. work_mem This configuration is used for complex sorting.
- 12. maintenance_work_mem maintenance_work_mem is a memory setting used for maintenance tasks. • The default value is 64MB. • Setting a large value helps in tasks like VACUUM, RESTORE, CREATE INDEX, ADD FOREIGN KEY and ALTER TABLE.
- 13. synchronous_commit •This is used to enforce that commit will wait for WAL to be written on disk before returning a success status to the client. •This is a trade-off between performance and reliability. •Increasing reliability decreases performance and vice versa.
- 14. checkpoint_timeout •PostgreSQL writes changes into WAL. The checkpoint process flushes the data into the data files. •More checkpoints have a negative impact on performance.
- 16. Input Output Handling • Direct IO, Buffered IO and Double buffering • PostgreSQL believes that the Operating system (Kernel) knows much better about storage and IO scheduling. • PostgreSQL has its own buffering; and also needs the pages cache. Double Buffering • It Increase the use of memory. • And different kernel and setting behave differently.
- 17. Virtual Memory https://en.wikipedia.org/wiki/Virtual_memory https://en.wikipedia.org/wiki/Page_table • Every process is given the impression that it is working with large, contiguous sections of memory • Each process runs in its own dedicated address space • Pages Table are used to translate the virtual addresses seen by the application into Physical Address
- 18. Translation Lookaside Buffer (TLB) • Translation Lookaside Buffer is a memory cache • It reduce the time to access a user memory location • If a match is found the physical address of the page is returned → TLB hit • If match not found scan the page table (walk) looking for the address mapping (entry) → TLB miss Small page size bigger TLB size → expensive
- 19. Memory Pages •Different OS has different size of Pages •Linux has a concept of Classic Huge Pages and Transparent Huge Pages. •BSD has Super Pages. •Windows has Large Pages.
- 20. Linux Page sizes 4K 67108864 2M 131072 1G 256 large/huge pages • Linux Page size is 4K • Many modern processors support other page sizes If we consider a server with 256G of RAM:
- 21. Classic Huge Pages 1/3 # cat /proc/meminfo MemTotal: 264041660 kB ... Hugepagesize: 2048 kB DirectMap4k: 128116 kB DirectMap2M: 3956736 kB DirectMap1G: 266338304 kB sysctl -w vm.nr_hugepages=256
- 22. Classic Huge Pages 2/3 – Setting Huge Page Size # vi /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="hugepagesz=1GB default_hugepagesz=1G” # update-grub Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.4.0-75-generic Found initrd image: /boot/initrd.img-4.4.0-75-generic Found memtest86+ image: /memtest86+.elf Found memtest86+ image: /memtest86+.bin Done # shutdown -r now
- 23. Classic Huge Pages 3/3 – Enabling / Disabling in PostgreSQL # vim /etc/postgresql/10/main/postgresql.conf huge_pages=ON # default is try # service postgresql restart
- 24. Transparent Huge pages • The kernel works in the background (khugepaged) trying to: "create" huge pages. • Find enough contiguous blocks of memory • Convert them into a huge page • Transparently allocate them to processes when there is a "fit"
- 25. Disabling Transparent Huge pages # cat /proc/meminfo | grep AnonHuge AnonHugePages: 2048 kB # ps aux | grep huge root 42 0.0 0.0 0 0 ? SN Jan17 0:00 [khugepaged] To disable it: • at runtime: # echo never > /sys/kernel/mm/transparent_hugepage/enabled # echo never > /sys/kernel/mm/transparent_hugepage/defrag • at boot time: GRUB_CMDLINE_LINUX_DEFAULT="(...) transparent_hugepage=never"
- 26. vm.swappiness • This is another kernel parameter that can affect the performance of the database. •Used to control the swappiness (swapping pages to swap memory into RAM) behavior on a Linux system. •This parameter's can take anything from “0” to “100”, default is 60. •Higher value means more aggressively swap.
- 27. vm.overcommit_memory and vm.overcommit_ratio • Applications acquire memory and free that memory when it is no longer needed. • But in some cases an application acquires too much memory and does not release it. This can invoke the OOM killer. • Heuristic overcommit, Do it intelligently (default); based kernel heuristics • Allow overcommit anyway • Don’t over commit beyond the overcommit ratio.
- 28. vm.dirty_background_ratio and vm.dirty_background_bytes •The vm.dirty_background_ratio is the percentage of memory filled with dirty pages that need to be flushed to disk. •Flushing is done in the background. • The value of this parameter ranges from 0 to 100;
- 29. vm.dirty_ratio / vm.dirty_bytes •The vm.dirty_background_ratio is the percentage of memory filled with dirty pages that need to be flushed to disk. •Flushing is done in the foreground. • The value of this parameter ranges from 0 to 100;
- 30. Blogs •Tuning PostgreSQL Database Parameters to Optimise Performance. ▪ https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-opti mize-performance/ •Tune Linux Kernel Parameters For PostgreSQL Optimisation ▪ https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-op timization/
- 31. ? “Poor leaders rarely ask questions of themselves or others. Good leaders, on the other hand, ask many questions. Great leaders ask the great questions.” Michael Marquardt author of Leading with Questions