ceph 壓力測試

時間  2019-12-05
標籤 ceph 壓力 測試 简体版
原文   原文鏈接

[TOC]java

ceph 壓力測試報告

此文檔最新版本地址ios

概述

對ceph文件集羣進行性能測試, 以確認知足咱們業務需求. 這次測試主要測試S3接口讀寫文件性能.centos

測試環境

網絡拓撲結構

以下圖, client和三臺OSD集羣在同一個內網, 每臺OSD機器上, 分別裝有MON和RGW. 測試時同時使用多個RGW, 由客戶端控制將請求分發到不一樣RGW服務. 因部署遺留緣由, 三臺OSD機器編號從2開始, 分別是 DFS2, DFS3, DFS4.api

image

軟硬件環境

OSD服務器

服務器 硬件配置 軟件配置
DFS2 Intel Core i7-4790@ 3.60GHz 四核八線程 8G DDR3內存 1T 7200轉硬盤, 1000M網口 centos 7.2, ceph 10.2.2
DFS3 Intel Core i7-4790@ 3.60GHz 四核八線程 8G DDR3內存 1T 7200轉硬盤, 1000M網口 centos 7.2, ceph 10.2.2
DFS4 Intel Core i7-4790@ 3.60GHz 四核八線程 16G DDR3內存 1T 7200轉硬盤, 1000M網口 centos 7.2, ceph 10.2.2

測試客戶端服務器

服務器 | 硬件配置|軟件配置 --|--|-- 10.141.5.63|雙核 Intel Xeon CPU E7- 4850 @ 2.00GHz, 4G內存, 1000M網口| centos 6.8, java 1.7.0_79 10.141.4.83|四核 Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GHz, 8G內存, 1000M網口| centos 6.7, java 1.8.0_92緩存

測試軟件

基於aws api本身寫的 java 客戶端. 另外, 有推薦 cosbench 的. 之後能夠看看.服務器

maven依賴:網絡

<dependency>
	<groupId>com.amazonaws</groupId>
	<artifactId>aws-java-sdk-s3</artifactId>
	<version>1.9.0</version>
</dependency>

壓測數據

注意: 壓測過程當中, index副本數設置爲1, 會比默認的3效率高些.app

中等文件寫入壓測

測試內容: 文件大小95M,上傳50次
在客戶端5個線程,20個線程,50個線程 3種狀況下得出數據:maven

1個副本 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 5|75.731|62.96|0.66 20|65.947|72.306|0.758 50(一條請求超時)|83.37|57.195|0.5997 數據簡單分析:性能

  • 最高寫入速度也在70 M/s左右.
  • 三臺OSD中的兩臺磁盤io幾乎達到100%, 一臺在90%左右. 磁盤成爲性能瓶頸.
  • 線程數過多(50), 性能不升反降, 還會有超時現象.

2個副本 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 5|139.247|34.2439|0.359 20|147.913|32.237|0.338 50|138.832|34.346|0.360

數據簡單分析: 瓶頸與1個副本1個RGW相似, 瓶頸在磁盤io. 兩個副本最大寫入速度在35M/s左右.

3個副本 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|223.859|21.30|0.223 5|227.563|20.954|0.2197 20|234.088|20.37|0.21359

數據簡單分析: 瓶頸與1個副本1個RGW相似, 瓶頸在磁盤io. 三個副本最大寫入速度在30M/s左右.

小文件寫入壓測

測試內容: 文件大小30 000字節,上傳5000次
客戶端在啓用20個線程,100個線程,200個線程 3種狀況下得出數據:

設置了 index 分片爲16. 默認index不分片, 會形成寫索引時單臺OSD成爲瓶頸, 磁盤io佔滿(大約每秒寫30個對象).

兩個副本, 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|52.426|2.796|95.37 100|34.78|4.2158|143.76 200|34.417|4.26|145.277

資源佔用 dstat信息:
20個線程:
image
100個線程:
image
200個線程:
image

磁盤佔用 iostat信息:
20個線程:
image
100個線程:
image
200個線程:
image

數據簡單分析:

  • 最高文件上傳速度在每秒145個文件左右. 從20個線程到100個線程過程當中, 寫入速度明顯提高; 100個線程後, 達到峯值.
  • 在壓測過程當中, 系統CPU佔用很低. 從20個線程增加到200個線程, CPU佔用增加不明顯, 系統空閒CPU一直維持在80%以上.
  • 到100個線程之後, 磁盤 io 佔用率達到100%, 成爲系統瓶頸. 儘管寫入量並不大, 可是由於大量小文件致使大量寫入, 使磁盤時間佔滿.
  • 客戶端在線程少的狀況下, 不足以達到最高吞吐量.

