Flash Cache Management
This chapter describes how to configure a flash cache for SSVR instances using flash devices on storage nodes and use it efficiently.
Overview
SSVR instances support flash devices as caches.
Flash devices provide fast I/O performance and non-volatile low storage space. There are two ways to write data to the cache: write-through and write-back, as shown in the figure.
write-through
This operation is completed by storing data in both disk and cache.
write-back
The operation is completed by storing the data only in the cache.
The write-back method has the advantage of faster I/O speeds because it does not write to disk . On the other hand, it has the disadvantage that the contents of the cache must be flushed to disk at a later time. This is called the checkpointing process.
ZetaData's flash cache uses a write-back method to enhancing the write I/O speed.
Flash Cache Checkpoint
Using the write-back caching algorithm may result in inconsistency between the cache data and the disk data.
Blocks that contain data are called dirty blocks. Dirty blocks are synchronized to disk by the cache exchange algorithm in order of oldest dirty blocks at the time the cache runs out. The operation of synchronizing dirty blocks to disk is called a checkpoint. Synchronized dirty blocks become clean blocks.
If the percentage of free blocks is insufficient, old blocks among the clean blocks are selected to become free blocks and can be used to cache new I/O requests. Checkpoints are usually performed automatically by the cache replacement policy. Admin can also manually direct checkpoints.
The following is a DDL to manually checkpoint the flash cache.
$ tbsql sys/tibero
tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Connected to Tibero.
SQL> alter flashcache checkpoint;
altered.
SQL>Flash cache removal
A flash cache must be removed when a user does not want to use it.
To maintain consistency of a flash cache, there must not be a dirty block. Executing a flash cache removal command performs a checkpoint. After checkpointing is completed, the flash cache is normally removed.
The following is a DDL to remove the flash cache.
$ tbsql sys/tibero
tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Connected to Tibero.
SQL> drop flashcache flash0;
dropped.
SQL>Flash cache initialization parameters
The following describes the parameters related to flash cache performance.
SSVR_FC_WS_CNTs. It is recommended to set the number of working sets to the same number of CPUs.
Defines the number of working sets. If not set, it will be the same as the number of CPUs, so it is not necessary to set it. It is recommended to set the number of in the working set to be the same as the number of CPUs.
SSVR_FC_FREE_BIN_RATIO
Flash cache changes cache blocks that have not been accessed for a long time to free blocks.
parameter defines the percentage of free blocks that should be freed. A large value has the advantage of reducing the latency of obtaining free blocks by freeing them in advance, but has the disadvantage of truncating the number of cached blocks . (Default: 10%)
SSVR_FC_DIRTY_BIN_RA TIO_MAX
Defines the maximum percentage (%) of dirty blocks to keep in the flash cache.
If more than this percentage of dirty blocks are present, the Background Thread performs checkpoints to maintain the defined maximum percentage of dirty blocks. (Default: 80%)
Flash Cache Creation Information check
The following is to verify the creation information for your flash cache.
$ tbsql sys/tibero
tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Connected to Tibero.
SQL> select * from V$SSVR_FLASHCACHE;
FLASHCACHE_NUMBER NAME PATH OS_BYTES
----------------- ----------------------- -------------------------- -----------
0 FLASH1 /dev/zeta-flash1 5.3687E+10
1 FLASH2 /dev/zeta-flash2 5.3687E+10
2 FLASH3 /dev/zeta-flash3 5.3687E+10
3 rows selected.
SQL>
Last updated