Pacerier Absent Member.
Absent Member.
7203 views

Understanding "mmdrv.exe"

 

Can someone explain the high-level overview of what "mmdrv.exe" does along with its low-level workings?

 

Also, why does "mmdrv.exe" continue running even after we exit LoadRunner? Is this a "design" bug with LR?

============================================
0 Likes
11 Replies
Yoav_Agami Absent Member.
Absent Member.

Re: Understanding "mmdrv.exe"

The mmdrv is the process that emulates the virtual users. It is loaded by the Controller and not by VuGen. After the scenario finishes, the process will terminate.

Regards,

Yoav

0 Likes
Pacerier Absent Member.
Absent Member.

Re: Understanding "mmdrv.exe"

However, I have already completely exitted the Controller.

 

Why is mmdrv still running?

 

Is this a bug?

============================================
0 Likes
Yoav_Agami Absent Member.
Absent Member.

Re: Understanding "mmdrv.exe"

If working locally (Controller loading on localhost), then after the scenario finishes, mmdrv.exe should terminate.

 

0 Likes
Respected Contributor.. KajFeis Respected Contributor..
Respected Contributor..

Re: Understanding "mmdrv.exe"

It should terminate...but in my experience(LR11.52) that doesn't always happen. So I always make sure to kill the  mmdrv processes mannualy also after closing te Controller, or when I restart it. Just in case. I think it has someting to do with some subtle nuances regarding user rights on the machines you use.

0 Likes
Absent Member.. ssawale Absent Member..
Absent Member..

Re: Understanding "mmdrv.exe"

When running the Vuser as a process, LR will create 1 process per Vuser. So if you have 10 Vusers, you will have 10 mdrv.exe processes on your box.
When running the Vuser as a thread, it creates 1 thread per Vuser. So if you have 10 Vusers, then you will have 1 process with 10 threads running inside it if the process limit is 10 threads per process else you might see multiple process based on number of threads per process limit.
For a process:
program counter - identifying next instruction to execute.
processors register set - contains register values.
text segment - contains code section.
data segment - contains variable content.
stack segment - contains temporary data such as subroutine parameters, return addresses, temporary variables
For a thread:
The text segment and the data segment are being shared by multiple threads within parent process. Each thread will have its own allocation for the rest of the module.
That is why you will be able to run more Vusers as threads than as processes since less memory resources are being taken. And context switching is faster for threads than processes.
 
By default, most of LR Vuser's is set to run as a threads unless they are not thread safe. There is, however, a trade off on running vuser as a thread. The more threads in a process, the more unstable the system becomes.
 
Some users which requires complex authentication and elevation for process to access GDI resources also won't run successfully as threads one example is QTP/UFT based GUI scripts.
 
I hope this helps!
 
Tnx!
 
 
Pacerier Absent Member.
Absent Member.

Re: Understanding "mmdrv.exe"


@ssawale wrote:
By default, most of LR Vuser's is set to run as a threads unless they are not thread safe. There is, however, a trade off on running vuser as a thread. The more threads in a process, the more unstable the system becomes.

Why will having more threads make LR less unstable?

 

Is this a code design issue? What's the maximum number of threads LR is designed for?

 

Also, regarding efficiency (as opposed to memory concerns), which would be more performant?

============================================
0 Likes
Dennis Handly Acclaimed Contributor.
Acclaimed Contributor.

Re: Understanding "mmdrv.exe"

>Why will having more threads make LR less unstable?

 

I suppose this comment is about the fact that there must be increased locking to protect the shared resources.

 

> regarding efficiency (as opposed to memory concerns), which would be more performant?

 

These are related when you have a massive number of threads/processes.  If you use too much memory, you start paging.

Pacerier Absent Member.
Absent Member.

Re: Understanding "mmdrv.exe"


Dennis Handly wrote: 
These are related when you have a massive number of threads/processes. If you use too much memory, you start paging.

I've replied to this at http://h30499.www3.hp.com/t5/LoadRunner-Support-Forum/The-goal-is-to-maximize-speed-concurrency-of-Vuser-scripts/m-p/6693219#M11633 , will be keeping this thread free for "mmdrv.exe" posts.

============================================
0 Likes
Absent Member.. ssawale Absent Member..
Absent Member..

Re: Understanding "mmdrv.exe"

Need to look little deeper inside the layers like user mode and kernel mode working of each process, resource allocations and how they operate. Its not a straight answer but to understand at upper level reason for unstability is reduction in per thread stack size with larger number of threads per process which would result in stack-overflows that causes system to be more unpredictable and hence unstable.

 

I hope this helps a bit!

 

Tnx!

0 Likes
Highlighted
Pacerier Absent Member.
Absent Member.

Re: Understanding "mmdrv.exe"


ssawale wrote:

... to understand at upper level reason for unstability is reduction in per thread stack size with larger number of threads per process which would result in ...


Isn't per thread stack size fixed regardless of how many we have per process? Which means if its 2 MB per thread and we have 100 threads, it would be 200 MB isn't it?

 

Why would having more threads affect the per thread stack size?

============================================
0 Likes
Absent Member.. ssawale Absent Member..
Absent Member..

Re: Understanding "mmdrv.exe"

I think you can a take deep look at these articles which will help you to go down the stack on limits, how they are set , how problem starts cropping up etc.

 

http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx 

 

http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx 

 

 

Good luck!

 

Tnx!

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.