單副本, 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|41.833|3.505|119.523 100|30.929|4.741|161.66 200|40.984|3.577|122

數據簡單分析:

  • 系統佔用狀況和磁盤佔用狀況和兩個副本時類似, 這裏省略.
  • 單副本最高文件寫入速度在每秒160個左右. 從客戶端20個線程到100個線程過程增加明顯, 100個線程達到峯值, 從100到200之間有降低趨勢.
  • 在200個線程時, 比100個線程速度要降低. 再數據出來之後又測試了屢次, 200個線程通常和100個線程速度持平. 這個數據是一個特例.
  • 和兩個副本相比, 由於要一份數據不須要保存兩份到不一樣機器上, 減小了了網絡和磁盤開銷. 致使速度要比兩個副本快.

三個副本, 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|74.018|1.98|67.55 100|47.283|3.101|105.746 200|45.983|3.1887|108.7

  • 系統佔用狀況和磁盤佔用狀況和兩個副本時類似, 這裏省略.
  • 三個副本狀況下, 最高文件寫入速度在每秒105個左右. 從客戶端20個線程到100個線程過程當中, 增加明顯; 100個線程達到峯值; 超過100個線程, 寫入速度保持在105個左右.
  • 和兩個副本相比, 由於一份數據須要保存到三臺機器上, 增大了網絡和磁盤開銷. 致使速度要比兩個副本慢.

大文件讀取壓測

因文件讀取耗費大量CPU, 因此使用83測試機, 不讓客戶端配置成爲性能瓶頸.

壓測方式: 上傳30個100M的文件, 下載時隨機選取文件下載.

三個副本, 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|44.875|1.1142|106.259 100|44.286|1.129|107.672 200|44.4|1.126|107.395

內存佔用 free -g:

[root@dfs2 ~]# free -g
              total        used        free      shared  buff/cache   available
Mem:              7           1           2           0           3           5
Swap:             7           0           7

磁盤佔用 iostat:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.00    0.00    3.00     0.00     0.02    16.00     0.03   10.50    0.00   10.50  10.50   3.15
dm-0              0.00     0.00    0.00    4.00     0.00     0.02    12.00     0.03    7.88    0.00    7.88   7.88   3.15
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

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.00    0.00    6.00     0.00     0.03    10.67     0.06   10.17    0.00   10.17  10.17   6.10
dm-0              0.00     0.00    0.00    6.00     0.00     0.03    10.67     0.06   10.50    0.00   10.50  10.17   6.10
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

系統資源佔用 dstat:
image

數據簡單分析:

  • 大文件讀取, 單個rgw, 最高在107M左右. 從客戶端20線程增長到200線程, 讀取速度增加不明顯.
  • 內存還有足夠餘量, 磁盤io佔用也不高.
  • 從系統資源佔用上來看, RGW所在機器網卡接收和發送已經達到114M/s左右, 1000M網卡理論最快速度在 1000M bit/8 = 125M 每秒. 因此能夠認爲網卡已經跑滿, 瓶頸在1000M網卡上.

一個副本, 1個RGW

兩個副本, 1個RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|44.663|1.119|106.763 100|43.932|1.138|108.5398 200|43.961|1.137|108.468

數據簡單分析:

  • 數據和三個副本下狀況類似. 瓶頸在網卡上.

小文件讀取壓測

壓測方式: 上傳100 000個小文件, 下載時隨機選取文件下載, 下載100000次.

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|30.437|3285.4749|96.347 100|28.186|3547.86|104.04 200|28.578|3499.19|102.61

rgw機器內存佔用狀況.

[root@dfs2 ~]# free -g
              total        used        free      shared  buff/cache   available
Mem:              7           1           0           0           6           5
Swap:             7           0           7

rgw機器, 磁盤佔用狀況

