Pinned topic 'nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' too large for nmon_analyzer
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
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
Re: 'nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' too large for nmon_analyzer2006-05-05T08:31:31ZThis is the accepted answer. This is the accepted answer.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 100000MRSJ1718 Posts
How many is tons?2006-05-06T10:24:28ZThis is the accepted answer. This is the accepted answer.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.
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
Re: 'nmon_aix52 -F /tmp/mdt22024.050306.nmon -s 300 -c 288 -t' too large for nmon_analyzer2006-05-10T12:14:33ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK