我が家のサーバは、NAS（Samba）としてだけではなく、ありとあらゆるサービスが動いている。
NAS内の大きなファイルを開こうとするときに、待ち時間が長い事が気になっており、MySQLが原因ではないかと疑っていた。（Wi-FIルータもかなり怪しいが）
中でも、ZabbixがMySQLを使用しており、ハードディスクのI/Oの大半を占めている。
今回、家で使われていなかった古いSSDをサーバにマウントし、MySQLのデータベースファイルをそこに移動したため、結果を記載しておく。
SSDのスペック
家で使われていなかったSSDは、CFDのCSSD-SM30NJという製品だ。
SATAⅡ SSD 30GB MLC Read 150 MB/s, Write90 MB/sで、今見ると非常にスペックが低い。
HDDの方が速いまである。
まあMySQL専用なので、問題無いだろう思い、サーバのSATAの空きポートに接続した。
SSDのマウント
サーバを起動させ、dmesgを確認してみる。
# dmesg (snip) [ 5.056274] ata2: SATA max UDMA/133 abar m2048@0xc1415000 port 0xc1415180 irq 120 [ 5.365207] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 5.365905] ata2.00: ATA-8: SiliconHardDisk, 02.10102, max UDMA/100 [ 5.365911] ata2.00: 62586880 sectors, multi 0: LBA [ 5.367155] ata2.00: configured for UDMA/100 [ 5.369392] scsi 1:0:0:0: Direct-Access ATA SiliconHardDisk 0102 PQ: 0 ANSI: 5 [ 5.419180] scsi 1:0:0:0: Attached scsi generic sg1 type 0 [ 5.444521] sd 1:0:0:0: [sdb] 62586880 512-byte logical blocks: (32.0 GB/29.8 GiB) [ 5.444556] sd 1:0:0:0: [sdb] Write Protect is off [ 5.444562] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 5.444611] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 5.843502] sdb: sdb1 [ 5.844346] sd 1:0:0:0: [sdb] Attached SCSI disk
無事認識し、使用できそうだ。
しかし、本当にSATAⅡなんだなと感じた。
次にSSDをフォーマットする。
# ls /dev/sdb
/dev/sdb
# mkfs.xfs /dev/sdb1
mkfs.xfs: /dev/sdb1 appears to contain an existing filesystem (exfat).
mkfs.xfs: Use the -f option to force overwrite.
# mkfs.xfs /dev/sdb1 -f
meta-data=/dev/sdb1 isize=512 agcount=4, agsize=1955648 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=0 inobtcount=0
data = bsize=4096 blocks=7822592, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=3819, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
/var/ssdをマウントポイントにする。
# mkdir /var/ssd # vi /etc/fstab /dev/sdb1 /var/ssd defaults 0 0 ←追記 # mount -a
MySQLのデータを移動
/var/lib/mysqlをMySQLのデータ移動先にする。
# mkdir /var/ssd/mysql # chmod 755 /var/ssd/mysql/ # chown mysql. /var/ssd/mysql/
データをコピーし、MySQLを設定を変え、起動させる。
# systemctl stop mysqld # cp -rfp /var/lib/mysql/* /var/ssd/mysql/ # vi /etc/my.cnf.d/mysql-server.cnf [mysqld] datadir=/var/lib/mysql ↓ datadir=/var/ssd/mysql # systemctl start mysqld
問題なく、MySQLが起動した。
結果
まず、体感速度しては、NASからのデータ読み込みが早くなっている気がする。
他にも、複数のファイルを多重で読み出す際の待ち時間が無くなっている気もしている。
体感の話だけでは微妙なので、Zabbixのグラフを確認する。
移動前
移動後
SSDにデータを移動してから、iowaitが4%から1%に減っている。
CPUの待ち時間が減っているため、全体のパフォーマンスが上がったと言って良いかもしれない。
Trimを確認してみる
Trimは、SSD内の未使用データを削除し、その領域に再びデータを書き込めるようにする機能だ。
もし、Trimを使わず未使用領域が無くなった場合は、データを一旦消してから書き込む動作になる。
これにより一瞬PCが止まったような挙動を見せるのが、通称プチフリだ。
MySQLのデータは、上書きが何度もされるため、未使用領域が少なくなる可能性が高い。
Trimの設定は必須だろう。
Trimは、OSとSSDの両方で対応している必要がある。
OSであるCentOS Stream 8はもちろん対応している。
SSDの方は以下のように確認すると良いそうだ。
早速打ってみる。
# hdparm -I /dev/sdb | grep TRIM
ん？何もでない。
# hdparm -I /dev/sdb
(snip)
Commands/features:
Enabled Supported:
* SMART feature set
* Power Management feature set
Write cache
Look-ahead
* Mandatory FLUSH_CACHE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Host-initiated interface power management
* Phy event counters
『Data Set Management TRIM supported (limit 8 block)』が無い！！
まあ、何とかなるだろう…。
SSDは良いものを使うに越したことはない。
kusoneko.blogspot.com