更新

2019/04/10 调整定时任务频率以应对内存泄露过快问题

2019/03/30 增加 cron 任务重启 Unity Cache Server

2019/03/28 初次发布

问题

Jira 无法访问，表现为浏览器无法连接，输入地址后无法连接。

初步排查分析：

安装在服务器上的 Jira 无法访问，其他服务 Jenkins、GitLab 也无法访问。

服务器无法使用 SSH 连接，也无法在本地登录，处于卡死状态。

强制关机后再开机，访问 Jira 提示无法访问数据库错误。

在服务器连接的显示器上发现登录界面充满着磁盘读取错误，并且无法输入账号密码登录。

确认是磁盘读取错误导致以上故障。但是又是什么原因导致磁盘读取错误呢？！先修复磁盘读取错误再说。

查找问题过程

但是很奇怪的是，居然可以远程 SSH 连接到服务器，因此以下大部分操作都是远程使用 SSH 登录进行的：

查看 MySQL 服务状态，并未处于正常工作状态：

1234567891011121314

# systemctl status mysqld

● mysqld.service - MySQL Server

Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)

Active: activating (start) since Thu 2019-03-28 11:18:57 CST; 3s ago

Docs: man:mysqld(8)

http://dev.mysql.com/doc/refman/en/using-systemd.html

Process: 16135 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)

Control: 16158

CGroup: /system.slice/mysqld.service

└─16161 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

Mar 28 11:18:57 centos systemd[1]: Starting MySQL Server...

Mar 28 11:19:00 centos mysqld[16158]: Initialization of mysqld failed: 0

Mar 28 11:19:00 centos systemd[1]: mysqld.service: control process exited, code=exited status=1

尝试连接数据库，提示：

123

# mysql -u root -p

Enter password:

ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 104

重启 MySQL

123

# systemctl stop mysqld

# systemctl start mysqld

Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

运行 journalctl -xe 会显示以下错误，默认情况下输出会用彩色输出，重点信息会使用红色字体显示。

1234567891011121314151617

Mar 28 11:48:26 centos kernel: ata1.00: exception Emask 0x0 SAct 0xc000000 SErr 0x0 action 0x0

Mar 28 11:48:26 centos kernel: ata1.00: irq_stat 0x40000008

Mar 28 11:48:26 centos kernel: ata1.00: failed command: READ FPDMA QUEUED

Mar 28 11:48:26 centos kernel: ata1.00: cmd 60/08:d0:b8:35:dd/00:00:6f:00:00/40 tag 26 ncq 4096 in

res 41/40:08:b8:35:dd/00:00:6f:00:00/00 Emask 0x409 (media error)

Mar 28 11:48:26 centos kernel: ata1.00: status: { DRDY ERR }

Mar 28 11:48:26 centos kernel: ata1.00: error: { UNC }

Mar 28 11:48:26 centos kernel: ata1.00: configured for UDMA/133

Mar 28 11:48:26 centos kernel: sd 0:0:0:0: [sda] tag#26 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Mar 28 11:48:26 centos kernel: sd 0:0:0:0: [sda] tag#26 Sense Key : Medium Error [current] [descriptor]

Mar 28 11:48:26 centos kernel: sd 0:0:0:0: [sda] tag#26 Add. Sense: Unrecovered read error - auto reallocate failed

Mar 28 11:48:26 centos kernel: sd 0:0:0:0: [sda] tag#26 CDB: Read(10) 28 00 6f dd 35 b8 00 00 08 00

Mar 28 11:48:26 centos kernel: blk_update_request: I/O error, dev sda, sector 1876768184

Mar 28 11:48:26 centos kernel: ata1: EH complete

Mar 28 11:48:26 centos mysqld[6370]: Initialization of mysqld failed: 0

Mar 28 11:48:26 centos systemd[1]: mysqld.service: control process exited, code=exited status=1

Mar 28 11:48:27 centos systemd[1]: Failed to start MySQL Server.

核心错误信息：blk_update_request: I/O error, dev sda, sector 1876768184，日志中磁盘访问的多次错误指向的都是同一个磁盘位置。

反复重启 MySQL 多次都是一样的错误。

环境

macOS 10.14.3

CentOS 7.6 1810

SystemRescueCD 6.0.2

修复磁盘读取错误

修复尝试

MySQL 默认安装到系统盘，数据文件并未修改位置因此也在系统盘。

输出磁盘信息：

1234567891011121314

# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sda 8:0 0 931.5G 0 disk

├─sda1 8:1 0 200M 0 part /boot/efi

├─sda2 8:2 0 1G 0 part /boot

└─sda3 8:3 0 930.3G 0 part

├─centos-root 253:0 0 50G 0 lvm /

├─centos-swap 253:1 0 7.8G 0 lvm [SWAP]

└─centos-home 253:2 0 872.6G 0 lvm /home

