![]() ![]() I won’t go into much more detail on the TLBs inner workings, as that is a complex subject. If we wanted to be a bit more precise, the MMU does not actually check for a matching page, but uses Content Addressable Memory (CAM) to try to match the requested page, and if matched, this is a TLB hit. As the TLB is hardware based, the memory mapping is really quick it typically costs 0.5 – 1 clock cycle on most modern hardware. If the memory translation values are already present in the TLB, the requested mapping is already cached and nothing more needs to be done. When a process tries to access a memory address within a memory page, the CPU, or more accurately the Memory Management Unit (MMU) of each CPU core, checks to see if that specific logical memory page is currently mapped to the physical memory page via the Translation Lookaside Buffers (TLB), which is a fairly small hardware based cache on the MMU. There are four potential scenarios with page mapping. 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. 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. ![]()
0 Comments
Leave a Reply. |