Topic
  • 4 replies
  • Latest Post - ‏2012-05-18T04:32:53Z by SystemAdmin
SystemAdmin
SystemAdmin
2402 Posts

Pinned topic 'nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' too large for nmon_analyzer

‏2006-05-04T22:31:46Z |
The UNIX SA's set '/usr/bin/nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' will provide with the -c 288 the number of data points for the day. When I put the raw file for 05/03 into the nmon analyzer, it tells me that the file is too large and to sort it. When I sorted it the nmon analyzer gave the message 'input past end of file'. There are worksheets created, but no graphs which of course is essential. This server has an immense ESS so there's tons of disk. Please advise. Thanks!
Updated on 2012-05-18T04:32:53Z at 2012-05-18T04:32:53Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    2402 Posts

    Re: 'nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' too large for nmon_analyzer

    ‏2006-05-05T08:31:31Z  
    send the zipped .nmon file to steve_atkins at uk.ibm.com and I'll look at it. Note that ESS configs with more than 253 vpaths can't be analysed and if this is your problem then you'll need to investigate the use of NMON diskgroups
  • nagger
    nagger
    1698 Posts

    How many is tons?

    ‏2006-05-06T10:24:28Z  
    This "lots of disks" is a common problem.

    Older ESS, or any of the large disk subsystems, that were setup a few years ago where the tendance was to have lots of small LUNs.
    Since then and with hind sight this is seen as a mistake.

    If you have hundreds of disks/LUNs then the disks are unmanagable
    1)if you can't monitor then all on one screen perhaps with X Windows say 100 disks then you can't management
    2) If they are unmanagable your can't expect nmon to manage them either!
    3) To make matters worse Excel has some build in really strange and low limitations when reading data files.
    4) This is made even worse when people make the mistake of having more than four paths to the disks can hence thousands of hdisks. Above four paths performance can drop off and recovery times from SAN errors can take minutes or hours.

    This is also wasting the power of these disk subsystems - why would you want to manage lots of disks yourself when you have purchased a disk subsystem to do this for you in hardware?

    I recommend 64 LUNs and four paths.
    I know changing this after the implimentation is extremely hard work but if you system is unmanagable and unmonitorable then you have to accept the risks of not knowing what the machine is doing.

    So:
    How many disks and vpaths have you got?
    How big is the output file?
    How many lines in the output file?

    I hope this helps, N
  • SystemAdmin
    SystemAdmin
    2402 Posts

    Re: 'nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' too large for nmon_analyzer

    ‏2006-05-10T12:14:33Z  
    send the zipped .nmon file to steve_atkins at uk.ibm.com and I'll look at it. Note that ESS configs with more than 253 vpaths can't be analysed and if this is your problem then you'll need to investigate the use of NMON diskgroups
    Larry, still waiting for the files - your email system has been garbling the data.
  • SystemAdmin
    SystemAdmin
    2402 Posts

    Re: 'nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' too large for nmon_analyzer

    ‏2012-05-18T04:32:53Z  
    双方的首发的士速递佛挡杀佛第三方身份梵蒂冈法国