This means more CPU time (and potentially storage I/O time) is available for your application(s).
If the O/S can do this mapping in 2MB chunks or 1GB chunks at a time, instead of 4KB at a time, then as you have probably already guessed, the CPU and O/S need to do less work. The Operating System needs to work in concert with the CPU to manage this mapping.Īs you can imagine, when the O/S and the CPU have to constantly map lots of 4kB chunks of physical memory to virtual address spaces in order to allow your application to work smoothly, the CPU and O/S have a lot of work to do, and the more memory your server has, the more 4kB pages the CPU and O/S have to manage. Other than that, it should be noted that physical memory is mapped into a virtual address space (at the exact moment that memory is needed) for use by a running application. It is the smallest unit of data for memory management in a virtual memory operating system.”Īn important thing to note here, which we’ll come back to shortly, is the reference to page tables. “ A page, memory page, or virtual page is a fixed-length contiguous block of virtual memory, described by a single entry in the page table. We’ll discuss THP in a future article, but for now, the simple advice is to disable THP. It should be noted that Transparent Huge Pages (THP) are not the same thing as Huge Pages. On Linux, anything other than the standard 4kB page is called a Huge Page. On a reasonably modern x86 CPU, the available page sizes are 4kB, 2MB or 1GB. The x86 CPU has the ability to use different sized memory pages. For information about using Huge Pages with your hypervisor or a container orchestration platform, please see the appendix. This article covers the use of Huge Pages with PostgreSQL.
Every application and database workload is different some workloads get a little more performance out of Huge Pages, and some get a lot more, but the more CPU cores and more main memory being used by PostgreSQL, the bigger the improvements you will get from using Huge Pages. Huge Pages offer a considerable opportunity for performance improvement. In this first article, I’m going to talk about Linux Huge Pages. I’ll talk primarily about Red Hat 7 and 8 on x86 architecture as many EDB customers use these combinations, although most, if not all, of the areas discussed are relevant to other Linux distributions, FreeBSD and other Operating systems too, on x86, IBM POWER, ARM and RiscV architectures.
Many of the concepts I will discuss may be new to you, but once you have a holistic view of your server, O/S and applications, you will be able to make many more tuning choices, some of which can offer quite dramatic improvements to database performance. This is not to say that those other areas aren’t worth considering good query optimisation, an appropriate setting for work_mem and shared_buffers, or the use of a connection pooler can make massive differences to your overall PostgreSQL performance.
#CAT PROC CPUINFO VIRTUAL ADDRESS SERIES#
Model name : Intel(R) Core(TM) i7-3770 CPU 3.I’d like to introduce a series of articles describing aspects of your server and its performance, and how in many cases, you can significantly improve the performance of PostgreSQL without making any changes to PostgreSQL configuration, SQL queries or other areas of PostgreSQL that have been covered by previous articles. Model name : Intel(R) Core(TM) i7-3770 CPU 3.40GHzįlags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl pni ssse3 lahf_lmĪddress sizes : 36 bits physical, 48 bits virtual Code: Select all Expand view Collapse view cat /proc/cpuinfo
0 kommentar(er)
