分类： 后端

Linux服务器基准性能测试常用工具

Posted on by bjzhanghao

对Linux服务器做基准测试可以帮助确定服务器在特定任务或负载下的性能。这不仅有助于我们了解服务器的处理能力、响应时间、吞吐量等关键性能指标，也有助于我们进行服务器容量规划，确保服务器在未来的工作负载下仍能保持良好的性能。

本文总结Linux下常用的基准测试工具的使用场景和方法，按硬件组成分为CPU、内存、磁盘和网络四个部分。其中有些工具不是Linux自带的，此时需要先安装工具。以fio为例，在Ubuntu里使用sudo apt-get install fio，在CentOS里则使用sudo yum install fio即可完成安装。

一、CPU基准测试

lscpu - 查看CPU硬件信息

命令lscpu是显示关于 CPU 体系结构信息的一个工具，它从/proc/cpuinfo和其他系统文件中收集数据，汇总并以易于阅读的格式显示，不需要root权限。我们通常用它了解CPU的架构、核数和主频等基本信息：

> lscpu
Architecture:                    aarch64   <-- CPU架构，这里是ARM架构的
CPU op-mode(s):                  64-bit
Byte Order:                      Little Endian
CPU(s):                          128   <-- CPU核心数量128个
On-line CPU(s) list:             0-127
Thread(s) per core:              1  <-- 每核心线程数
Core(s) per socket:              64
Socket(s):                       2  <-- 两个物理CPU插槽
NUMA node(s):                    4  <-- NUMA节点数
Vendor ID:                       0x48
Model:                           0
Stepping:                        0x1
CPU max MHz:                     2600.0000   <-- CPU最大频率
CPU min MHz:                     200.0000
BogoMIPS:                        200.00
L1d cache:                       8 MiB
L1i cache:                       8 MiB
L2 cache:                        64 MiB
L3 cache:                        128 MiB     <-- 三级缓存大小，此缓存是多核共享的
NUMA node0 CPU(s):               0-31
NUMA node1 CPU(s):               32-63
NUMA node2 CPU(s):               64-95
NUMA node3 CPU(s):               96-127
...

其中Core、Socket和NUMA node的概念可以参考下图（来源）：

file

sysbench cpu - 测试CPU性能

使用sysbench工具可以测试CPU的实际性能，它内部是通过反复查找指定范围（默认10000）内所有素数实现的，每完整查找完成一次即为一个事件(event)，默认10秒后输出平均每秒完成的事件次数（eps, events per second）作为衡量CPU性能的指标。

若测试时在命令行里添加--threads参数指定了多线程，则eps指标也会相应上升，简单公平起见我们都用默认单线程测试即可。

> sysbench cpu run
Prime numbers limit: 10000
Initializing worker threads...
Threads started!

CPU speed:
    events per second:  3329.35   <-- 主要关注这个eps指标

General statistics:
    total time:                          10.0002s
    total number of events:              33299

Latency (ms):
         min:                                    0.30
         avg:                                    0.30
         max:                                    0.62
         95th percentile:                        0.31
         sum:                                 9994.03

Threads fairness:
    events (avg/stddev):           33299.0000/0.00
    execution time (avg/stddev):   9.9940/0.00

二、内存基准测试

dmidecode - 查看内存条硬件信息

命令dmidecode从系统的 DMI（Desktop Management Interface）表中读取数据，提供关于系统硬件组件的详细信息，如 主板、BIOS、处理器、内存、缓存、芯片组和其他系统硬件的信息。我们通常用它查看主板上各个内存条的型号、容量、频率等硬件信息。

查看已安装的物理内存条数及容量：

> sudo dmidecode -t memory | grep 'GB'
Size: 32 GB  <-- 单条内存容量32GB
Size: 32 GB
Size: 32 GB
Size: 32 GB

查看已安装的物理内存频率：

> sudo dmidecode -t memory | grep 'MT/s'
Speed: 3200 MT/s                    <-- 物理内存支持的最大频率
Configured Memory Speed: 2933 MT/s  <-- 实际运行频率, 通常是CPU无法支持到内存最高频率导致的
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

在测试内存性能时，需要注意缓存的影响，下图（来源）展示了典型的三级缓存架构。测试项目所处理的数据量应该大大超过缓存的大小，否则就变成了测试缓存的性能。

file

sysbench memory - 测试内存性能

用sysbench工具可以测试内存的实际性能：

> sysbench memory run
Running memory speed test with the following options:
  block size: 1KiB
  total size: 102400MiB
  operation: write
  scope: global

Initializing worker threads...
Threads started!

Total operations: 38967914 (3896177.52 per second)
38054.60 MiB transferred (3804.86 MiB/sec)

General statistics:
    total time:                          10.0002s
    total number of events:              38967914

