|
13版本的情况 写入大文件(64GiB)写满pool，这个没有问题，写满pool也不用多少个文件，读取也顺利 写入大量较小的文件就不行了，读取也不能正常进行 默认配置下，cephfs的根目录下创建10个目录，写入大量的文件 [twj@R03-MTEST-DN-017.xx.cn ~]$ sudo ceph fs status8 s0 I3 V4 n. i# S" v. @/ A+ [( V
filecephfs - 3 clients0 b1 d5 c4 W# X# H. [/ x
==========
U7 P E4 Z' O+------+--------+------------------------+---------------+-------+-------+* o% J3 _; f9 {
| Rank | State | MDS | Activity | dns | inos |
+ _9 X3 X( i0 F+------+--------+------------------------+---------------+-------+-------+0 s% {( w k5 Y9 H% a m0 s
| 0 | active | R03-MTEST-MN-002.xx.cn | Reqs: 0 s | 19.8M | 19.8M |( b/ I8 s+ v* i
+------+--------+------------------------+---------------+-------+-------+
X# N# |! ^6 Q X6 M3 c8 x8 n+----------------------+----------+-------+-------+
$ @. ?1 Y/ {4 N. }8 S3 x| Pool | type | used | avail |5 P. Z# q7 `9 ?: D3 B+ B
+----------------------+----------+-------+-------+
6 W0 D( c; \$ f3 @$ p7 M; F" Q, n| cephfs-metadata-pool | metadata | 155M | 794G |
" d9 K. z) m2 r! j, A| cephfs-data-pool | data | 957T | 0 |% V# S: r5 p5 y, s
+----------------------+----------+-------+-------+
3 p1 E, ^* S: e7 {" f t: c+------------------------+0 S: c' K2 B3 P, {" j) m0 r
| Standby MDS |
6 \) h1 N/ J$ D6 @. U: f c+------------------------+
, s. }' p z: s2 E( X& Q| R03-MTEST-MN-001.xx.cn |
5 x& s3 ~1 l$ B8 a, ?+ p+------------------------+# C6 P; ? r$ }. f
MDS version: ceph version 13.2.10 (564bdc4ae87418a232fc901524470e1a0f76d641) mimic (stable)0 D* M+ P5 C3 e( S$ C
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df5 \/ I) D ]: N* g; s* i4 C* K
GLOBAL:+ I& {: P: P8 P& a- v7 r5 H
SIZE AVAIL RAW USED %RAW USED
7 f( r6 |# `( W0 V5 w- D9 F; r; v 1.5 PiB 91 TiB 1.4 PiB 94.08( K0 m5 ~2 U! Z# b" E+ L, `
POOLS:& G6 e- v! E2 \1 i& w- \
NAME ID USED %USED MAX AVAIL OBJECTS
% c' | `: z* H. h6 u7 Z' P cephfs-data-pool 15 957 TiB 100.00 0 B 561286578
: p* N4 T; A4 A) _2 @9 d/ t1 q cephfs-metadata-pool 17 155 MiB 0.02 795 GiB 98368
! h+ J* U" J8 s8 r; j; [) F8 B8 n此时，mds的内存占用达到了55g PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
& a; t8 N) G# d. S/ q7 E 47740 ceph 20 0 55.4g 55.0g 10356 S 6.6 21.9 11905:23 ceph-mds
+ m* Y* W" u C; X. E. g尝试重启这个mds，直接导致fs瘫痪，mds状态一直都是replay，接着mon好几天都起不来，集群也直接没法用了。。。 2021-06-17 10:10:36.352 7f9039544700 1 heartbeat_map is_healthy 'Monitor::cpu_tp thread 0x7f9034ccc700' had timed out after 0
- Q4 J# I- u+ Q# l2 v
. D ^# K4 \' i4 S2 ]perf top -p 3563473
9 A9 S. ?. h$ RSamples: 63K of event 'cycles:ppp', Event count (approx.): 494028413958 c4 N$ u% `. \
Overhead Shared Object Symbol
1 F \/ k6 z+ {1 @1 Z 48.92% libceph-common.so.0 [.] crush_hash32_3# J" k6 L9 { M7 z
24.28% libceph-common.so.0 [.] 0x0000000000647f80$ l( i: I0 w% o& S% O* t6 g
4.35% libceph-common.so.0 [.] 0x0000000000647f59
/ r U. \8 G+ q$ g; n! Q9 [8 U第二次测试，写入一段时间后，集群报错，mds处于rejoin状态 cluster:* n$ S9 G i# x3 f* I4 x$ `
id: 8418d616-979b-46f9-ab95-b8fb20093d1b
! S6 Y. D9 I& G0 \" C health: HEALTH_WARN1 c/ |, S1 z6 A& p3 A
1 filesystem is degraded
^4 i8 L7 O, n0 X 1 MDSs report oversized cache0 r+ w* V5 o0 ^! @0 w
1 MDSs report slow metadata IOs7 `* C* D) F; h7 b, i* T+ o" b
+------+--------+----------------------+----------+-------+-------+
2 k# T6 a: ^% \; Y% U! S8 J/ J' q| Rank | State | MDS | Activity | dns | inos |. \/ S0 K9 m2 }6 o7 Y3 s
+------+--------+----------------------+----------+-------+-------+
! g7 j3 T( e7 n p& S$ U" s+ f2 d| 0 | rejoin |R03-MTEST-MN-001.xx.cn| | 59.5M | 59.5M |
6 P) J3 |" e: z+------+--------+----------------------+----------+-------+-------+
( v- m/ q: ]( @+ h" \- d0 [此时mds的内存消耗非常大 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND" I: U' `7 _$ F" G6 s5 v% Q9 I0 o
150540 ceph 20 0 224.9g 223.5g 11704 S 100.0 89.0 196:15.69 ceph-mds( F% P; t' M3 L% q }0 S$ k: b
使用命令ceph daemon run/ceph/ceph-mds.R03-MTEST-MN-001.xx.cn.asok flush journal
' x5 `" p. ^$ m; }3 y后，降低了一些，但很快又上到了223G 从结果上看，该版本的mds主要是没有解决内存的问题，没写多少文件，内存就直线飙升，而且居高不下，妄想重启mds，那就直接玩完 这里直接给出13.2.10的建议：不行！事实上，14.2.x之前的版本都不建议使用cephfs上生产环境 14版本的表现在这个版本的测试用，我加入了额外的data pool，并使用了多活mds，直接测试的小文件写入 [twj@R03-MTEST-MN-001.xx.cn test-cephfs]$ sudo ceph fs status& h% J( C& Q K# N3 }" N$ q! `
cephfs - 40 clients
2 M4 @" [, s$ O' u- x4 N3 f======" k6 X, u) L5 I) `! l
+------+--------+------------------------+---------------+-------+-------+
; A* h7 E8 o( o| Rank | State | MDS | Activity | dns | inos |
0 |1 `- N# [2 D+------+--------+------------------------+---------------+-------+-------+8 W5 X/ w) h/ c, s/ K3 C ?
| 0 | active | R03-MTEST-MN-003.xx.cn | Reqs: 10.3k/s | 391k | 391k |+ ]! O% ~' T6 l8 a
| 1 | active | R03-MTEST-MN-002.xx.cn | Reqs: 10.5k/s | 385k | 385k |
# E" K ^8 W7 p3 U4 p+ I+------+--------+------------------------+---------------+-------+-------+& I5 r, j1 u: x6 x( D* z+ W8 P
+----------------------+----------+-------+-------+
* P5 Y3 u4 M; r& |3 c( a| Pool | type | used | avail |
1 z. m `( e$ m+----------------------+----------+-------+-------+. I" I; F# _- R2 B1 Q; V
| cephfs.metadata.pool | metadata | 3378M | 797G |
* G+ }. x5 {5 B! z, b| cephfs.data.pool1 | data | 6085G | 1234T |8 d6 V) P# N. ?
| cephfs.data.pool2 | data | 2257G | 1241T |' D* \) o5 T9 V) i6 e
+----------------------+----------+-------+-------+6 o& b `- ]8 c7 y6 D# _* l
+------------------------+
' j s3 ?1 X7 Q3 u6 j# {* R4 j& D( v| Standby MDS |; Q( {- s& Y9 {+ I5 `$ ]
+------------------------+/ C4 m3 { m( W) [8 r8 ~
| R03-MTEST-MN-001.xx.cn |9 t- T% p6 Z) p7 m3 c# }3 A
+------------------------+
& x' C$ n; A2 o5 l0 K0 M! AMDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)& G4 h4 H7 f" f* U; G1 m
其中每个data pool都创建了20个目录，并pin到不同的mds上，性能看还算均衡，连续快速写入，会有告警2 MDSs behind on trimming1 F/ t1 A! ~/ y% h% m
但没有什么影响，就没管 随着数据的大量写入，集群开始出现slow [twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph df C$ a9 N1 d. w# f2 v# R6 a
RAW STORAGE:
7 Y( j4 [! n4 j# |6 T1 N, v CLASS SIZE AVAIL USED RAW USED %RAW USED
" f" [* I2 Q- M) ~4 |: H/ H hdd 3.9 PiB 3.1 PiB 823 TiB 823 TiB 20.79
8 z- s3 Q# D9 J6 L$ ], j1 M ssd 16 TiB 3.0 TiB 13 TiB 13 TiB 80.728 o/ v4 ?/ o+ L; M& Z, L
TOTAL 3.9 PiB 3.1 PiB 835 TiB 836 TiB 21.03: Z. [' T6 M- K: E2 G8 S
0 `1 W3 R& h, m9 ?
POOLS:# }; W6 g- y2 E
POOL ID PGS twjD OBJECTS USED %USED MAX AVAIL* r4 W% Q) M7 r
cephfs.data.pool1 2 8192 275 TiB 217.81M 413 TiB 23.20 911 TiB
# ?& B0 ?* L a: S9 p cephfs.data.pool2 3 8192 244 TiB 102.44M 366 TiB 20.53 946 TiB) t% G; {0 ?$ S# j8 _
cephfs.metadata.pool 4 256 127 GiB 115.39k 191 GiB 7.74 760 GiB
; ~, Y5 @$ m4 I G1 J % C6 y* v2 ~$ a d
[twj@R03-MTEST-MN-001.xx.cn ~]$ sudo ceph health detail
2 M5 s" `8 M4 w' D Y" w- [9 X6 ZHEALTH_WARN 1 MDSs report slow metadata IOs; 1 MDSs report slow requests) a3 E- `% T/ `0 R% [/ g! N! ~# K! y
MDS_SLOW_METADATA_IO 1 MDSs report slow metadata IOs
( \; d8 ~- `; A% q O% \ mds.R03-MTEST-MN-002.xx.cn(mds.1): 100+ slow metadata IOs are blocked > 30 secs, oldest blocked for 87 secs
9 p3 m/ t8 T( ?0 BMDS_SLOW_REQUEST 1 MDSs report slow requests/ o; k) M* \) }2 ~( i
mds.R03-MTEST-MN-002.xx.cn(mds.1): 11 slow requests are blocked > 30 secs! m. w; X2 Z2 j! X$ ]9 H5 V/ Z
查看mds的op处理流程 [twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph daemon mds.`hostname` dump_historic_ops_by_duration|grep duration
3 ]0 U9 E- f" [% w "duration": 600,
5 `0 a9 L( _. J$ B& R8 \: `, x; E* N/ Z "duration": 427.63886984499999,
- E; O& J$ U9 ]: a "duration": 427.62001601499998,1 f& `7 ]3 g" z X8 O$ R0 q. Z# l- L: h* |
"duration": 409.772382456,2 i/ \7 v* r, z; Y
"duration": 409.75990740399999,/ p& C* W8 L! M6 d5 R
"duration": 215.47288510800001,
+ `) B1 f; D6 S" } R "duration": 214.47418489699999,
( f* k9 O% R1 a; p" i! ?+ r$ N5 V "duration": 203.97045117499999, u8 q( u% }( ~ s3 ^
"duration": 203.51505527899999,! U; I4 u3 L" e( R* X1 W* \
...
4 a; x- K Q. P时间都非常久，继续排查，发现大量的op都是卡在failed to rdlock, waiting7 m. h! A: W9 v- w6 O
这个步骤，关于这种情况的调查和优化，还在努力。。。 看了一眼内存，没有明显的飙升 [twj@R03-MTEST-MN-003.xx.cn ~]$ top
/ c+ m$ P* B: Ctop - 15:34:57 up 9 days, 4:36, 1 user, load average: 0.95, 1.22, 1.28
" J) [- m X B) L3 STasks: 650 total, 1 running, 649 sleeping, 0 stopped, 0 zombie4 p9 \5 S. u2 O; h1 t6 I
%Cpu(s): 1.9 us, 0.1 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
; C6 j6 L7 p0 X$ G' w) M$ e" VKiB Mem : 26353089+total, 25013656+free, 11907872 used, 1486464 buff/cache1 B3 i- T. ^" S ^, ^1 k# f, b
KiB Swap: 16777212 total, 16777212 free, 0 used. 24535932+avail Mem
4 \+ z, r3 C( ~7 k1 ]- [! k+ ?& U3 ], [ y, D ]2 h! j& S. M
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND2 m) T7 F: }* P7 a. N9 w/ _9 T
29657 ceph 20 0 7878864 2.5g 14288 S 100.7 1.0 4616:55 ceph-mds
9 Y. W8 R. h0 ^$ O# C大量数据写入后，先测试一下mds的重启，直接reboot节点，观察集群的情况 [twj@R03-MTEST-MN-002.xx.cn ~]$ sudo ceph fs status/ w# e' @) q3 _* s% }0 [
cephfs - 40 clients
. X! C, ]) _3 @1 w- N======6 `* S6 D9 V4 `
+------+--------+------------------------+---------------+-------+-------+8 I; A4 T4 n# [" t+ R
| Rank | State | MDS | Activity | dns | inos |
- D; p$ ~2 E5 |$ H4 `+------+--------+------------------------+---------------+-------+-------+8 l+ K3 ] Z1 N; }
| 0 | active | R03-MTEST-MN-001.xx.cn | Reqs: 869 s | 445k | 445k |
5 i% g2 i+ V6 [" }% q- z| 1 | active | R03-MTEST-MN-002.xx.cn | Reqs: 0 s | 365k | 365k |
# ]% ^2 ~/ I% [+------+--------+------------------------+---------------+-------+-------+9 v7 k* l$ s" o6 X1 f5 D- ~
+----------------------+----------+-------+-------+
2 }- ?3 D1 W; [9 j* Y& z3 O| Pool | type | used | avail |
6 Z: W* \- @/ _) R1 h+ p! x+----------------------+----------+-------+-------+( f$ o, Z G" Y+ n7 H% \
| cephfs.metadata.pool | metadata | 186G | 762G |+ g4 B. q6 B4 K. g& K2 M
| cephfs.data.pool1 | data | 412T | 910T |
$ v7 d: G; B. }1 Q/ d* y2 N/ `# O| cephfs.data.pool2 | data | 366T | 945T |$ J( \: e# w, v2 v" F6 `
+----------------------+----------+-------+-------+" g9 \7 X% ?+ ]0 m
+------------------------+
; H R- L( ` ]0 U0 w( s| Standby MDS |! h! q2 j3 Y9 [7 R8 c
+------------------------+
0 _. \, l. E$ B- N# ~| R03-MTEST-MN-003.xx.cn |
) V( j1 d; s6 H" U, e+------------------------+
9 g0 ]! m1 d3 B+ `( S" m9 s5 ~MDS version: ceph version 14.2.20 (36274af6eb7f2a5055f2d53ad448f2694e9046a0) nautilus (stable)4 ~. b- r% V; |' ?
看是备是直接顶上了，mds重启后自动做备，业务侧暂时没有发现有问题，不过，发现写入的流量都打到了同一个mds，不知道是不是因为rank序号变化导致的 测试发现，当单个目录对象数达到千万级时，cephfs的目录出现明显的卡顿，测试读，读取偶尔会有问题，流量不稳定，最大可到1GiB/s，最小只有几百M io:$ e7 c( ]& K) f# V k5 b
client: 240 MiB/s rd, 559 KiB/s wr, 102 op/s rd, 0 op/s wr7 y) `& g0 g$ ^- T0 ^/ r3 u8 s' I5 B
结论cephfs 14.2.20测试结果来看，稳定性可靠性还是可以的，至少内存的问题看来是解决了，没有出现持续大量数据写入时产生的高内存占用问题，同时，重启其中一个rank，备用的mds会自动顶上，业务没有太大影响，而且，目录内的文件数量只要不是太大，小于百万级的话，性能也没有太大的问题，因此，14.2.20及后续版本的cephfs应该是可以上生产的了 反观此前的版本，12、13都比较拉垮，mds不太靠谱，如果client有故障，读写卡住，mds分分钟给你瘫痪，极具危险性，还是不建议上，如果已经有在线的fs，还是强烈建议迁移到14.2.20+的版本 下一步，将继续测试cephfs的其他异常情况和大规模数据写入后slow req的问题，并对代码逻辑方面进行一些分析， |
发表于 2022-7-26 10:36:35