分区性能监控

本文介绍 SequoiaDB 巨杉数据库中，进行数据分区的性能监控，比较全面地了解 SequoiaDB 巨杉数据库的运行状况。

数据量的均衡

在 SequoiaDB 中，通过分区键将数据打散到不同的数据分区中，不同数据分区内数据量的大小，将直接影响到数据分区的性能。不同分区键数据量的均衡，可以有效提高数据库的整体性能。不同分区数据量的多少可以通过查看不同节点下的数据文件大小进行判断，在不同数据节点下，数据文件大小差距过大，则判断为数据失衡。 通常情况下，SequoiaDB 每个数据节点对应一块磁盘，可以通过 df 命令查看磁盘使用情况，确定数据量是否均衡。

  1. # df -h
  2. Filesystem             Size  Used Avail Use% Mounted on
  3. /dev/mapper/rhel-root   50G   42G  8.3G  84% /
  4. devtmpfs                32G     0   32G   0% /dev
  5. tmpfs                   32G   84K   32G   1% /dev/shm
  6. tmpfs                   32G  450M   32G   2% /run
  7. tmpfs                   32G     0   32G   0% /sys/fs/cgroup
  8. /dev/mapper/rhel-home   42G   22G   21G  52% /home
  9. /dev/sda               497M  140M  358M  29% /boot
  10. /dev/sdb               1.2T  140M  1.2T   1% /sdbdata/disk1
  11. /dev/sdc               1.2T  140M  1.2T   1% /sdbdata/disk2
  12. /dev/sdd               1.2T  140M  1.2T   1% /sdbdata/disk3
  13. /dev/sde               1.2T  140M  1.2T   1% /sdbdata/disk4
  14. tmpfs                  6.3G   16K  6.3G   1% /run/user/42
  15. tmpfs                  6.3G     0  6.3G   0% /run/user/0
  16. tmpfs                  6.3G     0  6.3G   0% /run/user/1001

Note:

主要关注磁盘的使用率和不同磁盘间数据量的差异。磁盘使用率超过 70%，需要规划扩容相关内容。磁盘极限占用率推荐为 80%，预留一定的存储空间。如果发现 SequoiaDB 数据节点所在的磁盘间数据量差距过大，则需要通过分区数据均衡来定位并解决问题。

IO性能的均衡

通过 iostat 命令监控 IO 性能， 重点观察 %iowait 是否超过 5%，各磁盘读写速度是否相近。

  1. # iostat -xm 5
  2. Linux 3.10.0-123.el7.x86_64 (test)  06/05/2019  _x86_64_    (1 CPU)
  4. avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  5.            0.62    0.00    1.03    0.00    0.00   98.35
  7. Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
  8. scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
  9. sda               0.00     0.00    0.21    0.00     0.00     0.00    16.00     0.00    1.00    1.00    0.00   1.00   0.02
  10. dm-0              0.00     0.00    0.21    0.00     0.00     0.00    16.00     0.00    1.00    1.00    0.00   1.00   0.02
  11. dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

CPU使用率监测

通过 top 命令监控 CPU 使用率，重点观察 CPU 使用率是否可以达到较高水平，但是 sys% 不应该超过 usr% 的 50%。

  1. # top -c
  2. top - 01:37:33 up  1:43,  4 users,  load average: 0.02, 0.10, 0.12
  3. Tasks: 406 total,   1 running, 405 sleeping,   0 stopped,   0 zombie
  4. %Cpu(s):  1.4 us,  1.7 sy,  0.0 ni, 97.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  5. KiB Mem:   2902952 total,  2882112 used,    20840 free,        4 buffers
  6. KiB Swap:  2097148 total,     6664 used,  2090484 free.  1890884 cached Mem
  8.    PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                                                      
  9.   7475 sdbadmin  20   0  123892   2008   1236 R  1.3  0.1   0:00.15 top -c 
  10.   4534 sdbadmin  20   0 1706116  87136  13544 S  0.7  3.0   0:22.02 sequoiadb(11830) D 
  11.   4537 sdbadmin  20   0 1848192 111804  18016 S  0.7  3.9   0:14.70 sdbom(11780)
  12.   4545 sdbadmin  20   0  837180  85492  13836 S  0.7  2.9   0:22.63 sequoiadb(11810) S 
  13.   4551 sdbadmin  20   0 2490824  93316  14608 S  0.7  3.2   0:25.89 sequoiadb(11800) C
  14.   4542 sdbadmin  20   0 1706116 116440  21784 S  0.3  4.0   0:23.83 sequoiadb(11820) D
  15.   4548 sdbadmin  20   0 2099332 124368  21788 S  0.3  4.3   0:24.33 sequoiadb(11840) D
  16.   ...

分区健康检查

