RedHat Linux LVM LVM - 很好很强大
http://www.iteye.com/topic/283065
LVM (Logic Volume Management,逻辑卷管理),是传统商业Unix就带有的一项高级磁盘管理工具,异常强大。后来LVM移植到了Linux操作系统上,尽管不像原 来Unix版本那么强大,但瘦死的骆驼比马大,Linux的LVM仍然非常强大,可以在生产运行系统上面直接在线扩展硬盘分区,可以把分区umount以 后收缩分区大小,还可以在系统运行过程中把一个分区从一块硬盘搬到另一块硬盘上面去等等,简直就像变魔术,而且这一切都可以在一个繁忙运行的系统上面直接 操作,不会对你的系统运行产生任何影响,很安全。
还是拿JavaEye的网站服务器随便举个小例子吧。话说今天晚上我登录JavaEye网站服务器随便这么一查看磁盘使用状况:- df -h
df -h
竟然发现/home分区的磁盘消耗的很快
- Filesystem Size Used Avail Use% Mounted on
- /dev/mapper/system-home 40G 32G 8G 80% /home
Filesystem Size Used Avail Use% Mounted on/dev/mapper/system-home 40G 32G 8G 80% /home
有点出乎意料,已经使用了80%,如果用光了,可就有点麻烦了,所以为了安全,把/home分区扩大5GB,多给它点硬盘空间,敲入两条shell命令
- lvextend -L +5G /dev/system/home
- resize_reiserfs -s +5G /dev/system/home
lvextend -L +5G /dev/system/homeresize_reiserfs -s +5G /dev/system/home
先把逻辑卷扩大5GB,再把上面的reiserfs文件系统扩大5GB,前后耗时不超过3秒钟。再df -h查看一下:
- Filesystem Size Used Avail Use% Mounted on
- /dev/mapper/system-home 45G 32G 13G 71% /home
Filesystem Size Used Avail Use% Mounted on/dev/mapper/system-home 45G 32G 13G 71% /home
哈哈,/home立刻多了5GB,搞定收工,这是不是很像变戏法,我没停任何服务,没重起服务器,大家没有任何感觉,就一切搞定,说实话我也一直 觉得LVM很cool,所以我一直是LVM+Reiserfs的忠实拥趸。有兴趣学习LVM的同学可以下载后面的附件,这可是我珍藏多年的LVM秘籍!
另外强烈推荐Daniel Robbins在IBM DW网站上面关于LVM的系列文章: 另外,在大规模的生产系统上面,文件系统的管理是一个错综复杂的工作,如果你对这个方面的知识很感兴趣,你可以继续了解一下 EVMS(Enterprise Volume Management System,企业级文件卷管理系统)。EVMS 为 Linux 下的所有存储技术提供了统一的、可扩展的、基于插件的 API。这意味着什么?它意味着由于 EVMS,您可以使用单个工具来对磁盘分区、创建 LVM 对象以及甚至创建 Linux 软件 RAID 卷。并且可以使用这一工具以强有力的方式合并这些技术。还是推荐看Daniel Robbins的文章: BTW:Daniel Robbins在IBM DW所有的文章都值得一读,特别是《通用线程: 高级文件系统实现者指南》这个系列。- (335.8 KB)
RedHat Linux Disk mount / 翟翔(13110508)
磁盘状态为加载过,分两种情况:
A、虚拟机删除,数据盘未删除;
B、虚拟机迁移,原物理机上数据盘未删除。
umount 的时候报错:device is busy
http://liuyu.blog.51cto.com/183345/64044
linux分区知识与大磁盘的分区
http://www.iteye.com/topic/521107
...balabala...
GPT硬盘不能用于lvm ?
Linux LVM-逻辑卷管理 / Apache Traffic Server / ATS Cache Server
http://wiki.cns*****.com/pages/viewpage.action?pageId=17403026
Linux LVM-逻辑卷管理
场景:
CDN节点上安装完ats(Apache Trafficserver)后,配置ats,需要指定一个大的磁盘用来存放cache。根据服务器的分区情况,分两种操作
1、查看磁盘分区:
http://dl2.iteye.com/upload/attachment/0101/0028/30f34a85-0583-397c-a399-07cae20a40ef.png
存在一个独立的大磁盘分区挂载到/cache 目录,此时只需要将ats的cache目录配置为: /cache 350G
2、查看磁盘分区
http://dl2.iteye.com/upload/attachment/0101/0032/5917480e-7a89-35ff-a33b-e2d2925cc46d.png
不存在足够大的分区(400G左右)供ats存放缓存
我们只能选择一个裸盘 供ats使用,默认我们选择 /dev/sda2
问题:
但是使用/dev/sda2的服务器发生了问题,服务器运行一段时间后,系统down掉,解决方法:只能重装系统。
分析问题:
分析后,定位原因:
fdisk -l # fdisk -l 可以列出所有的分区,包括没有挂上的分区和usb设备,
http://dl2.iteye.com/upload/attachment/0101/0036/df8e7a47-3b58-399c-afd7-2498a1e13fb4.png
我们选择使用的 /dev/sda2 是 Id为8e,即分区的类型是 Linux LVM
=============
对Linux LVM的说明:
LVM的全称为Logical Volume Manager,它是Linux环境下对磁盘分区进行管理的一种机制,LVM是建立在硬盘和分区之上的一个逻辑层,来提高磁盘分区管理的灵活性。通过LVM系统管理员可以轻松管理磁盘分区,如:将若干个磁盘分区连接为一个整块的卷组(volume group),形成一个存储池。管理员可以在卷组上随意创建逻辑卷组(logical volumes),并进一步在逻辑卷组上创建文件系统
在以往的Linux系统中(比Redhat AS4更早的版本),默认是不支持LVM逻辑卷管理的当磁盘连接到服务器后,使用fdisk将其划分为主分区和扩展分区随后直接把分区进行格式化,生成诸如/dev/sda1、/dev/sda2之类的分区这些分区可以直接用mount命令挂载到目录来使用当应用了LVM后,磁盘分区类型为Linux LVM的/dev/sda1、/dev/sda2这样的分区会被LVM认为是一整个VG,即卷组这样的卷组是不能直接挂载的,需要由LVM转换成类似/dev/mapper/这样的VG卷组,每个VG又包含LV(逻辑卷),想要使用他们只需要将逻辑卷挂载到目录
==================
解决方法:
使用卷组查看命令vgdisplay查看卷组情况
http://dl2.iteye.com/upload/attachment/0101/0040/9b6b943f-79fb-3561-be19-a5a3a6d0ec2f.png
卷组名为:systemvg
可用大小:475G
步骤:
1、创建逻辑卷LV(Logical Volumes),命名为:cachelv,所属的卷组VG(Volume Groups)为systemvg,-L指定逻辑分区大小为400G
lvcreate -n cachelv -L 400G systemvg
2、创建文件系统
mkfs.ext4 /dev/systemvg/cachelv
3、挂载
mount /dev/systemvg/cachelv /cache
4、添加到 fstab #用fstab可以自动挂载各种文件系统格式的硬盘、分区、可移动设备和远程设备等
vi /etc/fstab/dev/systemvg/cachelv /cache ext4 defaults 0 0
以上操作完成后,df -h 查看:
将ats的cache目录指定为 /cache 就ok了
“苏*宁公有云”项目
http://eitp.cns*****.com/itp-web-in/resourcepool/resourceInfoRead.htm?employeeid=13073414
需求描述:
1、整合苏宁上游的服务提供者和下游最终用户,打造新的价值链和生态系统。
2、与竞品京东云、阿里云等竞争,积极扩大苏宁的用户群,提升苏宁的技术实力。
3、通过公有云项目,积极参与到开源技术领域,扩大苏宁在技术行业的影响力。
解决方案描述:
1. 搭建基于Cloudstack的公有云平台,使用KVM作为虚拟化层支撑。
2. 搭建苏宁公有云平台作为自助式管理门户,提供服务。
LVM数据丢失,替换数据盘
http://wiki.cns*****.com/pages/viewpage.action?pageId=19368510
Cloudstack资料收集
Cloudstack运维及优化
Openstack部署运维
Openstack技术调研
Openstack业界动态
苏*宁私有云支撑
File Lists
苏宁公有云支撑
CS问题对应列表
RDS 问题对应列表
对象存储问题列表
系统相关
LVM数据丢失,替换数据盘
http://wiki.cns*****.com/pages/viewpage.action?pageId=19368510
一、缘由
在linux虚机通过LVM将数据盘拓展到了opt目录,在数据盘损坏以后,使用新的数据盘替换损坏的数据盘。
二、操作
1.卸载源数据盘、添加新数据盘
2.创建PV:pvcreate /dev/vdc
lvremove /dev/systemvg/optlv vgreduce --removemissing systemvg vgextend systemvg /dev/vdc lvcreate /dev/systemvg/optlv lvcreate -n optlv -L 79G systemvg mkfs.ext4 /dev/systemvg/optlv mount /dev/systemvg/optlv /opt/3.最后重启服务器验证
小结一下linux 2.6内核的四种IO调度算法
http://jackyrong.iteye.com/blog/898938
在LINUX 2.6中,有四种关于IO的调度算法,下面综合小结一下:
linux IO调度算法
http://www.cnblogs.com/cutepig/p/3403711.html
1) NOOP (电梯式调度程序)
NOOP算法的全写为No Operation。该算法实现了最最简单的FIFO队列,所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”,原因是NOOP在FIFO的基础上还做了相邻IO请求的合并,并不是完完全全按照先进先出的规则满足IO请求。NOOP假定I/O请求由驱动程序或者设备做了优化或者重排了顺序(就像一个智能控制器完成的工作那样)。在有些SAN环境下,这个选择可能是最好选择。Noop 对于 IO 不那么操心,对所有的 IO请求都用 FIFO 队列形式处理,默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然,对于复杂一点的应用类型,使用这个调度器,用户自己就会非常操心。
2) Deadline scheduler (截止时间调度程序)
DEADLINE在CFQ的基础上,解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外,DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms,写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高,,而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下:
FIFO(Read) > FIFO(Write) > CFQ
deadline 算法保证对于既定的 IO 请求以最小的延迟时间,从这一点理解,对于 DSS 应用应该会是很适合的。
3) Anticipatory scheduler (预料I/O调度程序)
CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求,比如顺序读,并没有做优化。为了满足随机IO和顺序IO混合的场景,Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上,为每个读IO都设置了6ms
的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求,就可以立即满足
Anticipatory scheduler(as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是”预料的, 预想的”, 这个词的确揭示了这个算法的特点,简单的说,有个 IO 发生的时候,如果又有进程请求 IO 操作,则将产生一个默认的 6 毫秒猜测时间,猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时,对数据库应用很糟糕,而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的,因为那个”猜测”实际上的目的是为了减少磁头移动时间。
4)CFQ (完全公平排队I/O调度程序)
CFQ算法的全写为Completely Fair Queuing。该算法的特点是按照IO请求的地址进行排序,而不是按照先来后到的顺序来进行响应。
在传统的SAS盘上,磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序,以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下,SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是,先来的IO请求并不一定能被满足,可能会出现饿死的情况。
Completely Fair Queuing (cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列,各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中,SuSE Linux 好像是最先默认用 cfq 的.
查看和修改IO调度器的算法非常简单。假设我们要对sda进行操作,如下所示:
cat /sys/block/sda/queue/scheduler
echo “cfq” > /sys/block/sda/queue/scheduler
总结:
1 CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求,比如顺序读,并没有做优化。为了满足随机IO和顺序IO混合的场景,Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上,为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求,就可以立即满足。
IO调度器算法的选择,既取决于硬件特征,也取决于应用场景。
在传统的SAS盘上,CFQ、DEADLINE、ANTICIPATORY都是不错的选择;对于专属的数据库服务器,DEADLINE的吞吐量和响应时间都表现良好。然而在新兴的固态硬盘比如SSD、Fusion IO上,最简单的NOOP反而可能是最好的算法,因为其他三个算法的优化是基于缩短寻道时间的,而固态硬盘没有所谓的寻道时间且IO响应时间非常短。
2 对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点,而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3,整体 IO 改进还是不小的。
IO调度器的总体目标是希望让磁头能够总是往一个方向移动,移动到底了再往反方向走,这恰恰就是现实生活中的电梯模型,所以IO调度器也被叫做电梯. (elevator)而相应的算法也就被叫做电梯算法.而Linux中IO调度的电梯算法有好几种,一个叫做as(Anticipatory),一个叫做 cfq(Complete Fairness Queueing),一个叫做deadline,还有一个叫做noop(No Operation).具体使用哪种算法我们可以在启动的时候通过内核参数elevator来指定.
一)I/O调度的4种算法1)CFQ(完全公平排队I/O调度程序)
特点:
在最新的内核版本和发行版中,都选择CFQ做为默认的I/O调度器,对于通用的服务器也是最好的选择.CFQ试图均匀地分布对I/O带宽的访问,避免进程被饿死并实现较低的延迟,是deadline和as调度器的折中.CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择.CFQ赋予I/O请求一个优先级,而I/O优先级请求独立于进程优先级,高优先级的进程的读写不能自动地继承高的I/O优先级. 工作原理:CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,以此来保证每个进程都能被很好的分配到I/O带宽.I/O调度器每次执行一个进程的4次请求. 2)NOOP(电梯式调度程序)特点:
在Linux2.4或更早的版本的调度程序,那时只有这一种I/O调度算法.NOOP实现了一个简单的FIFO队列,它像电梯的工作主法一样对I/O请求进行组织,当有一个新的请求到来时,它将请求合并到最近的请求之后,以此来保证请求同一介质.NOOP倾向饿死读而利于写.NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.电梯算法饿死读请求的解释:
因为写请求比读请求更容易.写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中.读请求需要等到它前面所有的读操作完成,才能进行下一次读操作.在读操作之间有几毫秒时间,而写请求在这之间就到来,饿死了后面的读请求.3)Deadline(截止时间调度程序)
特点:
通过时间以及硬盘区域进行分类,这个分类和合并要求类似于noop的调度程序.Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择. 4)AS(预料I/O调度程序)特点:
本质上与Deadline一样,但在最后一次读操作后,要等待6ms,才能继续进行对其它I/O请求进行调度.可以从应用程序中预订一个新的读请求,改进读操作的执行,但以一些写操作为代价.它会在每个6ms中插入新的I/O操作,而会将一些小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.AS适合于写入较多的环境,比如文件服务器AS对数据库环境表现很差.查看当前系统支持的IO调度算法
dmesg | grep -i scheduler[root@localhost ~]# dmesg | grep -i scheduler
io scheduler noop registeredio scheduler anticipatory registeredio scheduler deadline registeredio scheduler cfq registered (default)查看当前系统的I/O调度方法:
cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]临地更改I/O调度方法:
例如:想更改到noop电梯调度算法:echo noop > /sys/block/sda/queue/scheduler想永久的更改I/O调度方法:
修改内核引导参数,加入elevator=调度程序名vi /boot/grub/menu.lst更改到如下内容:kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet 重启之后,查看调度方法:cat /sys/block/sda/queue/schedulernoop anticipatory [deadline] cfq已经是deadline了
四)I/O调度程序的测试
本次测试分为只读,只写,读写同时进行.
分别对单个文件600MB,每次读写2M,共读写300次.1)测试磁盘读:
[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 6.81189 seconds, 92.4 MB/sreal 0m6.833s
user 0m0.001ssys 0m4.556s[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 6.61902 seconds, 95.1 MB/sreal 0m6.645s
user 0m0.002ssys 0m4.540s[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 8.00389 seconds, 78.6 MB/sreal 0m8.021s
user 0m0.002ssys 0m4.586s[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 29.8 seconds, 21.1 MB/sreal 0m29.826s
user 0m0.002ssys 0m28.606s结果:第一 noop:用了6.61902秒,速度为95.1MB/s第二 deadline:用了6.81189秒,速度为92.4MB/s第三 anticipatory:用了8.00389秒,速度为78.6MB/s第四 cfq:用了29.8秒,速度为21.1MB/s 2)测试写磁盘:[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 6.93058 seconds, 90.8 MB/sreal 0m7.002s
user 0m0.001ssys 0m3.525s[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 6.79441 seconds, 92.6 MB/sreal 0m6.964s
user 0m0.003ssys 0m3.489s[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 9.49418 seconds, 66.3 MB/sreal 0m9.855s
user 0m0.002ssys 0m4.075s[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 6.84128 seconds, 92.0 MB/sreal 0m6.937s
user 0m0.002ssys 0m3.447s测试结果:
第一 anticipatory,用了6.79441秒,速度为92.6MB/s第二 deadline,用了6.84128秒,速度为92.0MB/s第三 cfq,用了6.93058秒,速度为90.8MB/s第四 noop,用了9.49418秒,速度为66.3MB/s 3)测试同时读/写[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 15.1331 seconds, 41.6 MB/s[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 36.9544 seconds, 17.0 MB/s[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 23.3617 seconds, 26.9 MB/s[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300300+0 records in300+0 records out629145600 bytes (629 MB) copied, 17.508 seconds, 35.9 MB/s测试结果:
第一 deadline,用了15.1331秒,速度为41.6MB/s第二 noop,用了17.508秒,速度为35.9MB/s第三 anticipatory,用了23.3617秒,速度为26.9MS/s第四 cfq,用了36.9544秒,速度为17.0MB/s五)ionice
ionice可以更改任务的类型和优先级,不过只有cfq调度程序可以用ionice.
有三个例子说明ionice的功能:采用cfq的实时调度,优先级为7ionice -c1 -n7 -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&采用缺省的磁盘I/O调度,优先级为3ionice -c2 -n3 -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&采用空闲的磁盘调度,优先级为0ionice -c3 -n0 -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&ionice的三种调度方法,实时调度最高,其次是缺省的I/O调度,最后是空闲的磁盘调度.
ionice的磁盘调度优先级有8种,最高是0,最低是7.注意,磁盘调度的优先级与进程nice的优先级没有关系.一个是针对进程I/O的优先级,一个是针对进程CPU的优先级.
Anticipatory I/O scheduler 适用于大多数环境,但不太合适数据库应用
Deadline I/O scheduler 通常与Anticipatory相当,但更简洁小巧,更适合于数据库应用
CFQ I/O scheduler 为所有进程分配等量的带宽,适合于桌面多任务及多媒体应用,默认IO调度器
Default I/O scheduler
问题一:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %utilsdi 82.40 8.90 67.00 5.30 8641.20 56.80 240.61 0.08 1.09 0.93 6.76上面sdi是一块SSD盘,SSD又不是机械盘,怎么会有rrqm这些合并值呢?我的理解是内核把这些指标统一对待了? 意思是这些指标对SSD不适用问题二:SSD的%util参数很低,但是明显感觉SSD性能到瓶颈了,难道说%util参数也是打酱油的?
end