Swap is intentionally disabled in FlashGrid Cluster/Server environments. The rationale for this is that when system is low on memory swapping may happen, even when there is some physical memory still available, and this will cause system to be unresponsive and potentially causing timeouts at various levels including storage. While swapping may prevent or delay running out of memory, the results of swapping are likely to be worse than the results of running out of memory.
Performance impact with swap enabled
Cache in the Swap File will increase I/O compared to just having less cache. If you run out of memory and need to use swap, first you have to find space to swap in the page which means swapping out some page. When the page is swapped you have the second I/O and finally you get page being cached read from the hard drive to the cache. This gives us 3 I/Os instead of one. Flushing dirty pages or even discarding the page will cause extra I/O slowing things down.
Escalated Locking/Latching. In highly concurrent environments database Locks/Latches are typically designed to be held for as short time as possible. The less portion of execution time thread spends holding exclusive locks the better system will scale. It is a big problem to hold any critical locks while you’re doing disk I/O as I/Os take a long time. When the system is swapping all of these gets messed up. When database is thinking it is taking the locks for few instructions only it can be a long time while I/O completes, if this is a critical lock it is possible to see everything in the system waiting on this I/O, even transactions that work with data which is not in the swap file.
Skewing up all Algorithms. The database internal algorithms are tuned for things being in memory and if they start dealing with data that is on disk they just often stop working with any reasonable level of efficiency. When database deals with on-disk data it often uses a different set of algorithms that are optimized to limit the number of I/Os or make them more sequential.
Reliability risks of swap enabled
During active swapping, the system may freeze for several seconds or even minutes. During this time it will be effectively unresponsive causing time-outs at various levels. But because the system might keep freezing and then unfreezing, the HA mechanisms may not recognize it as non-functional. As a result, there may be no quick eviction or failover, but the performance may be close to zero, so we have a "brown-out" situation. In contrast, if out-of-memory is allowed to occur then the system will reboot automatically and the failover mechanisms will be able to do their job.
When swap is needed
Some Oracle provided scripts/utilities may fail or report warnings if swap space is not configured, such as dbca, opatchauto, Oracle Universal Installer (OUI), etc. There are usually some keys that can avoid swap checks, for instance, -ignoreSysPrereqs. It is also possible to create swap space temporarily, perform the action that needs swap, then disable swap.
1. Create a temporary 1GB swapfile:
# dd if=/dev/zero of=/swapfile bs=1024k count=1024 oflag=direct # chown root:root /swapfile # chmod 600 /swapfile # mkswap /swapfile
2. Activate the swap file
# swapon /swapfile
3. perform the action that needs swap and return back to this page
4. Deactivate the swap file
# swapoff /swapfile
It is important to note that you should not leave the swap file enabled after maintenance. The swap file should be activated prior to maintenance only and then deactivated afterward. Failing to deactivate the swap file can result in performance issues and instability in the system.
Keywords: memory