sdb 8:16 0 477G 0 disk

└─sdb1 8:17 0 477G 0 part /data

# lsscsi

[0:0:0:0] disk ATA ST1000DM010-2EP1 CC43 /dev/sda

[1:0:0:0] disk ATA Samsung SSD 860 1B6Q /dev/sdb

检查磁盘 SMART 状态：

123456

# yum install smartmontools

# smartctl --all /dev/sda

...

=== START OF READ SMART DATA SECTION ===

SMART overall-health self-assessment test result: PASSED

...

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455

# lvscan

ACTIVE '/dev/centos/swap' [7.75 GiB] inherit

ACTIVE '/dev/centos/home' [<872.56 GiB] inherit

ACTIVE '/dev/centos/root' [50.00 GiB] inherit

# lvdisplay

--- Logical volume ---

LV Path /dev/centos/swap

LV Name swap

VG Name centos

LV UUID F3L08d-MoMj-i95k-rfAq-plaA-XTmp-CZSaey

LV Write Access read/write

LV Creation host, time localhost, 2019-01-22 15:16:07 +0800

LV Status available

# open 2

LV Size 7.75 GiB

Current LE 1984

Segments 1

Allocation inherit

Read ahead sectors auto

- currently set to 256

Block device 253:1

--- Logical volume ---

LV Path /dev/centos/home

LV Name home

VG Name centos

LV UUID fvtd5E-06YL-Sj8K-xTrE-USHa-IorI-Wa2nRm

LV Write Access read/write

LV Creation host, time localhost, 2019-01-22 15:16:08 +0800

LV Status available

# open 1

LV Size <872.56 GiB

Current LE 223375

Segments 1

Allocation inherit

Read ahead sectors auto

- currently set to 256

Block device 253:2

--- Logical volume ---

LV Path /dev/centos/root

LV Name root

VG Name centos

LV UUID sh4wLi-nSsR-PwXs-Pn4U-g0BR-CyeI-6URLuu

LV Write Access read/write

LV Creation host, time localhost, 2019-01-22 15:16:12 +0800

LV Status available

# open 1

LV Size 50.00 GiB

Current LE 12800

Segments 1

Allocation inherit

Read ahead sectors auto

- currently set to 256

Block device 253:0

尝试手动执行一部分命令修复磁盘提示：

12345

# xfs_repair /dev/centos/root

xfs_repair: /dev/centos/root contains a mounted filesystem

xfs_repair: /dev/centos/root contains a mounted and writable filesystem

fatal error -- couldn't initialize XFS library

由于无法直接修复正在使用的磁盘，因此尝试使用 Linux 启动U盘离线修复，参考以下文章的做法，使用 SystemRescueCD。

下载镜像

下载 SystemRescueCd 最新版本

制作启动 U 盘

在 macOS 终端中执行：

1234567891011121314151617181920

$ diskutil list

/dev/disk0 (internal):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme 500.3 GB disk0

1: EFI EFI 314.6 MB disk0s1

2: Apple_APFS Container disk1 500.0 GB disk0s2

/dev/disk1 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +500.0 GB disk1

Physical Store disk0s2

1: APFS Volume Macintosh HD 171.4 GB disk1s1

2: APFS Volume Preboot 45.3 MB disk1s2

3: APFS Volume Recovery 517.0 MB disk1s3

4: APFS Volume VM 4.3 GB disk1s4

/dev/disk2 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *3.9 GB disk2

1: Windows_FAT_32 JUSTIN 3.9 GB disk2s1

必须先卸载 U 盘，注意：网上其他文章介绍的方法 sudo umount /dev/disk2 无法生效，会提示 umount: /dev/disk2: not currently mounted

123456789

$ diskutil unmountDisk /dev/disk2

Unmount of all volumes on disk2 was successful

$ sudo dd if=~/Downloads/systemrescuecd-6.0.2.iso of=/dev/rdisk2 bs=1m

871+0 records in

871+0 records out

913309696 bytes transferred in 167.405588 secs (5455670 bytes/sec)

$ diskutil eject /dev/disk2

注意：在设置名称前面增加 r 可以显著提升速度，因为这样会跳过操作系统的磁盘缓存。

Note the “r” prefix on the device names – this bypasses the OS disk buffers, and in my experience makes dd run much faster.

注意：Windows 用户可以自行参考官方文档制作启动 U 盘

修复

修改机器的启动顺序，将 U 盘放到第一位。然后插入启动 U 盘启动。

在 SystemRescueCD 启动菜单中选择第一项 default boot options 后等待启动完成。

由于机器默认能启动，只是访问不了某些文件，因此在尝试挂载时发现可以成功挂载

123

# mount /dev/centos/root /mnt

# ls /mnt

...

执行修复

1

# xfs_repair /dev/centos/root

输出中并未有什么明显的提示说明出错，只是提到修复了某些东西。

