开始新对话

此帖子已超过 5 年

Solved!

Go to Solution

4547

2014年5月29日 02:00

Windows MPIO是哪个服务host的?

Hi,

我想trace MPIO,但没找到对应的进程,EMC有什么Windows主机文档可以参考下不?

1.6K 消息

2014年5月29日 23:00

http://technet.microsoft.com/en-us/library/ee619724(v=ws.10).aspx

这个有帮助不?不过log据说是二进制文件,必须找微软售后才能看...

2.1K 消息

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的。哪里找这本书的话,你懂的。

1.8K 消息

2014年5月29日 18:00

超哥,您应该强烈建议用PP。

Community Manager

 • 

6.1K 消息

2014年5月30日 00:00

可不是呢~ 如Born所说,你得宣传Powerpath,然后来讨论Powerpath的问题。。

1.4K 消息

2014年5月30日 02:00

思路是对的,不过拿下来如果打不开的话也没用了,不过为我打开了方向。

1.4K 消息

2014年5月30日 02:00

太复杂,不懂啊

1.4K 消息

2014年5月30日 02:00

xperf应该有办法trace它的call stack,再研究下。

2.1K 消息

2014年5月30日 02:00

遇到了什么问题?怀疑是MPIO导致性能问题?

1.6K 消息

2014年6月3日 07:00

你可否trace网络包啊,看看hang的时候有发送什么包不,这样也许也可以得到些线索

1.4K 消息

2014年6月3日 07:00

  • 一台Win2008R2,一台双控存储,一条路径到A控,一条路径到B控
  • iSCSI连接
  • Microsoft iSCSI Initiator
  • 用Windows explorer做拷贝,拷贝到一时断掉其中一条路
  • Explorer可以hang 2~5mins,然后explorer恢复把并继续刚才的拷贝

目前的concern就是为什么explorer会hang这么久,从存储端来看,delay并不在存储,而是在Windows上,所以我想trace MPIO、iSCSI initiator、Explorer来看delay的位置。

1.6K 消息

2014年6月3日 23:00

有msdn的话,下载个windbg,还有OS的symbol,用windbg挂到explorer进程上,hang时取个dump下来看看call stack。也有可能是在等待某个timeout的signal,不是一定要有网络流量的。这个你得去微软开发论坛问问了

1.4K 消息

2014年6月3日 23:00

network trace是最先想到的,但因为条件限制,没法抓。而且在hang的时候,任务管理器的网络tab,没有任何流量,所以感觉还是thread level delay。

还有一点很奇怪,Explorer居然能hang那么久(2~5mins),我在自己试验机上测试,不到1分钟如果copy没响应的话,Explorer就直接报错退出了。

1.4K 消息

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不一样(由下往上显示)

460882.jpg

1.4K 消息

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

1.6K 消息

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