Swap is intentionally disabled in FlashGrid Cluster/Server environments. The rationale for this is that when the system is low on memory, swapping may happen, even when there is some physical memory still available. This will cause the system to be unresponsive and potentially cause 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
Caching 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, the following happens:
1) Pages currently residing in swap need to be swapped out
2) Pages in cache are placed in the swap
3) Data is read from disk into cache
This gives us 3 I/O's instead of one. Flushing dirty pages or even discarding the page will cause extra I/O, slowing things down even more.
Escalated Locking/Latching
In highly concurrent environments, database locks/latches are typically designed to be held for as short a time as possible. The less portion of execution time the thread spends holding exclusive locks, the better the system will scale. There are high-performance impacts associated with holding any critical locks while performing disk I/O as I/O's take much longer times to complete than memory access. When the system is swapping, performance is greatly affected because when the database is thinking it is taking the locks for a 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 that 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 often just 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 swap file:
# 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.
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 afterwards. Failing to deactivate the swap file can result in performance issues and instability in the system.
Keywords: memory