I understand the load problems on a live session. Especially on large scale fabrics, where UFM server is already quite on a load.
But if i’m right with the new scheme of ufm 4.0 and the history feature, polling of the whole fabric is continuous. On my example, i have a schedule every 30 second, I’m not anymore running live session, and history database is on a second server (not on the UFM one).
The graphical display of history is important for me to have fast overview of congestion counters.
I’ll be happy to give you feedback if you have someone looking into it.
I think that this limit is an outcome of a limitation the product has with the live monitoring sessions.
With the live monitoring session, sampling too many ports at the same time consumes to many resources and can also pose heavier load on the fabric (every counter polling introduces traffic) - this is why the guys limited the amount of ports you can sample at the same time.
with the history feature, the behavior is the same but i am not sure about the amount of load. i can have somebody look into this.
i think that you can bypass this limitation by exporting the history data to a CSV file (you can export up to 1G of information) and then analyze as many ports as you’d like offline away from the UFM system .
Putting together the numbers: server=2 ports (for each HCA) so 20 servers runs 40 ports (potentially).
36 ports switch is under the 40 limitation so no issues with that part.
i guess, for your purpose, CSV will work but here is another advise (and sorry i am not being specific enough):
from my experience, if you use the history feature to investigate an event that took place in the past, you usually have some idea about which elements were involved with the issue. Try to narrow down your data analysis only to relevant ports (as much as possible). It will make your work more efficient too.