Latency (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                    0.26
         95th percentile:                        0.00
         sum:                                 4468.85

Threads fairness:
    events (avg/stddev):           38967914.0000/0.00
    execution time (avg/stddev):   4.4688/0.00

三、磁盘基准测试

lsblk - 查看磁盘信息

此命令可列出所有块设备及其属性，且不需要root权限。

> lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 446.6G  0 disk
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 446.1G  0 part /

fdisk - 查看磁盘分区信息

命令fdisk是一个磁盘分区工具，也经常被用于显示磁盘信息，需要root权限。它比lsblk给出的信息更加详细一些，例如包含了每个磁盘分区的大小和文件系统信息。

> sudo fdisk -l
Disk /dev/sda: 446.64 GiB, 479559942144 bytes, 936640512 sectors
Disk model: SAS3908
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes
Disklabel type: gpt
Disk identifier: 6819FBA6-5719-44F1-A2B6-F444F542E8BC

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   1050623   1048576   512M EFI System
/dev/sda2  1050624 936638463 935587840 446.1G Linux filesystem

fio - 测试磁盘性能

fio是一个专业的磁盘性能测试工具。它可以配置多种测试场景，包括顺序读写和随机读写等，我们主要关注IOPS（每秒操作数）和BW（带宽）指标。

以测试顺序读写性能为例：

> fio --rw=rw  --directory=/tmp --size=256m --direct=1 --name=mytest
mytest: (g=0): rw=rw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.7
Starting 1 process
Jobs: 1 (f=1): [M(1)][100.0%][r=1749KiB/s,w=1789KiB/s][r=437,w=447 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=25055: Sun Jun 30 11:44:53 2024
...
Run status group 0 (all jobs):
   READ: bw=1712KiB/s (1753kB/s), 1712KiB/s-1712KiB/s (1753kB/s-1753kB/s), io=128MiB (134MB), run=76476-76476msec
  WRITE: bw=1716KiB/s (1757kB/s), 1716KiB/s-1716KiB/s (1757kB/s-1757kB/s), io=128MiB (134MB), run=76476-76476msec

命令行参数--direct表示是否使用操作系统级的磁盘缓存，默认值1。取0和1对结果影响很大（几十倍），0反映磁盘本身的性能，1更接近实际使用场景。

命令行参数--rw是指定要测试的项目，可选项是以下之一：

: read       Sequential read
: write      Sequential write
: trim       Sequential trim
: randread   Random read
: randwrite  Random write
: randtrim   Random trim
: rw         Sequential read and write mix
: readwrite  Sequential read and write mix
: randrw     Random read and write mix
: trimwrite  Trim and write mix, trims preceding writes

dd - 测试磁盘性能（仅顺序读写）

如果在服务器上无法安装fio等专业工具，可以用dd命令粗略测试磁盘的顺序读写性能，绝大部分linux发行版都自带dd命令，它本来的作用是快速复制和转换文件，不需要root权限。

凭空创建一个大小为 1GB 的文件 testfile，以此测量顺序写入的速度：

> dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.834568 s, 1.3 GB/s

从刚才创建的 testfile 中读取数据，以此测量顺序读取的速度：

> dd if=testfile of=/dev/null bs=1G count=1 iflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.665267 s, 1.6 GB/s

四、网络基准测试

lspci - 查看网卡硬件信息

用Linux自带的lspci命令可以查看所有pci设备的基本信息，我们用ethernet过滤一下就可以得到网卡信息，例如网卡型号。此命令不需要root权限。

> lspci | grep -i ethernet
7d:00.0 Ethernet controller: Huawei Technologies Co., Ltd. HNS GE/10GE/25GE RDMA Network Controller (rev 21)
7d:00.1 Ethernet controller: Huawei Technologies Co., Ltd. HNS GE/10GE/25GE Network Controller (rev 21)
7d:00.2 Ethernet controller: Huawei Technologies Co., Ltd. HNS GE/10GE/25GE RDMA Network Controller (rev 21)
7d:00.3 Ethernet controller: Huawei Technologies Co., Ltd. HNS GE/10GE/25GE Network Controller (rev 21)

更详细的信息可以加-v参数获得：

> lspci -v | grep -i ethernet -A 10
7d:00.0 Ethernet controller: Huawei Technologies Co., Ltd. HNS GE/10GE/25GE RDMA Network Controller (rev 21)
        Subsystem: Huawei Technologies Co., Ltd. HNS GE/10GE/25GE RDMA Network Controller
        Flags: bus master, fast devsel, latency 0, NUMA node 0
        Memory at 121000000 (64-bit, prefetchable) [size=64K]
        Memory at 120000000 (64-bit, prefetchable) [size=1M]
        Capabilities: <access denied>    <-- 要显示全部能力需要加sudo
        Kernel driver in use: hns3
        Kernel modules: hclge, hns3, hns_roce_hw_v2
...

不过lspci命令无法看到网卡的MAC地址，为解决这个问题我们可以使用ifconfig命令或ip命令。

ip -查看MAC地址和IP地址

以前我们经常使用ifconfig命令查看mac地址和ip地址，但这个工具已经几乎停止开发，逐渐被新的ip命令取代。因此这里我们仅介绍后者的使用方法。

注：有些Linux发行版已经不再默认提供ifconfig，若一定要使用，请先安装net-tools组件，例如sudo apt-get install net-tools。

使用ip addr命令可以查看mac地址和ip地址。在下面的例子里，网卡1是LoopBack接口用于与本机通讯，网卡2~4为没有接入网络的物理网卡(DOWN)，网卡5为已接入网络的网卡（UP）

> ip addr
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp125s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether c0:4e:f6:5d:24:06 brd ff:ff:ff:ff:ff:ff
3: enp125s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether c0:4e:f6:5d:24:07 brd ff:ff:ff:ff:ff:ff
4: enp125s0f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether c0:4e:f6:5d:24:08 brd ff:ff:ff:ff:ff:ff
5: enp125s0f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether c0:4e:f6:5d:24:09 brd ff:ff:ff:ff:ff:ff                  <-- MAC地址
    inet 192.168.1.6/16 brd 192.168.255.255 scope global enp125s0f3     <-- IP地址、广播地址
       valid_lft forever preferred_lft forever
    inet6 fe80::b24f:a6ff:fe5c:1409/64 scope link
       valid_lft forever preferred_lft forever

ip命令还有很多功能，例如ip link set可以修改网卡属性，ip route可以操作静态路由表等，限于篇幅这里不作展开了。

netperf - 测试网络性能

使用 netperf 测试网络性能需要两台服务器，一台以netserver命令启动服务端（默认端口12865）：

> sudo netserver -4 -L 0.0.0.0 -p 9292
Starting netserver with host '0.0.0.0' port '9292' and family AF_INET

另一台作为客户端以netperf命令向服务端反复发送数据，下面的例子中-t TCP_CRR表示为每次交易建立一个新的tcp连接（http的场景），-r 4k,1k指定请求和响应内容的大小，-l 30指定测试时长为30秒：

> netperf  -H 127.0.0.1 -P 9292 -l 30 -t TCP_CRR -- -r 4k,1k
MIGRATED TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 () port 0 AF_INET : demo
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

16384  131072 4000     1000    30.00    10808.27    <-- 每秒完成10808个请求响应
16384  131072

后台频繁Full GC导致进程卡住问题一例

Posted on by bjzhanghao

问题现象

Springboot后台服务在向MySQL数据库写入数据的过程中，出现数据写入耗时过长的现象。正常情况下，这批数据的写入操作不应超过20分钟，但实际耗时却达数小时之久。

问题排查

首先怀疑是mysql瓶颈，但在mysql命令行里用processlist命令检查，未发现长时间等待的SQL语句，表明MySQL本身并没有出现性能不足的问题。

mysql -uroot -p mydatabase
show processlist

然后查看java后台日志发现线程池里的线程执行速度非常缓慢，按线程号过滤日志发现负责写入此批数据的线程在7:53卡住，直到9:47才恢复：

file

进一步检查后，发现发现gc日志目录里有大小为182G的dump文件，这个文件是项目组之前在java启动命令里配置的jvm参数（-XX:+HeapDumpBeforeFullGC）自动导出的：

file

Heap dump到磁盘本身会带来一些开销，因此我们先去掉了这个jvm参数。但重跑发现数据插入速度依然缓慢。

继续查看gc.log日志文件，可以看到有不少full gc发生，每次full gc会导致jvm暂停10秒左右。而两次full gc之间的间隔从一开始的几十秒到最后的1秒越来越短（每次gc释放的内存越来越少），导致jvm绝大部分时间都在进行gc，效率非常低。

file

full gc多数是由于在内存里创建了大对象造成的，从日志里看到要更新的计划在内存里是用map对象表示的，这些map对象的key数量总和1000万～2000万之间，每个value占用内存估算超过1KB，总共需要的内存粗估约10GB~20GB。

file

写入这批数据时，服务器可用内存情况：

file

jmap统计的backend jvm内存占用情况，可以看到BucketValue和DateFlagDto这两个对象占用的内存很高，而它们就是准备插入数据库的数据：

file

改进方案

至此频繁full gc的原因基本搞清楚了，即要导入的数据占用内存过多，以至于jvm不得不通过full gc让出足够的空间，而实际让出的空间有限且很快被从磁盘加载的新数据占满，导致再次full gc发生，如此循环。

解决方案也很简单，将数据拆为更小的批写入，改进后每批数据占用的内存大约是之前的十分之一，保险起见每次提交数据库后显式释放内存。现场验证频繁Full GC问题得到解决。

启动Docker容器超过100个后报错问题

Posted on by bjzhanghao

环境信息

AMD EPYC 7551 32-Core Processor 64bit / 452GB / 4.0TB
Kylin Linux Advanced Server V10 (Sword)
Linux-419.90-24.4.v2101.ky10.x86 64-x86 64-with-kylin-10-Sword
Docker 19.03.9

问题现象

Docker容器超过一定数量后无法启动新的容器。

排查和解决

先检查目前正常运行的容器数量，有134个：

> docker ps| wc-l
134

查看了系统可用CPU和内存资源，发现可用16个CPU线程和24GB内存，可用资源还比较宽裕。

考虑到目前运行的容器已经比较多，首先怀疑是打开文件数量(open files)达到上限，检查系统设置值：

> ulimit -n
1024

因为其他类似环境里一般都设置为65535，所以用ulimit -n 65536将打开文件数上限改大，但问题并没有解决。

既然启动新的容器失败，可能docker daemon日志会有线索，查了一下果然发现有错误信息如下：

>  journalctl -ru docker.service
...
04月 26 14:39:35 k2box-211 dockerd[3016]: time="2023-04-26T14:39:35.212798766+08:00" level=error msg="stream copy error: reading from a closed fifo"
04月 26 14:39:35 k2box-211 dockerd[3016]: time="2023-04-26T14:39:35.212674036+08:00" level=error msg="stream copy error: reading from a closed fifo"
04月 26 14:39:26 k2box-211 dockerd[3016]: time="2023-04-26T14:39:26.731792766+08:00" level=warning msg="Health check for container 443a24419f9864ca13a6772c35bb7fe9eabcf317d670d7c73c0383e5473cb397 error: context deadline exceeded"
04月 26 14:39:02 k2box-211 dockerd[3016]: time="2023-04-26T14:39:02.706135654+08:00" level=warning msg="Health check for container d18b85908134d2c45869f68daf825d0c7f6541e77673e8c83a03d34a1c0a3ad9 error: OCI runtime exec failed: exec failed: container_linux.go:318: starting container process caused \"exec: \\\"curl\\\": executable file not found in $PATH\": unknown"
04月 26 14:39:02 k2box-211 dockerd[3016]: time="2023-04-26T14:39:02.699741119+08:00" level=error msg="stream copy error: reading from a closed fifo"
04月 26 14:39:02 k2box-211 dockerd[3016]: time="2023-04-26T14:39:02.699578169+08:00" level=error msg="stream copy error: reading from a closed fifo"
...

日志提示context deadline exceeded，这个错误信息虽然比较模糊，但从时间上看与尝试创建新容器的时间是吻合的，并且应该是某个阈值的限制。在网上google了一下没有找到相同的问题。

尝试停止了一个正在运行的容器，此时启动新容器能正常成功1个，再启动则会失败，因此确认了是容器数量达到了某个阈值，但为什么是134个？

经过仔细分析，发现这134个容器的启动方式有区别，其中34个是通过docker run命令行启动的，另外100个是通过docker-java以程序方式启动的(http接口)，查看相关代码发现后者果然有限制：

DockerHttpClient httpClient = new ApacheDockerHttpClient.Builder()
    .dockerHost(config.getDockerHost())
    .sslConfig(config.getSSLConfig())
    .maxConnections(100)  // 这里对连接数量做了限制
    .connectionTimeout(Duration.ofSeconds(30))
    .responseTimeout(Duration.ofSeconds(45))
    .build();

至此定位到问题原因，解决方法是将maxConnections(100)改为maxConnections(1024)并打包更新到问题环境。

使用Docker部署PostgreSql高可用集群（RepMgr方案）

Posted on by bjzhanghao

本文记录了某项目中使用docker部署PostgreSQL集群的步骤和注意事项，使用的镜像是bitnami/postgresql-repmgr，其中与用户身份有关的内容在其他bitnami打包的镜像中也适用。

一、环境信息

CentOS 7.9
PostgreSQL 16

二、部署方案

PostgreSQL集群有多种方案，这里我们使用在项目中多次使用比较稳定的repmgr方案，repmgr能够在集群环境管理每个PostgreSQL节点的主从状态，官网介绍如下：

repmgr是一个开源的工具套件，用于管理PostgreSQL服务器集群中的复制和故障转移。它通过提供设置备用服务器、监控复制和执行故障转移或手动切换操作等管理任务的工具，增强了PostgreSQL内置的热备功能。
repmgr自从PostgreSQL 9.0引入内置的复制机制后，就提供了高级的支持。当前的repmgr系列，repmgr 5，支持了PostgreSQL 9.3引入的最新的复制功能，如级联复制、时间线切换和通过复制协议进行基础备份。

bitnami提供的postgresql-repmgr镜像是将PostgreSQL与repmgr打包在一起，形成一个集成的解决方案，以便用户能够快速搭建PostgreSQL集群服务，用户可以从dockerhub获取到这个镜像。

这个PostgreSQL集群解决方案包括PostgreSQL复制管理器，一个用于管理PostgreSQL集群上的复制和故障转移的开源工具。

三、部署步骤

首先确认集群环境各个服务器节点的状态：

关闭防火墙（如果docker已启动需要重启docker服务，否则关闭防火墙后启动容器会报iptables命令错）：

systemctl stop firewalld 
systemctl disable firewalld

确保服务器时钟准确：

ntpdate cn.ntp.org.cn

安装和启动docker服务和docker-compose工具：

yum install -y epel-release
yum install -y docker
yum install -y docker-compose
systemctl enable docker
systemctl start docker

安装postgresql-repmgr镜像：

docker pull bitnami/postgresql-repmgr

将各个服务器名称写入hosts文件，vi /etc/hosts添加下面内容：

10.102.9.80 pg-0
10.102.9.81 pg-1
10.102.9.82 pg-2

四、配置

数据目录

bitnami的镜像使用非root用户身份，即容器里的root用户映射到宿主机的非root用户，此用户是ID为1001的无名称用户。要让容器的数据能够持久化到宿主机，需要准备一个数据目录（此例中为/mnt/sda/bitnami/postgresql）并映射到容器内，此目录的owner是1001：

mkdir /mnt/sda/bitnami
mkdir /mnt/sda/bitnami/postgresql
chown 1001:root /mnt/sda/bitnami -R

网络

创建docker网络以便节点间能够通信：

docker network create --subnet=172.25.0.0/24 --gateway=172.25.0.1 pg-network

配置文件

在任意目录创建pg.yml文件，内容如下：

version: '2'
networks:
  default:
    external:
      name: pg-network
services:
  pg:
    container_name: "pg"
    image: bitnami/postgresql-repmgr:latest
    networks:
      default:
        ipv4_address: 172.25.0.110
    ports:
      - "5432:5432"
    restart: always
    volumes:
      - /mnt/sda/bitnami/postgresql:/bitnami/postgresql
      - /etc/hosts:/etc/hosts
    environment:
      - POSTGRESQL_POSTGRES_PASSWORD=adminpassword
      - POSTGRESQL_USERNAME=myuser
      - POSTGRESQL_PASSWORD=mypassword
      - POSTGRESQL_DATABASE=mydatabase
      - REPMGR_PASSWORD=adminpassword
      - REPMGR_PRIMARY_HOST=pg-0
      - REPMGR_PRIMARY_PORT=5432
      - REPMGR_PARTNER_NODES=pg-0,pg-1,pg-2:5432
      - REPMGR_NODE_NAME=pg-0
      - REPMGR_NODE_NETWORK_NAME=pg-0
      - REPMGR_PORT_NUMBER=5432

在第二个节点类似创建pg.yml文件，修改其中的部分内容（ip地址、以及2处节点名称，见代码中的标注）如下所示：

version: '2'
networks:
  default:
    external:
      name: pg-network
services:
  pg:
    container_name: "pg"
    image: bitnami/postgresql-repmgr:latest
    networks:
      default:
        ipv4_address: 172.25.0.111    <-- 修改了这里
    ports:
      - "5432:5432"
    restart: always
    volumes:
      - /mnt/sda/bitnami/postgresql:/bitnami/postgresql
      - /etc/hosts:/etc/hosts
    environment:
      - POSTGRESQL_POSTGRES_PASSWORD=adminpassword
      - POSTGRESQL_USERNAME=myuser
      - POSTGRESQL_PASSWORD=mypassword
      - POSTGRESQL_DATABASE=mydatabase
      - REPMGR_PASSWORD=adminpassword
      - REPMGR_PRIMARY_HOST=pg-0
      - REPMGR_PRIMARY_PORT=5432
      - REPMGR_PARTNER_NODES=pg-0,pg-1,pg-2:5432
      - REPMGR_NODE_NAME=pg-1    <-- 修改了这里
      - REPMGR_NODE_NETWORK_NAME=pg-1    <-- 修改了这里
      - REPMGR_PORT_NUMBER=5432

第三个节点的情况类似，为节约篇幅这里不再贴配置文件内容。

启动服务

在每个节点分别使用docker-compose命令启动服务：

docker-compose -f /root/pg-ha/pg.yml up -d

查看repmgr状态，例如当前primary节点是哪一个：

docker exec -ti pg /opt/bitnami/scripts/postgresql-repmgr/entrypoint.sh repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf service status

 ID | Name | Role    | Status    | Upstream | repmgrd | PID | Paused? | Upstream last seen
----+------+---------+-----------+----------+---------+-----+---------+--------------------
 1000 | pg-0 | standby |   running | pg-1     | running | 1   | no      | 1 second(s) ago
 1001 | pg-1 | primary | * running |          | running | 1   | no      | n/a
 1002 | pg-2 | standby |   running | pg-1     | running | 1   | no      | 0 second(s) ago

尝试连接数据库，验证服务是否正常（-U参数很重要）：

docker exec -ti pg psql -U myuser -d mydatabase

若需要手工切换standby节点为primary执行下面的命令，需要节点之间配置过免密：

docker exec -it pg /opt/bitnami/scripts/postgresql-repmgr/entrypoint.sh repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf standby switchover

Linux inode和常用操作

Posted on by bjzhanghao

Linux系统里的inode中文名索引文件，用于保存文件的大小、时间、权限等元信息。每个文件都对应一个inode，每个inode也对应一个文件。因为在Linux里目录、设备等也是文件，所以也对应一个inode。

inode与文件块是分开保存的，它们都会占用磁盘空间，通常情况下是后者先占满，但当磁盘上有大量小文件时，可能前者会先达到上限，从而导致磁盘虽然还有空间但无法写入新文件。这种场景应提前考虑增加inode的上限数量，例如将2KB降为1KB。

file
图片来源：Wikipedia

让我们做一些实验来验证一下inode的行为：

查看磁盘已用和可用inode数量

执行df -i可查看分区里inode数量，一个分区下最大inode数量是格式化时确定的，默认最大数量是分区大小除以2KB得到
file

查看文件inode信息

执行ls -i可查看当前目录每个文件的inode值：
file

验证软链接有自己的inode

软链接是一个文件，其inode值与链接目标文件是不相同的。
file

验证硬链接共享同一个inode

硬链接不是一个文件，其inode号与链接目标文件相同。其实很正常，linux内部对文件的管理都是通过inode完成的，文件名只是一个易读的符号。
file

验证.和..是硬链接

分别对应当前目录的inode和上一级目录的inode。
file

验证通过inode号反查文件名

用find -inum命令：
file

文件名存储在哪里？

inode里并不保存文件名（否则硬链接无法实现），那么文件名存储在哪里？答案是存储在“目录文件”里，当我们ls时，Linux就查询目录文件（但我们不能直接cat目录），此文件包含此目录下所有文件名到inode的映射关系。
file

注：以上均默认ext2文件系统。

使用Java nio实现快速合并大量csv文件

Posted on by bjzhanghao

需求描述

某项目有一个将小csv文件合并为大csv文件的场景：典型情况每台设备每天产生1440个csv文件（即每分钟一个文件），每个文件大小约100KB，需要将它们合并为一个csv文件。

这样的设备大约有2000台，也就是每天288万个csv文件，按设备合并后应得到2000个csv文件。

问题分析

如果用Apache Commons CSV依次读取小文件再写入大文件，每台设备大约需要20~30秒，2000台设备需要10小时以上，时间太长无法接受。

通过查看样例数据发现，每个设备每天的csv文件表头是完全相同的，跨设备或跨天则不保证表头相同。恰好合并的规则也是按设备按天，因此想到可以利用数据的这个特点优化合并效率。

Java的nio包提供了文件通道（FileChannel）访问文件的方法，允许在两个文件通道间直接传输数据(transferTo)，省去了数据在硬件、内核态和用户态之间多次复制的开销(零拷贝)。同时FileChannel允许跳到文件指定位置进行读取，我们可以利用这一点跳过csv的表头区域。

代码实现

以下代码封装了合并csv的逻辑，经测试在普通服务器SAS硬盘下合并1440个文件耗时约1秒，对比之前的20秒提升还是很明显的。

package com.acme;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.*;
import java.nio.channels.FileChannel;

public class MergeCsvDemo {

    final static Logger logger = LoggerFactory.getLogger(MergeCsvDemo.class.getName());

    /**
     * Merge given csv files into one file.
     * @param srcFiles Source csv files, must have same header
     * @param destFile Destination csv file
     * @throws UserException
     */
    public static void mergeCsvFiles(File[] srcFiles, File destFile) throws UserException {

        if (destFile.exists()) {
            throw new UserException("Destination file already exists: " + destFile.getPath());
        }
        if (!destFile.getPath().toUpperCase().contains("CSV")) {
            throw new UserException("Only csv file is allowed: " + destFile.getPath());
        }
        if (srcFiles.length == 0) {
            throw new UserException("Please specify at least one source file");
        }
        if (!destFile.getParentFile().exists()) {
            destFile.getParentFile().mkdirs();
        }

        try {

            // 获取源文件表头长度（假设每个源文件表头相同）
            int headerLength = 0;
            BufferedReader br = new BufferedReader(new FileReader(srcFiles[0]));
            String line = br.readLine();
            if (line == null) {
                throw new UserException("Empty source file: " + srcFiles[0]);
            }
            headerLength = line.length();
            br.close();

            // 合并文件
            FileChannel destChannel = new FileOutputStream(destFile, true).getChannel();
            for (int i = 0; i < srcFiles.length; i++) {
                FileChannel srcChannel = new FileInputStream(srcFiles[i]).getChannel();
                // 非第一个文件时，跳过表头
                if (i > 0) {
                    srcChannel.position(headerLength);
                }
                destChannel.transferFrom(srcChannel, destChannel.size(), srcChannel.size());
                srcChannel.close();
            }
            destChannel.close();

        } catch (IOException e) {
            e.printStackTrace();
            throw new UserException(e.getMessage());
        }

    }
}

示例下载

为了减小压缩后的文件尺寸，示例里的csv文件是经过脱敏、截取和复制处理的，执行测试用例即可合并80个样例csv文件，合并后约370MB，耗时约0.6秒。

merge-csv-demo.zip

Java读写本地Parquet格式数据文件

Posted on by bjzhanghao

Apache Parquet是大数据平台里广泛使用的一种开源的列式文件存储格式，MapReduce和Spark等计算框架都内置了对读写Parquet文件的支持，通常Parquet文件放在HDFS上使用。

有时我们需要用Java直接读写本地的Parquet文件，在没有MapReduce或Spark等工具的情况下，要实现读写Parquet文件可以借助hadoop-client和parquet-hadoop这两个包实现。

一、依赖类库

首先需要在Java工程的pom.xml里添加下面的依赖项（引入hadoop-client会显著增大fat jar包的体积，但目前没有很好的替代方案）：

<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>hadoop-client</artifactId>
    <version>2.7.7</version>
</dependency>
<dependency>
    <groupId>org.apache.parquet</groupId>
    <artifactId>parquet-hadoop</artifactId>
    <version>1.10.1</version>
</dependency>

二、将数据写入Parquet文件

Parquet官方提供了org.apache.parquet.example.data.Group作为一条记录的对象，这里演示以此对象写入parquet文件的方法。为了简化示例代码，parquet文件里每一列的类型都使用整型。

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;
import org.apache.parquet.example.data.Group;
import org.apache.parquet.example.data.simple.SimpleGroupFactory;
import org.apache.parquet.hadoop.ParquetWriter;
import org.apache.parquet.hadoop.example.GroupWriteSupport;
import org.apache.parquet.hadoop.metadata.CompressionCodecName;
import org.apache.parquet.schema.*;

import java.io.IOException;

/**
 * 示例程序：数据以 org.apache.parquet.example.data.Group 的形式写入Parquet文件
 */
public class WriteParquetDemoGroup {
    Configuration conf;

    public WriteParquetDemoGroup() {
        conf = new Configuration();
        conf.set("fs.hdfs.impl",
                org.apache.hadoop.hdfs.DistributedFileSystem.class.getName()
        );
        conf.set("fs.file.impl",
                org.apache.hadoop.fs.LocalFileSystem.class.getName()
        );
    }

    public void writeParquet(int numRows, String[] fields, Path parquetPath) throws IOException {

        Types.MessageTypeBuilder schemaBuilder = Types.buildMessage();
        for (int j = 0; j < fields.length; j++) {
            schemaBuilder.addField(new PrimitiveType(Type.Repetition.REQUIRED, PrimitiveType.PrimitiveTypeName.INT32, fields[j]));
        }
        MessageType schema = schemaBuilder.named("record");

        GroupWriteSupport.setSchema(schema, conf);
        GroupWriteSupport writeSupport = new GroupWriteSupport();
        writeSupport.init(conf);

        ParquetWriter<Group> writer = null;
        try {
            writer = new ParquetWriter<Group>(parquetPath,
                    writeSupport,
                    CompressionCodecName.SNAPPY,
                    ParquetWriter.DEFAULT_BLOCK_SIZE, ParquetWriter.DEFAULT_PAGE_SIZE, ParquetWriter.DEFAULT_PAGE_SIZE,
                    ParquetWriter.DEFAULT_IS_DICTIONARY_ENABLED,
                    ParquetWriter.DEFAULT_IS_VALIDATING_ENABLED,
                    ParquetWriter.DEFAULT_WRITER_VERSION,
                    conf);

            for (int i = 0; i < numRows; i++) {
                Group group = new SimpleGroupFactory(schema).newGroup();
                for (int j = 0; j < fields.length; j++) {
                    group.add(fields[j], i * j);
                }
                writer.write(group);
            }
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (writer != null) {
                try {
                    writer.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }

    }
}

三、从Parquet文件读取数据

读取Parquet文件的代码本身很简单，只是要特别注意一点，为了能发挥Parquet列式存储的优势，应将要读取的列配置到PARQUET_READ_SCHEMA参数，以便跳过其他不需要扫描的列，从而提高读取性能。

public void readParquetWithReadSchema(Path parquetPath, String[] queryFields) throws IOException {
    // 将要读取的列配置到PARQUET_READ_SCHEMA，如果缺失这一步读取性能将严重降低
    Types.MessageTypeBuilder builder = Types.buildMessage();
    for (int j = 0; j < queryFields.length; j++) {
        builder.addField(new PrimitiveType(Type.Repetition.REQUIRED, PrimitiveType.PrimitiveTypeName.INT32, queryFields[j]));
    }
    MessageType messageType = builder.named("record");
    conf.set(ReadSupport.PARQUET_READ_SCHEMA, messageType.toString());

    // 读取Parquet文件
    GroupReadSupport readSupport = new GroupReadSupport();
    ParquetReader.Builder<Group> readerBuilder = ParquetReader.builder(readSupport, parquetPath);
    ParquetReader<Group> reader = readerBuilder.withConf(conf).build();
    Group line = null;
    while ((line = reader.read()) != null) {
        for (String field : queryFields) {
            line.getInteger(field, 0);
        }
    }
}

四、性能测试

写了一个简单的测试用例ParquetDemoTest，验证不同条件下上面的代码写入和读取Parquet文件的耗时。运行环境是普通笔记本电脑，i5 CPU + SSD硬盘。

写入性能：固定每行500列，可以看到写入parquet文件的耗时与写入的行数成正比；

读取性能：从parquet文件中读取少量列时速度是很快的，读取耗时与读取的列数成正比；

错误读取：当没有配置PARQUET_READ_SCHEMA时，读取多少列耗时都与读取500列差不多，未能体现列式存储的优势。

写入Parquet文件（Group）, 100 行 x 500 列, 耗时 1580 ms
写入Parquet文件（Group）, 500 行 x 500 列, 耗时 6927 ms
写入Parquet文件（Group）, 1000 行 x 500 列, 耗时 12424 ms
写入Parquet文件（Group）, 2000 行 x 500 列, 耗时 25849 ms
写入Parquet文件（Group）, 3000 行 x 500 列, 耗时 36799 ms

读取Parquet文件（过滤列）, 3000 行 x 5 列, 耗时 180 ms
读取Parquet文件（过滤列）, 3000 行 x 10 列, 耗时 202 ms
读取Parquet文件（过滤列）, 3000 行 x 15 列, 耗时 171 ms
读取Parquet文件（过滤列）, 3000 行 x 50 列, 耗时 258 ms
读取Parquet文件（过滤列）, 3000 行 x 100 列, 耗时 504 ms
读取Parquet文件（过滤列）, 3000 行 x 200 列, 耗时 1608 ms
读取Parquet文件（过滤列）, 3000 行 x 300 列, 耗时 2544 ms
读取Parquet文件（过滤列）, 3000 行 x 400 列, 耗时 3998 ms
读取Parquet文件（过滤列）, 3000 行 x 500 列, 耗时 6022 ms

读取Parquet文件（未过滤列）, 3000 行 x 5 列, 耗时 6188 ms
读取Parquet文件（未过滤列）, 3000 行 x 5 列, 耗时 6795 ms
读取Parquet文件（未过滤列）, 3000 行 x 10 列, 耗时 6717 ms
读取Parquet文件（未过滤列）, 3000 行 x 15 列, 耗时 6268 ms
读取Parquet文件（未过滤列）, 3000 行 x 50 列, 耗时 6311 ms
读取Parquet文件（未过滤列）, 3000 行 x 100 列, 耗时 7317 ms
读取Parquet文件（未过滤列）, 3000 行 x 200 列, 耗时 6637 ms
读取Parquet文件（未过滤列）, 3000 行 x 300 列, 耗时 6676 ms
读取Parquet文件（未过滤列）, 3000 行 x 400 列, 耗时 7225 ms
读取Parquet文件（未过滤列）, 3000 行 x 500 列, 耗时 6928 ms

五、代码下载

文中使用的代码：parquet-demo-1.0.0-src.zip

参考资料

https://www.arm64.ca/post/reading-parquet-files-java/

CentOS 7.6内核SLAB泄露问题

Posted on by bjzhanghao

公司产品使用docker-java控制作业在指定的运行环境（docker容器）里执行，因此经常需要反复启动和停止docker容器，在项目中发现存在一段时间（若干天）后启动容器失败的现象。

问题现象

多次启动docker容器并停止后，发现buff/cache内存占用不断增加，且手工释放没有明显效果：
file

file

内存不足的一个表现是无法启动docker容器，报错如下：

OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:319: getting the final child's pid from pipe caused \"EOF\"": unknown

查看meminfo判断主要是slab过多：
file

问题解决

在网上查询后发现有用户遇到类似问题，原因是kernal 3.10的kmem memory limit不稳定，但这个feature是默认开启的。解决方法是升级内核到kernal 3.10.1075以上，或升级CentOS发行版到7.8或以上。

补充：后来发现3.10版的内核仍然没有完全解决这个问题，升级到4.x版内核后问题解决。

参考资料

https://github.com/moby/moby/issues/37722
https://zhuanlan.zhihu.com/p/106757502

关于Apache Drill使用DIR0条件过滤分区的性能问题

Posted on by bjzhanghao

问题描述

数据文件按设备号和日期（yyyyMMdd）两层分区，现在想查询指定设备下的所有数据，使用DIR0关键字过滤：

select * from dfs.`table1` where DIR0 = 'device0001'

发现planning时间很长，进一步检查日志发现是在planning阶段扫描了table1下的所有目录，而不是只扫描了device0001目录，而设备数量有8000多个，每个目录下有几百个parquet文件总共300万个文件左右，因此扫描的时间很长。
file

问题解决

通过跟踪DRILL代码发现，DRILL在planning开始的时候，需要创建一个Table对象并扫描此Table下的所有文件，并且未考虑DIR0指定的条件。

在drill的jira上查到相关bug记录：DRILL-2517和DRILL-3996，后者2015年记录但至今仍未解决，因此短期内可能无法通过升级DRILL版本解决。

变通的解决方法是，将查询语句修改为：

select * from dfs.`table1/device0001`

即把DIR0里的条件放在FROM子句里，此时planning时间显著降低。

定制Flink输出的parquet文件名

Posted on by bjzhanghao

问题描述

使用Flink将kafka等数据源的数据流，经过处理后输出到文件，我们一般是这样写代码的：

Schema avroSchema = ...;
StreamingFileSink<GenericRecord> sink = StreamingFileSink
        .forBulkFormat(new Path("my/base/path"), ParquetAvroWriters.forGenericRecord(avroSchema))
        .withBucketAssigner(new MyBucketAssigner())
        .build();

实际使用时发现，生成的parquet文件名称是"part-1-2"这种格式的，且没有扩展名。由于我们的应用对parquet文件名有一定的规范且文件名里包含一些实用信息（例如文件里的记录条数），所以这样是不能满足我们要求的。

然而flink里这个文件名的规则是写死在Bucket.java里的无法修改，只能寻找变通的方法来解决。

解决方法

StreamingFileSink.forBulkFormat()的第二个参数是一个Factory，用于创建BulkWriter，我们可以从这里入手，注入自定义的BulkWriter，在写入文件的时候修改parquet文件名。

以下是若干个相关类，经实测通过。这个方案最大的问题是需要通过反射获取targetFile文件名，所以有可能在未来的flink版本里失效。

StreamingFileSink:

Schema avroSchema = ...;
StreamingFileSink<GenericRecord> sink = StreamingFileSink
        .forBulkFormat(new Path("my/base/path"), new MyParquetWriterFactory(new MyParquetBuilder()))
        .withBucketAssigner(new MyBucketAssigner())
        .build();

MyParquetWriterFactory:

static class MyParquetWriterFactory extends ParquetWriterFactory {
    public MyParquetWriterFactory(ParquetBuilder writerBuilder) {
        super(writerBuilder);
    }

    @Override
    public BulkWriter create(FSDataOutputStream stream) throws IOException {
        BulkWriter writer = super.create(stream);
        return new MyParquetBulkWriter(writer, stream);
    }
}

MyParquetBulkWriter:

/**
 * 包装flink的ParquetBulkWriter，修改part文件名格式
 */
static class MyParquetBulkWriter implements BulkWriter<GenericRecord> {
    private FSDataOutputStream stream;
    private BulkWriter writer;
    private int rowCount;

    public MyParquetBulkWriter(BulkWriter writer, FSDataOutputStream stream) {
        this.writer = writer;
        this.stream = stream;
    }

    @Override
    public void addElement(GenericRecord element) throws IOException {
        writer.addElement(element);
        rowCount++; //记录计数，结果将作为文件名的一部分
    }

    @Override
    public void flush() throws IOException {
        writer.flush();
    }

    @Override
    public void finish() throws IOException {
        // 试图在finish()后改名失败，因为finish()后正式文件并没有生成
        // 通过反射直接修改stream里的targetFile名称可行
        // 这里是修改part文件名的关键部分
        try {
            Field field = stream.getClass().getDeclaredField("targetFile");
            field.setAccessible(true);
            File targetFile = (File) field.get(stream);
            File renamedTargetFile = new File(targetFile.getParent(), rowCount + "_" + System.currentTimeMillis() + ".parquet");
            field.set(stream, renamedTargetFile);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } finally {
            writer.finish();
        }
    }
}

MyParquetBuilder（其中avroSchema是在外部赋值的）：

static class MyParquetBuilder implements ParquetBuilder {
    @Override
    public ParquetWriter createWriter(OutputFile outputFile) throws IOException {
        return 
        ParquetWriter.builder(outputFile).withSchema(avroSchema).withDataModel(GenericData.get()).build();
    }
}

参考资料

Flink streaming - Change part file names when using StreamingFileSink?