移除 U 盘后重启进入系统，可以看到系统正常工作，MySQL、Jira、GitLab、Jenkins 也都已恢复正常工作。

修复内存占用过高

查看内存占用

在后续使用 Jira 的过程中，突然再次发现 Jira 响应极慢，马上 SSH 登录服务器，发现 used 内存过高，几乎占据了所有内存，而且结果中出现了正常不会有的虚拟内存信息：

1234

# free -h

total used free shared buff/cache available

Mem: 15G 14G 152M 131M 573M 214M

Swap: 7.7G 2.2G 5.6G

注意：默认情况下不会使用基于磁盘的虚拟内存，一旦使用就会造成系统响应速度极大下降，当出现卡顿时优先考虑内存问题。

查看进程内存大小

尝试按照占用内存大小输出进程信息：

12345678910

# ps aux --sort -rss

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

unity 5946 0.0 14.3 4166772 2310272 ? Sl Mar28 0:31 /usr/bin/node /bin/unity-cache-server --NODE_CONFIG_DIR=/data/unity-cache-server/config

root 5873 1.1 13.9 6510320 2255416 ? Sl Mar28 19:23 /usr/bin/java -Djava.util.logging.config.file=/opt/atlassian/jira/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms384m -Xmx2048m -XX:InitialCodeCacheSize=32m -XX:ReservedCodeCacheSize=512m -javaagent:/opt/

unity 5927 0.0 13.1 3648680 2113632 ? Sl Mar28 0:57 /usr/bin/node /bin/unity-cache-server --NODE_CONFIG_DIR=/data/unity-cache-server/config

unity 5934 0.0 11.1 3208120 1797668 ? Sl Mar28 0:28 /usr/bin/node /bin/unity-cache-server --NODE_CONFIG_DIR=/data/unity-cache-server/config

jenkins 6031 0.6 7.0 7925472 1132532 ? Ssl Mar28 10:54 /etc/alternatives/java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --httpPort=5000 --debu

unity 5916 0.0 6.5 2170168 1061960 ? Sl Mar28 0:33 /usr/bin/node /bin/unity-cache-server --NODE_CONFIG_DIR=/data/unity-cache-server/config

git 6310 2.5 3.8 1027228 626400 ? Ssl Mar28 43:04 sidekiq 5.2.5 gitlab-rails [0 of 25 busy]

git 17623 0.0 2.9 798756 472748 ? Sl Mar28 1:14 unicorn worker[1] -D -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru

终止问题进程

发现排在前面的是 Unity Cache Server，很奇怪 Unity 缓存服务器怎么会占用这么多的内存？停止服务后可以看到内存占用降低了一半！

12345

# systemctl stop unity-cache-server

# free -h

total used free shared buff/cache available

Mem: 15G 7.0G 7.8G 131M 576M 7.9G

Swap: 7.7G 2.0G 5.7G

升级 Unity Cache Server

查看 Unity Cache Server 版本，发现是 v6.2.4，去官网发布页面 Releases · Unity-Technologies/unity-cache-server 可以看到最新版本已经是 v6.3.0 了，而且在 v6.2.5 版本中修复了工作者进程占用内存过高的 Bug：

Reduced high memory usage in worker processes (#95)

果断升级：

1234567891011121314151617

# systemctl stop unity-cache-server

# unity-cache-server --version

6.2.4

# curl -sL https://rpm.nodesource.com/setup_10.x | bash -

# sudo yum install -y nodejs

# npm update -g unity-cache-server

/usr/bin/unity-cache-server -> /usr/lib/node_modules/unity-cache-server/main.js

/usr/bin/unity-cache-server-cleanup -> /usr/lib/node_modules/unity-cache-server/cleanup.js

/usr/bin/unity-cache-server-import -> /usr/lib/node_modules/unity-cache-server/import.js

+ unity-cache-server@6.3.0

updated 2 packages in 7.147s

# unity-cache-server --version

6.3.0

# systemctl start unity-cache-server

注意：v6.3.0 同时升级了 Nodejs 版本

启动 Unity Cache Server

1

# systemctl start unity-cache-server

依然存在内存泄露

虽然 v6.2.5 版本的更新日志中说明修复了占用内存过高的 Bug，但是 v6.3.0 版本在使用的时候依然会出现内存占用过高的问题，由于 Unity Cache Server 并不需要连续运行，而且就算是 Unity 在使用时重启也只会导致当前资源下载失败，然后 Unity 会重新导入资源。

123

crontab -e

30 */6 * * * systemctl restart unity-cache-server

使用 cron 定时任务在 00:30 重启服务器，之后每隔 6 小时重启一次。选择这个时间主要是考虑到中午休息的时候并不会有很多人在用，一天 4 次的频率也是考虑到内存增长的实际情况，如果超过 6 小时不清理一次可能内存就占用就会涨得太多了。