Using gdb, we were able to call malloc_trim directly (without making any code changes) and the results were very encouraging. We decided to run some experiments with malloc_trim to see if it would help. There is a Linux specific function called ‘malloc_trim’ that can be used to force release of freed memory from the heap back to the operating system. This can have major memory usage implications especially for long running applications. By default, glibc’s allocator implementation does not always release freed memory on the heap back to the OS. malloc_trimĪn online search revealed that other folks have run into similar memory release issues with Linux. On Windows, calling delete/free reduced the memory footprint of the process and returned memory back to the OS. The same code was behaving very differently when it came to releasing memory back to the operating system. Our initial thought was that sessions were not getting cleaned up as expected on Linux but after some more troubleshooting we ruled out that theory. Interestingly, on Linux, we did not observe this large drop in memory. This was expected since sessions are memory intensive. On Windows, when a VizQL session expired, we saw the memory usage of the vizqlserver process drop significantly. When investigating a customer issue related to memory usage, we noticed a marked difference between memory patterns on Windows as compared to Linux. Session expiry not releasing memory on Linux ![]() To prevent restarts of processes in production (Tableau Online and Tableau Public), we have had to provision machines with very high memory capacity. Having said that, a restart due to excessive memory usage is undesirable because it interrupts the workflow of users. A node in a Tableau Server cluster typically hosts multiple processes, so these restarts are sometimes necessary to keep a single process from using up all the resources on that node. Memory intensive processes within Tableau Server have a watchdog thread that continually monitors memory usage and terminates processes as needed to keep the overall node healthy. Specifically, VizQL sessions are stored in memory and they can take up a lot of space. Within Tableau Server the component that is responsible for rendering the viz (the vizqlserver process) can be memory intensive. Notice the significant drop in restarts after the code was deployed. ![]() It shows a trend of the number of times applications were restarted due to excessive memory consumption. The image below is based on data from one of our Tableau Online production pods. We will talk about how a single function call dramatically reduced the memory footprint of Tableau Server processes on Linux and helped us improve stability and availability of our services. This blog post is an attempt to shed light on one such difference related to memory usage patterns. As we continue to support both operating systems, there are times when we run into interesting differences between how Tableau Server operates on Windows versus Linux. Our hosted offering, Tableau Online, and our free platform, Tableau Public, both run on Linux. those who choose to host their own Tableau Server instances) the flexibility to pick an operating system of their choice. Tableau Server supports both Windows and Linux and provides on-premise customers (i.e. Controlling Memory Usage By Forcing Release of Freed Memory
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |