How to resolve fsflush overhead as large sized memory mapped

To reduce the I/O on Solaris platform, Solaris does
offer virtual file system which is memory-based file systems
that provide access to kernel specific resources.
As the name indicates,virtual file systems do not
use file system disk space. However, tmpfs use the
swap space on a disk. tmpfs is the default file system
type for the /tmp directory in the Solaris.

Since uses local memory for file system reads and writes,
it has much more lower latency than using classic Solaris
UFS. I/O performance can be enhanced by reduced I/O
to a local disk or across the network in order to significantly
speed up their creation, manipulation etc. Therefore, tmpfs
can be utlized for the memory mapping.

Files in TMPFS file systems are votial. The files will be dispeared
as the file system is unmounted and when the system is shut down
or rebooted. Files can be moved into or out of the /tmp directory.
This means KTS needs to ensure completed process image backup
as normal fsflush does.

Please note that tmpfs uses swap space for pageout. Process will
be executed as system does not have enough swap space. Which means
it requires larger swap space for pagout.


Other than Solaris built-in kernel modules, Sun Storage Cache also can
be utlized to reduce the latency of the I/O activities.


To ensure no paging on Solaris platform, shmop(2) with shmget(2)
and Intimate Shared Memory variant of System V shared
memory. ISM* *mappings are created with the SHM_SHARE_MMU flag.
This locks down the memory used. Then just read the file
into shared memory. But this may result in code change.



If this is not an option you can tune the flusher with system parameters

set segspt_minfree
set swapfs_minfree
set lotsfree
set desfree
set minfree

You can also postpone the time between cleaning with

set autoup