Hi. The Primus case pertains to a cluster or a non-cluster host. Without a case being opened with CS, no definitive answer can really be given now. The recommendation is to upgrade to PP 5.3 which contains the 1.23 MPIO driver. There are different builds for the x64 architectures with this release. You can find the appropriate build on Powerlink. Good luck.
Really appreciate any more input on this as it's Friday tomorrow and if nothing else it would be good to know what the definitive fix is for this issue *if* it may be MPIO that's doing it.
Thanks Brion, I hadn't opened a case as I assumed (maybe incorrectly) that Powerpath wouldn't be supported in such a broad sense via technical.
It sounds like their first suggestion will be to move to 5.3 anyway, so if the server does its trick I think that will have to be "Plan A" and at least that's the thing covered that is known to have issues.
Brion is correct in that the article refers to memory leaks in both clustered and non clustered hosts.
The situation is a little more complex than the ETA specifies.
Basically the code that produces the memory leak specified in MPIO 1.22 is actually present in MPIO 1.21 - however at the time I wrote the ETA only clustered hosts had seen the issue in MPIO 1.21 and both clustered and non-clustered had seen the memory leak in 1.22
The memory leak is very specific to the non-paged memory pool and can normally be tracked using poolmon.
The recommendation is to not use MPIO 1.21 or 1.22 - i.e. use MPIO 1.23 shipped with PowerPath 5.3 or 5.3 SP1.
You can of course use the utility to update the MPIO component only - however there are other changes in PowerPath 5.3 that mak it a better fit than 5.2 with MPIO 1.21/2
Please note that PowerPath 5.2 and 5.2 SP1 have been removed from availability in Powerlink
If you upgrade to PowerPath 5.3/5.3 SP1 and you still experience the issue you are describing then it is more than likely due to some other cause (the descriprion is vague - however it seems to be describing a slightly different behaviour than I have seen). If this is the case then an EMCReports output along with a memory dump (kernel at a minimum) would be required to identify the issue.
Paul_Hutchings
18 Posts
0
July 15th, 2009 07:00
I did read that but we're not running any sort of cluster, just a standalone server (dual Emulex LPe1150's).
Also there's no indication of paged/non-paged or any memory counter in Task Manager "slowly" incrementing/decrementing - it seems to go very suddenly.
Message was edited by:
Hutchingsp
Brion2
154 Posts
0
July 16th, 2009 06:00
Paul_Hutchings
18 Posts
0
July 16th, 2009 06:00
Powerpath 5.3 vs. downgrade MPIO for example?
Paul_Hutchings
18 Posts
0
July 16th, 2009 08:00
It sounds like their first suggestion will be to move to 5.3 anyway, so if the server does its trick I think that will have to be "Plan A" and at least that's the thing covered that is known to have issues.
I'm still working on Plan B
SamCl
54 Posts
0
July 28th, 2010 23:00
Brion is correct in that the article refers to memory leaks in both clustered and non clustered hosts.
The situation is a little more complex than the ETA specifies.
Basically the code that produces the memory leak specified in MPIO 1.22 is actually present in MPIO 1.21 - however at the time I wrote the ETA only clustered hosts had seen the issue in MPIO 1.21 and both clustered and non-clustered had seen the memory leak in 1.22
The memory leak is very specific to the non-paged memory pool and can normally be tracked using poolmon.
The recommendation is to not use MPIO 1.21 or 1.22 - i.e. use MPIO 1.23 shipped with PowerPath 5.3 or 5.3 SP1.
You can of course use the utility to update the MPIO component only - however there are other changes in PowerPath 5.3 that mak it a better fit than 5.2 with MPIO 1.21/2
Please note that PowerPath 5.2 and 5.2 SP1 have been removed from availability in Powerlink
If you upgrade to PowerPath 5.3/5.3 SP1 and you still experience the issue you are describing then it is more than likely due to some other cause (the descriprion is vague - however it seems to be describing a slightly different behaviour than I have seen). If this is the case then an EMCReports output along with a memory dump (kernel at a minimum) would be required to identify the issue.