[root@dfs2 ~]# iostat -mdx 2
Linux 3.10.0-327.22.2.el7.x86_64 (dfs2) 	08/29/2016 	_x86_64_	(8 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.01     3.09    1.06   13.40     0.14     0.56    98.73     0.51   35.16    4.11   37.63   7.69  11.13
dm-0              0.00     0.00    1.07   13.96     0.14     0.56    94.99     0.76   50.65    4.26   54.21   7.41  11.13
dm-1              0.00     0.00    0.00    0.04     0.00     0.00     8.05     0.00   21.78    5.51   22.67   0.71   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     5.50    0.00   10.00     0.00     0.08    17.20     0.10   10.40    0.00   10.40  10.40  10.40
dm-0              0.00     0.00    0.00   12.50     0.00     0.08    13.76     0.11    8.56    0.00    8.56   8.32  10.40
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

RGW機器資源佔用狀況 dstat:

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
 18   7  74   0   0   2|   0   108k|  78M  116M|   0     0 |  29k  191k
 18   6  73   0   0   2|   0   116k|  76M  115M|   0     0 |  29k  191k
 18   6  74   0   0   2|   0    48k|  77M  116M|   0     0 |  30k  189k
 18   6  74   0   0   2|   0    36k|  80M  116M|   0     0 |  30k  189

數據簡單分析:

  • 小文件讀取速度可達每秒100M, 每秒能夠讀取3500個大約3K的文件. //TODO 內存策略? 這些數據已經緩存到內存中?
  • 從硬件使用狀況來看, 讀取瓶頸在1000M網口上.

硬盤參數優化, 寫入壓測(nobarrier)

開啓/關閉 xfs nobarrier 參數:

# 開啓
mount -o remount,nobarrier {/dev/mapper/cl_bogon-root} {/}
# 關閉
mount -o remount,barrier {/dev/mapper/cl_bogon-root} {/}

壓測數據:

副本數爲3, index分片爲8, 分別在barrier和nobarrier上傳文件:

barrier 文件大小30k, 上傳5000次

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|225.018|0.65|22.22 20| 55.719|2.63|89.7 100|46.484|3.154|107.56

nobarrier 文件大小30k, 上傳5000次

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|48.147|3.045|103.848 20| 11.237|13.0486|444.958 100|9.969|14.708|501.55

barrier 文件大小100M, 上傳50次

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|223.859|21.30|0.223 5|227.563|20.954|0.2197 20|234.088|20.37|0.21359

nobarrier 文件大小100M, 上傳50次

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|144.14|33.08|0.3468 5|135.583|35.169|0.3687 20|141.82|33.62|0.3525

數據簡單分析:

  • 關閉 xfs文件系統 barrier 選項之後, 使小文件寫入性能提高5倍左右. 效果很是可觀. 100M左右文件, 性能提高爲之前的1.65倍左右(網卡還沒跑滿, 瓶頸在磁盤io).
  • 官方雖然不建議關閉nobarrier選項, 可是咱們有數據多機器寫入多個副本. 可是存在OSD機器在一個機房, 當遭遇同一機房停電狀況, 數據就會損壞的極端狀況. 這個視具體狀況而定. 若是寫入確實是系統瓶頸, 則建議使用nobarrier選項. 也能夠臨時不使用nobarrier選項, 當達到性能瓶頸之後, 再使用.

壓測總結

  1. 100M文件寫最高 入單副本 70M/s, 兩個副本35M/s, 三個副本20M每秒, 瓶頸在磁盤io. //TODO 進一步分析哪一個環節影響效率(文件數據寫入/索引寫入/日誌寫入) 這塊能夠經過加入更多OSD服務器, 升級SSD硬盤來進一步優化.
  2. 30K文件寫入在index分片(16個分片)的狀況下, 單副本寫入每秒能達到160個文件, 兩副本最高能達到每秒145個文件寫入, 三副本最高能達到每秒 105個文件. 性能瓶頸在磁盤io上. index不分片, 寫入index讓對應機器磁盤成爲瓶頸. 最高在每秒30個文件左右.
  3. 100M文件讀取, 1~3個副本, 都能達到 100M/s 的讀取速度. 性能瓶頸在1000M網卡上.
  4. 30K文件讀取, 1~3個副本, 都能達到100M/s的速度. 性能瓶頸在1000M網卡上. //TODO 這個會對緩存進行清理再測測試.
  5. 測試過程當中千兆網絡很容易成爲系統瓶頸. 在生產部署時, 最好使用萬兆網絡. 考慮client網絡和cluster網絡分離(http://docs.ceph.com/docs/master/rados/configuration/network-config-ref/)
  6. 測試過程當中, index 副本數設置爲1, 沒有找到index丟失的狀況下(機率低), 從數據文件重建的方法, 建議線上環境設置大於等於2.
  7. 關閉 xfs文件系統 barrier 選項之後, 使文件寫入性能提高明顯. 若是對寫入要求較高的場景, 建議使用nobarrier選項.
  8. 因文件寫入瓶頸在磁盤io上, 測試過程當中, 還增長OSD 操做線程數, OSD操做硬盤線程數, 小文件寫入都沒有提高.
  9. 由於測試過程當中, RGW部署在OSD服務器上, RGW和同一臺機器上的OSD訪問網絡開銷會小不少. 分開部署網絡開銷會高一些. 網絡影響很大.
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程