AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

VXFS启用异步IO导致的严重问题

2014-08-06 971
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 今天在做数据迁移的时候，碰到了一个严重的问题，数据加载完全hang住了，最后无奈回退了。 系统使用的vxfs文件系统，在生产升级前一个月的时候，做过一次小规模的数据迁移，当时查看awr,ash，最后根据addm的推荐得出加载速度比较慢主要是由于异步IO导致的，而且当时生产库确实没有启用异步io, filesystemio_option的设置为none，在经过确认之后，在半个月前的一此例行维护中，由客户做了这个配置的修改。
今天在做数据迁移的时候，碰到了一个严重的问题，数据加载完全hang住了，最后无奈回退了。

系统使用的vxfs文件系统，在生产升级前一个月的时候，做过一次小规模的数据迁移，当时查看awr,ash，最后根据addm的推荐得出加载速度比较慢主要是由于异步IO导致的，而且当时生产库确实没有启用异步io, filesystemio_option的设置为none，在经过确认之后，在半个月前的一此例行维护中，由客户做了这个配置的修改。修改后发现iowait明显增加了，当时也没再多跟多的分析因为没有比较明显的性能问题，当时认为iowait高可能和启用了异步io后处理的效率更高有关，反而认为这是一种改进。
在升级的前2天的时候，做数据迁移前的检查工作的时候就做了一次简单的io分析。其中使用了dd来做了一个小测试。
发现io的速度很差，相比测试环境有很大的差别。

time dd if=/dev/zero bs=1M count=204 of=direct_200M

213909504 bytes (214 MB) copied, 5.27558 seconds, 40MB/s40.5 MB/s  
real    0m5.284s  
user    0m0.003s  
sys     0m0.031s  
以下是当时做的sar的记录。
07:00:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle  
09:20:01 AM       all     10.48      0.11      1.76      2.89      0.00     84.76  
09:30:01 AM       all     10.59      0.10      1.81      2.45      0.00     85.04  
09:40:01 AM       all      7.91      0.18      1.61      3.20      0.00     87.10  
09:50:01 AM       all      7.26      0.07      1.66      3.23      0.00     87.78  
10:00:01 AM       all      7.54      0.13      1.53      3.67      0.00     87.13  
10:10:01 AM       all      7.78      0.09      1.76      3.92      0.00     86.45  
10:20:01 AM       all      8.24      0.09      2.27      3.98      0.00     85.43  
10:30:01 AM       all      7.38      0.08      1.79      5.18      0.00     85.57  
10:40:01 AM       all      8.14      0.16      2.01      6.36      0.00     83.33  
10:50:02 AM       all      7.05      0.10      1.74      4.83      0.00     86.29  
11:00:01 AM       all      7.61      0.09      2.04      5.43      0.00     84.83  
11:10:01 AM       all      7.22      0.09      1.70      6.22      0.00     84.76  
11:20:01 AM       all      6.71      0.12      2.10      7.35      0.00     83.72  
11:30:01 AM       all      9.36      0.10      2.87      5.03      0.00     82.63  
11:40:01 AM       all      7.26      0.25      1.76      6.08      0.00     84.65  
11:50:01 AM       all      7.17      0.12      2.40      5.24      0.00     85.07  
12:00:01 PM       all      6.30      0.10      2.64      5.27      0.00     85.69  
Average:          all     10.36      0.26      1.14      3.40      0.00     84.83  
 一个月前的数据情况
Production statistics 20-June-14:  
204+0 records in
204+0 records out
213909504 bytes (214 MB) copied, 1.44182 seconds, 148 MB/s
real    0m1.445s
user    0m0.001s
sys     0m0.039s  
测试环境
TEST machine statistics:  
204+0 records in  
204+0 records out  
213909504 bytes (214 MB) copied, 0.550607 seconds, 388 MB/s  
real    0m0.595s  
user    0m0.001s  
sys     0m0.072s  
另外一个数据迁移服务器
TEST2 machine statistics:  
213909504 bytes (214 MB) copied, 0.320128 seconds, 668 MB/s  
real    0m0.43s  
user    0m0.01s  
sys     0m0.42s  

结果这个问题在升级前还是没有解决，在数据迁移的时候就最终回退了。

在做数据的merge的时候，强制启用了parallel，但是通过top命令看到cpu的使用率可怜的低。
使用dd简单测试，竟然最低达到了15M/s左右。