当磁盘 I/O 和 CPU 使用率均正常，但 SequoiaDB 的数据分区依然无法正常提供服务时，需要进行分区健康检查。

  1. > db.snapshot( SDB_SNAP_HEALTH, { GroupName: "group1" } )
  2. {
  3.   "NodeName": "sdbserver1:11820",
  4.   "IsPrimary": true,
  5.   "ServiceStatus": true,
  6.   "Status": "Normal",
  7.   "BeginLSN": {
  8.     "Offset": 1342177280,
  9.     "Version": 6
  10.   },
  11.   "CurrentLSN": {
  12.     "Offset": 2657251884,
  13.     "Version": 9
  14.   },
  15.   "CommittedLSN": {
  16.     "Offset": 2657251884,
  17.     "Version": 9
  18.   },
  19.   "CompleteLSN": 2657251968,
  20.   "LSNQueSize": 0,
  21.   "NodeID": [
  22.     1000,
  23.     1000
  24.   ],
  25.   "DataStatus": "Normal",
  26.   "SyncControl": false,
  27.   "Ulimit": {
  28.     "CoreFileSize": 0,
  29.     "VirtualMemory": -1,
  30.     "OpenFiles": 60000,
  31.     "NumProc": 257587,
  32.     "FileSize": -1
  33.   },
  34.   "ResetTimestamp": "2019-05-29-17.04.24.775434",
  35.   "ErrNum": {
  36.     "SDB_OOM": 0,
  37.     "SDB_NOSPC": 0,
  38.     "SDB_TOO_MANY_OPEN_FD": 0
  39.   },
  40.   "Memory": {
  41.     "LoadPercent": 2,
  42.     "TotalRAM": 67556651008,
  43.     "RssSize": 1784561664,
  44.     "LoadPercentVM": 45,
  45.     "VMLimit": 65878863872,
  46.     "VMSize": 29887328256
  47.   },
  48.   "Disk": {
  49.     "Name": "/dev/mapper/rhel-root",
  50.     "LoadPercent": 83,
  51.     "TotalSpace": 53660876800,
  52.     "FreeSpace": 8917061632
  53.   },
  54.   "FileDesp": {
  55.     "LoadPercent": 0,
  56.     "TotalNum": 60000,
  57.     "FreeNum": 59921
  58.   },
  59.   "StartHistory": [
  60.     "2019-05-29-17.04.25.211680",
  61.     "2019-05-27-11.28.00.190238",
  62.     "2019-04-27-22.04.03.000814",
  63.     "2019-04-27-22.00.23.301800"
  64.   ],
  65.   "AbnormalHistory": [],
  66.   "DiffLSNWithPrimary": 0
  67. }
  68. {
  69.   "NodeName": "sdbserver1:11820",
  70.   "IsPrimary": false,
  71.   "ServiceStatus": true,
  72.   "Status": "Normal",
  73.   "BeginLSN": {
  74.     "Offset": 1342177280,
  75.     "Version": 6
  76.   },
  77.   "CurrentLSN": {
  78.     "Offset": 2657251884,
  79.     "Version": 9
  80.   },
  81.   "CommittedLSN": {
  82.     "Offset": 2657251884,
  83.     "Version": 9
  84.   },
  85.   "CompleteLSN": 2657251968,
  86.   "LSNQueSize": 0,
  87.   "NodeID": [
  88.     1000,
  89.     1001
  90.   ],
  91.   "DataStatus": "Normal",
  92.   "SyncControl": false,
  93.   "Ulimit": {
  94.     "CoreFileSize": 0,
  95.     "VirtualMemory": -1,
  96.     "OpenFiles": 60000,
  97.     "NumProc": 128578,
  98.     "FileSize": -1
  99.   },
  100.   "ResetTimestamp": "2019-05-29-17.04.06.253067",
  101.   "ErrNum": {
  102.     "SDB_OOM": 0,
  103.     "SDB_NOSPC": 0,
  104.     "SDB_TOO_MANY_OPEN_FD": 0
  105.   },
  106.   "Memory": {
  107.     "LoadPercent": 3,
  108.     "TotalRAM": 33737936896,
  109.     "RssSize": 1341104128,
  110.     "LoadPercentVM": 34,
  111.     "VMLimit": 37132955648,
  112.     "VMSize": 12665397248
  113.   },
  114.   "Disk": {
  115.     "Name": "/dev/mapper/rhel-root",
  116.     "LoadPercent": 75,
  117.     "TotalSpace": 53660876800,
  118.     "FreeSpace": 13171359744
  119.   },
  120.   "FileDesp": {
  121.     "LoadPercent": 0,
  122.     "TotalNum": 60000,
  123.     "FreeNum": 59921
  124.   },
  125.   "StartHistory": [
  126.     "2019-05-29-17.04.06.313152",
  127.     "2019-05-27-11.26.27.818497",
  128.     "2019-04-27-22.03.50.506024",
  129.     "2019-04-27-22.00.25.508364"
  130.   ],
  131.   "AbnormalHistory": [],
  132.   "DiffLSNWithPrimary": 0
  133. }

Note:

重点关注分区内每一个节点的 ServiceStatus 是否为 true

分区内节点LSN的一致性

在 SequoiaDB 中，主节点是复制组内唯一接收写操作的成员。当发生写操作时，主节点写入数据，并记录事务日志 replicalog。备节点从主节点异步复制 replicalog，并通过重放 replicalog 来复制数据。主备节点间的同步，使用 LSN 号标识数据的顺序。

主备节点的 LSN 需要尽量保持一致，或者差距很小，才能保证数据库的正常运行。主备节点间 LSN 差距过大，会触发节点间的全量同步。

分区内节点 LSN 的一致性可以通过 sdbinspect 工具进行检测。

  • 查看当前集群所有节点 LSN 版本一致性：
  1. # sdbinspect -d localhost:11810 -o item.bin
  2. inspect done
  3. Inspect result:
  4. Total inspected group count       : 3
  5. Total inspected collection        : 15
  6. Total different collections count : 0
  7. Total different records count     : 0
  8. Total time cost                   : 32904 ms
  9. Reason for exit : exit with no records different