浏览
帮助
登录
此帖子已超过 5 年
Solved!
zhouzengchao
1.4K 消息
0
4547
2014年5月29日 02:00
Hi,
我想trace MPIO,但没找到对应的进程,EMC有什么Windows主机文档可以参考下不?
回复(17)
Yanhong1
1.6K 消息
2014年5月29日 23:00
http://technet.microsoft.com/en-us/library/ee619724(v=ws.10).aspx
这个有帮助不?不过log据说是二进制文件,必须找微软售后才能看...
Fenglin1
2.1K 消息
2
Windows的Multipath I/O (MPIO) Drivers应该是Kernel的,Build在Msdsm.sys这个Driver里面,工具的话用diskmon可以看一些,更多的东西要看dump了。
Windows Internals Part 2_6th Edition有专门一个小的章节讲MPIO的Stack的。哪里找这本书的话,你懂的。
born_chen
1.8K 消息
2014年5月29日 18:00
超哥,您应该强烈建议用PP。
DELL-Leo
Community Manager
•
6.1K 消息
2014年5月30日 00:00
可不是呢~ 如Born所说,你得宣传Powerpath,然后来讨论Powerpath的问题。。
2014年5月30日 02:00
思路是对的,不过拿下来如果打不开的话也没用了,不过为我打开了方向。
太复杂,不懂啊
xperf应该有办法trace它的call stack,再研究下。
遇到了什么问题?怀疑是MPIO导致性能问题?
2014年6月3日 07:00
你可否trace网络包啊,看看hang的时候有发送什么包不,这样也许也可以得到些线索
目前的concern就是为什么explorer会hang这么久,从存储端来看,delay并不在存储,而是在Windows上,所以我想trace MPIO、iSCSI initiator、Explorer来看delay的位置。
2014年6月3日 23:00
有msdn的话,下载个windbg,还有OS的symbol,用windbg挂到explorer进程上,hang时取个dump下来看看call stack。也有可能是在等待某个timeout的signal,不是一定要有网络流量的。这个你得去微软开发论坛问问了
network trace是最先想到的,但因为条件限制,没法抓。而且在hang的时候,任务管理器的网络tab,没有任何流量,所以感觉还是thread level delay。
还有一点很奇怪,Explorer居然能hang那么久(2~5mins),我在自己试验机上测试,不到1分钟如果copy没响应的话,Explorer就直接报错退出了。
2014年6月4日 18:00
说到call stack,Yanhong Huang,这里要你帮忙教授下怎么看了。下面是我抓的一个stack trace,我想知道某个函数的具体描述,比如函数的作用,参数类型,参数个数等。我觉得MSDN上应该能查到,但试了好几个函数名都没找到,比如ntdll.dll模块的RtUserThreadStart(),user32.dll模块的LoadRemoteFonts()函数。
你知道如何找到这些函数的描述不?还是说我查的这些都是non-public的?看上应该是些Win32 API system function call。
note: xperf trace的call stack是从上往下显示next call的,和windbug不一样(由下往上显示)
windbg单独下载现在已经被取消了,必须下载WinSDK,windbg都包含在里面了。Windbg取process dump以前没做过,有时间去研究下。不过我现在用的Xperf已经能够trace到call stack,待会去看看explorer的call stack,它居然能hang 2~5mins还不crash得确也蛮神奇的。
explorer进程hang多半是在waiting for something,可能是他的UI thread running under sync mode (not async),因为当时路径切换还没完成,所以从逻辑上来说,root cause还是路径切换的delay,所以我才想去trace MPIO。
想到要network trace是因为想看看host/mpio有没有在路径断开后向存储发起一些比如转移LUN owership to peer controller的Msg,但和这个delay没有直接关系(因为ALUA,这个就不细说了)。
测完我再来update
2014年6月4日 20:00
当然有很多函数是undocument的了,一般外面的人是看不到的。以前我们都是在内部查source code的网站直接查找这个函数的源代码的,不过费时费力,没事也不去看。
你的这个工具我不熟悉,windbg里面可以看一些函数的参数的。取决于你有这个函数的symbol。你看这篇:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539042(v=vs.85).aspx
戴尔支持资源
查看更多
查看全部
Top
Yanhong1
1.6K 消息
0
2014年5月29日 23:00
http://technet.microsoft.com/en-us/library/ee619724(v=ws.10).aspx
这个有帮助不?不过log据说是二进制文件,必须找微软售后才能看...
Fenglin1
2.1K 消息
2
2014年5月29日 02:00
Windows的Multipath I/O (MPIO) Drivers应该是Kernel的,Build在Msdsm.sys这个Driver里面,工具的话用diskmon可以看一些,更多的东西要看dump了。
Windows Internals Part 2_6th Edition有专门一个小的章节讲MPIO的Stack的。哪里找这本书的话,你懂的。
born_chen
1.8K 消息
0
2014年5月29日 18:00
超哥,您应该强烈建议用PP。
DELL-Leo
Community Manager
Community Manager
•
6.1K 消息
0
2014年5月30日 00:00
可不是呢~ 如Born所说,你得宣传Powerpath,然后来讨论Powerpath的问题。。
zhouzengchao
1.4K 消息
0
2014年5月30日 02:00
思路是对的,不过拿下来如果打不开的话也没用了,不过为我打开了方向。
zhouzengchao
1.4K 消息
0
2014年5月30日 02:00
太复杂,不懂啊
zhouzengchao
1.4K 消息
0
2014年5月30日 02:00
xperf应该有办法trace它的call stack,再研究下。
Fenglin1
2.1K 消息
0
2014年5月30日 02:00
遇到了什么问题?怀疑是MPIO导致性能问题?
Yanhong1
1.6K 消息
0
2014年6月3日 07:00
你可否trace网络包啊,看看hang的时候有发送什么包不,这样也许也可以得到些线索
zhouzengchao
1.4K 消息
0
2014年6月3日 07:00
目前的concern就是为什么explorer会hang这么久,从存储端来看,delay并不在存储,而是在Windows上,所以我想trace MPIO、iSCSI initiator、Explorer来看delay的位置。
Yanhong1
1.6K 消息
0
2014年6月3日 23:00
有msdn的话,下载个windbg,还有OS的symbol,用windbg挂到explorer进程上,hang时取个dump下来看看call stack。也有可能是在等待某个timeout的signal,不是一定要有网络流量的。这个你得去微软开发论坛问问了
zhouzengchao
1.4K 消息
0
2014年6月3日 23:00
network trace是最先想到的,但因为条件限制,没法抓。而且在hang的时候,任务管理器的网络tab,没有任何流量,所以感觉还是thread level delay。
还有一点很奇怪,Explorer居然能hang那么久(2~5mins),我在自己试验机上测试,不到1分钟如果copy没响应的话,Explorer就直接报错退出了。
zhouzengchao
1.4K 消息
0
2014年6月4日 18:00
说到call stack,Yanhong Huang,这里要你帮忙教授下怎么看了。下面是我抓的一个stack trace,我想知道某个函数的具体描述,比如函数的作用,参数类型,参数个数等。我觉得MSDN上应该能查到,但试了好几个函数名都没找到,比如ntdll.dll模块的RtUserThreadStart(),user32.dll模块的LoadRemoteFonts()函数。
你知道如何找到这些函数的描述不?还是说我查的这些都是non-public的?看上应该是些Win32 API system function call。
note: xperf trace的call stack是从上往下显示next call的,和windbug不一样(由下往上显示)
zhouzengchao
1.4K 消息
0
2014年6月4日 18:00
windbg单独下载现在已经被取消了,必须下载WinSDK,windbg都包含在里面了。Windbg取process dump以前没做过,有时间去研究下。不过我现在用的Xperf已经能够trace到call stack,待会去看看explorer的call stack,它居然能hang 2~5mins还不crash得确也蛮神奇的。
explorer进程hang多半是在waiting for something,可能是他的UI thread running under sync mode (not async),因为当时路径切换还没完成,所以从逻辑上来说,root cause还是路径切换的delay,所以我才想去trace MPIO。
想到要network trace是因为想看看host/mpio有没有在路径断开后向存储发起一些比如转移LUN owership to peer controller的Msg,但和这个delay没有直接关系(因为ALUA,这个就不细说了)。
测完我再来update
Yanhong1
1.6K 消息
0
2014年6月4日 20:00
当然有很多函数是undocument的了,一般外面的人是看不到的。以前我们都是在内部查source code的网站直接查找这个函数的源代码的,不过费时费力,没事也不去看。
你的这个工具我不熟悉,windbg里面可以看一些函数的参数的。取决于你有这个函数的symbol。你看这篇:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539042(v=vs.85).aspx