以下是当时查看top的结果。
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31130 root 10 -5 0 0 0 S 20.5 0.0 1352:56  [vxfs_thread]
17285 oraccbs1 16 0 18.3g 114m 35m S 12.9 0.0 4:56.41 ora_p026_PRODB
18568 oraccbs1 16 0 18.3g 50m 22m D 7.3 0.0 2:40.81 ora_p056_PRODB
18580 oraccbs1 16 0 18.2g 42m 21m D 4.6 0.0 2:24.26 ora_p062_PRODB
 7846 oraccbs1 16 0 18.5g 315m 47m S 4.0 0.1 0:12.23 oraclePRODB  (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
18576 oraccbs1 16 0 18.2g 42m 21m D 3.6 0.0 2:25.63 ora_p060_PRODB
11334 tivoliam 15 0 820m 89m 14m S 3.3 0.0 341:18.97 /opt/app/IBM/ITM/lx8266/lz/bin/klzagent
18570 oraccbs1 16 0 18.2g 42m 21m D 3.3 0.0 2:25.69 ora_p057_PRODB
18578 oraccbs1 16 0 18.2g 42m 21m D 3.0 0.0 2:23.12 ora_p061_PRODB

稍后就看到parallel启用的很艰难。过一会才能看到几个相关的进程。
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31130 root 10 -5 0 0 0 S 5.6 0.0 1371:05 [vxfs_thread]
11334 tivoliam 15 0 820m 89m 14m S 3.3 0.0 342:47.68 /opt/app/IBM/ITM/lx826
 1388 root 18 0 59116 784 568 S 1.6 0.0 0:13.80 sadc 5 1001 -z
 4661 oraccbs1 15 0 18.2g 24m 4272 S 1.3 0.0 23:40.35 ora_dbw2_PRODB
27545 oraccbs1 16 0 13428 1844 816 R 1.0 0.0 0:02.35 top -c 
 2833 root 16 0 127m 71m 3520 S 0.7 0.0 81:28.54 vxconfigd -x syslog
 4653 oraccbs1 18 0 18.3g 130m 14m S 0.7 0.0 221:18.30 ora_dia0_PRODB
 4663 oraccbs1 15 0 18.2g 24m 3464 S 0.7 0.0 23:48.27 ora_dbw3_PRODB 
 2598 root 15 0 0 0 0 S 0.3 0.0 5:03.01 [dmp_daemon]
 4878 oraccbs1 15 0 18.2g 7140 4396 S 0.3 0.0 67:17.54 ora_mmnl_PRODB 
 5016 root 10 -5 0 0 0 S 0.3 0.0 0:14.14 [kjournald]
 7334 root 18 0 280m 21m 7824 S 0.3 0.0 26:27.83 /opt/VRTSob/bin/vxsvc
19215 root 15 0 37872 9464 2264 S 0.3 0.0 69:47.85 /opt/VRTSvcs/bin/Mount

最后，公司的unix team的一个同事的判断是vxfs的bug，需要打一个补丁。活还得干，看看今晚的进展了。

The first two are major

VXFS version

 

We had IO performance issues with the very same version of VXFS installed in TRUE 6.0.100.000

Eventually we found we were hitting the following bug which is fixed with version 6.0.3 https://sort.symantec.com/patch/detail/8260

this happened at that site – even though it was a fresh install and NOT and upgrade as indicated in the below.

We did see the very same issues of performance degrading when removing the direct mount option

 

Hence we recommend installing this patch

 

SYMPTOM:

Performance degradation is seen after upgrade from SF 5.1SP1RP3 to SF 6.0.1 on

Linux

 

DESCRIPTION:

The degradation in performance is seen because the I/O are not unplugged before

getting delivered to lower layers in the IO path. These I/Os are unplugged by

OS at a default time which 3 milli seconds, which resulted in an additional

overhead in completion of I/Os.

 

RESOLUTION:

Code Changes made to explicitly unplug the I/Os before sending then to the lower

layer.

 

* 3254132 (Tracking ID: 3186971)

 

Power management

Servers should have power management savings disabled set to high performance

Make sure C-state is disabled set to C0

This is executed at the BIOS level and requires a reboot.

文章标签：
测试技术
关键词：
io异步
jeanron100
目录
相关文章
东方睿赢
|
2月前
|
并行计算 数据处理 Python
Python并发编程迷雾：IO密集型为何偏爱异步？CPU密集型又该如何应对？
在Python的并发编程世界中，没有万能的解决方案，只有最适合特定场景的方法。希望本文能够为你拨开迷雾，找到那条通往高效并发编程的光明大道。
东方睿赢
43 2
众所周知
|
3月前
|
开发框架 并行计算 算法
揭秘Python并发神器：IO密集型与CPU密集型任务的异步革命，你竟还傻傻分不清？
揭秘Python并发神器：IO密集型与CPU密集型任务的异步革命，你竟还傻傻分不清？
众所周知
47 4
土木林森
|
7月前
|
调度 数据库 Python
【专栏】异步IO在处理IO密集型任务中的高效性
【4月更文挑战第27天】本文介绍了Python并发编程和异步IO，包括并发的基本概念（多线程、多进程、协程），线程与进程的实现（threading和multiprocessing模块），协程的使用（asyncio模块），以及异步IO的原理和优势。强调了异步IO在处理IO密集型任务中的高效性，指出应根据任务类型选择合适的并发技术。
土木林森
162 2
龙大吉
|
3月前
|
算法 Java 程序员
解锁Python高效之道：并发与异步在IO与CPU密集型任务中的精准打击策略！
在数据驱动时代，高效处理大规模数据和高并发请求至关重要。Python凭借其优雅的语法和强大的库支持，成为开发者首选。本文将介绍Python中的并发与异步编程，涵盖并发与异步的基本概念、IO密集型任务的并发策略、CPU密集型任务的并发策略以及异步IO的应用。通过具体示例，展示如何使用`concurrent.futures`、`asyncio`和`multiprocessing`等库提升程序性能，帮助开发者构建高效、可扩展的应用程序。
龙大吉
127 0
东方睿赢
|
5月前
|
并行计算 数据处理 Python
Python并发编程迷雾：IO密集型为何偏爱异步？CPU密集型又该如何应对？
【7月更文挑战第17天】Python并发编程中，异步编程（如`asyncio`）在IO密集型任务中提高效率，利用等待时间执行其他任务。但对CPU密集型任务，由于GIL限制，多线程效率不高，此时应选用`multiprocessing`进行多进程并行计算以突破限制。选择合适的并发策略是关键：异步适合IO，多进程适合CPU。理解这些能帮助构建高效并发程序。
东方睿赢
125 6
龙大吉
|
5月前
|
算法 Java 程序员
解锁Python高效之道：并发与异步在IO与CPU密集型任务中的精准打击策略！
【7月更文挑战第17天】在数据驱动时代，Python凭借其优雅语法和强大库支持成为并发处理大规模数据的首选。并发与异步编程是关键，包括多线程、多进程和异步IO。对于IO密集型任务，如网络请求，可使用`concurrent.futures`和`asyncio`；CPU密集型任务则推荐多进程，如`multiprocessing`；`asyncio`适用于混合任务，实现等待IO时执行CPU任务。通过这些工具，开发者能有效优化资源，提升系统性能。
龙大吉
99 4
土木林森
|
5月前
|
开发框架 并行计算 .NET
从菜鸟到大神：Python并发编程深度剖析，IO与CPU的异步战争！
【7月更文挑战第18天】Python并发涉及多线程、多进程和异步IO（asyncio）。异步IO适合IO密集型任务，如并发HTTP请求，能避免等待提高效率。多进程在CPU密集型任务中更优，因可绕过GIL限制实现并行计算。通过正确选择并发策略，开发者能提升应用性能和响应速度。
土木林森
110 3
众所周知
|
5月前
|
开发框架 并行计算 算法
揭秘Python并发神器：IO密集型与CPU密集型任务的异步革命，你竟还傻傻分不清？
【7月更文挑战第18天】Python并发编程中，异步IO适合IO密集型任务，如异步HTTP请求，利用`asyncio`和`aiohttp`实现并发抓取，避免等待延迟。而对于CPU密集型任务，如并行计算斐波那契数列，多进程通过`multiprocessing`库能绕过GIL限制实现并行计算。选择正确的并发模型能显著提升性能。
众所周知
89 2
土木林森
|
5月前
|
开发框架 数据挖掘 .NET
显微镜下的Python并发：细说IO与CPU密集型任务的异步差异，助你精准施策！
【7月更文挑战第16天】在Python并发编程中，理解和区分IO密集型与CPU密集型任务至关重要。IO密集型任务（如网络请求）适合使用异步编程（如`asyncio`），以利用等待时间执行其他任务，提高效率。CPU密集型任务（如计算）则推荐使用多进程（如`multiprocessing`），绕过GIL限制，利用多核CPU。正确选择并发策略能优化应用性能。
土木林森
77 2
三分钟热度的鱼
|
5月前
|
SQL 关系型数据库 MySQL
实时计算 Flink版产品使用问题之在Flink算子内部使用异步IO可以通过什么办法实现
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架，广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器，提供了一套全面的解决方案，以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点，使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
三分钟热度的鱼
46 1