VSP (non G version) CPU Usage?

i trying this tool.. Its so easy compared to the hitachi tool. But it looks like that there are some incorrect datas. 
As example CPU Usage at a VSP (NON G version). It IS every night up to 90%. 


  • Hi,

    pls send us this data (replace storage name by your one)
    Note a shor problem description in the upload form.

        cd /home/stor2rrd/stor2rrd
        tar cvf d.tar data/<storage name>/IOSTATS  tmp/<storage name>-*
        gzip -9 d.tar

  • I did not get an answer for my last dump. So i just start to calculate.
    If you take a HDS the most of the admins have a look at the "CPU". But you/this tool list CHA, MPB* and so on separate. Thats, at all, fine. BUT you make a simple adiddtion of all values and divided it to the count of procs. Thats a little wrong. I try and see aroudn 20% at all....but the CPU of the MPBs are realy important. You have to prioritize this over the rest. Thats my point of view and i now that a lot of admins habe a first look at the CPU of the MPBs, the other values are nice but not important. 

  • Hi,

    sorry, we had no time to look at data yet.
    I have no clue what are CHA,MPB and others, I see all of that for the first time.
    We expecting here CPU cores like on our demo and just averaging it:
    On demo are MPU, I thought it is some generic core prefix.

    if you need any change here than you have to explain us what is what and what and how would you expect to graph it. We are not Hitachi storage experts.

  • Hi,
    no problem. Im a free user and did not expect a 24/7 support ;)
    My point of view is that we should focus to MBP - if we did not get an MPU (on G*** systems). The storages like VSP/G1*** are reporting more than this (as you see in my screen). Im not sure how to solve that or how to give us (in a configfile) the possebilty to select what we want.  I like to help, but im not a coding guy :)

    ID that uniquely identifies the MP Blade (or
    MPU for Hitachi Unified Storage VM
    devices) to which the processor belongs
    within the storage system
  • our biggest problem is that we have no clue what are MPU, MBP etc, what is important and what is not.
    We could do what ever what make sense, we just need to know what it is :smile: 
  • OK, i have to read the manuals ;) But MPB are in the focus if you get problem with access times or write pending cache probleme. Guess the same are MPU, but we did not have so small systems. 
  • Make sense to create aggregared graphs for each type separately like MPU*, MBP* ... is that something you are looking for?
  • Hi,

    we have finally implemented it based on other forum thread:

    You can try it in this build, just upgrade to that:

Sign In or Register to comment.