DISCLAIMER : Please note that blog owner takes no responsibility of any kind for any type of data loss or damage by trying any of the command/method mentioned in this blog. You may use the commands/method/scripts on your own responsibility.If you find something useful, a comment would be appreciated to let other viewers also know that the solution/method work(ed) for you.
This perfpmr package contains a number of performance tools and some instructions. Some of these tools are products available with AIX. Some of the tools are prototype internal tools (setpri, setsched, iomon, getevars, pmcount, lsc, fcstat2, memfill, getdate, perfstat_trigger) and are not generally available to customers.
All results generated by the Program are estimates and averages based on certain assumptions and conditions. Each environment has its own unique set of requirements that no tool can entirely account for. No representation is made that the results will be accurate or achieved in any given IBM installation environment. The result is based on specific configurations and run time environments. Customer results will vary. Any configuration recommended by the Program should be tested and verified. Any code provided is for illustrative purposes only.
This package contains a set of tools and instructions for collecting the data needed to analyze a AIX performance problem. This tool set runs on AIX V7.1
A. Purpose:
1. This section describes the set of steps that should be followed to collect performance data.
2. The goal is to collect a good base of information that can be used by AIX technical support specialists or development lab programmers to get started in analyzing and solving the performance problem. This process may need to be repeated after analysis of the initial set of data is completed and/or AIX personnel may want to dial-in to the customer's machine if appropriate for additional data collection/analysis.
B. Collection of the Performance Data on Your System
1. Detailed System Performance Data:
Detailed performance data is required to analyze and solve a performance problem. Follow these steps to invoke the supplied shell scripts:
NOTE: You must have root user authority when executing these shell scripts.
a. Create a data collection directory and 'cd' into this directory.
Allow at least 45MB*#of_logicalcpus of unused space in whatever file system is used.
*IMPORTANT* - DO NOT COLLECT DATA IN A REMOTELY MOUNTED FILESYSTEM SINCE IPTRACE MAY HANG
For example using /tmp filesystem:
# mkdir /tmp/perfdata
# cd /tmp/perfdata
b. HACMP users:
Generaly recommend HACMP deadman switch interval be lengthened while performance data is being collected.
c. Collect our 'standard' PERF71 data for 600 seconds (600 seconds = 10 minutes). Start the data collection while the problem is already occurring with the command:
/directory_where_perfpmrscripts_are_installed/perfpmr.sh 600
The perfpmr.sh shell provided will:
- immediately collect a 5 second trace (trace.sh 5)
- collect 600 seconds of general system performance data (monitor.sh 600).
- collect hardware and software configuration information (config.sh).
In addition, if it finds the following programs available in the current execution path, it will:
- collect 10 seconds of iptrace information (iptrace.sh 10)
- collect 10 seconds of filemon information (filemon.sh 10)
- collect 60 seconds of tprof information (tprof.sh 60)
NOTE: Since a performance problems may mask other problems, it is not uncommon to fix one issue and then collect more data to work on another issue.
d. Answer the questions in the text file called 'PROBLEM.INFO' in the data collection directory created above. This background information about your problem helps us better understand what is going wrong.
A. Combine all the collected data into a single binary 'tar' file and compress it:
Put the completed PROBLEM.INFO in the same directory where the data was collected (ie. /tmp/perfdata in the following example). Change to the parent directory, and use the tar command as follows:
Either use: cd /tmp; perfpmr.sh -o perfdata -z pmr#.pax.gz
or
# cd /tmp/perfdata (or whatever directory used
to collect the data)
# cd ..
# pax -xpax -vw perfdata | gzip -c > pmr#.pax.gz
B. Submission of testcase to IBM:
Internet 'ftp' access:
----------------------
The quickest method to get the data analyzed is for the customer to ftp the data directly to IBM. Data placed on the server listed below cannot be accessed by unauthorized personnel. Please contact your IBM representative for the PMR#, BRANCH#, and COUNTRY#. IBM uses all 3 to uniquely associate your data with your problem tracking record.
'ftp testcase.software.ibm.com'
Userid: anonymous
password: your_internet_email_address
(ie. smith@austin.ibm.com)
'cd toibm/aix'
'bin'
'put PMR#.BRANCH#.COUNTRY#.pax.gz'
(ie. '16443.060.000.pax.gz'
'quit'
If the transfer fails with an error, it's possible that a file already exists by the same name on the ftp server. In this case, add something to the name of the file to differentiate it from the file already on the ftp site (ex. 16443.060.000.july18.pax.gz).
Notify your IBM customer representative you have submitted the data. They will then update the defect report to indicate the data is available for analysis.
All results generated by the Program are estimates and averages based on certain assumptions and conditions. Each environment has its own unique set of requirements that no tool can entirely account for. No representation is made that the results will be accurate or achieved in any given IBM installation environment. The result is based on specific configurations and run time environments. Customer results will vary. Any configuration recommended by the Program should be tested and verified. Any code provided is for illustrative purposes only.
AIX 7.1 PERFORMANCE DATA COLLECTION PROCESS
Note: The act of collecting performance data will add load on the system. HACMP users may want to extend the Dead Man Switch timeout or shutdown HACMP prior to collecting perfpmr data to avoid accidental failovers.
I. INTRODUCTION
This package contains a set of tools and instructions for collecting the data needed to analyze a AIX performance problem. This tool set runs on AIX V7.1
II. HOW TO OBTAIN AND INSTALL THE TOOLS ON AN IBM RISC SYSTEM/6000.
A. OBTAINING THE PACKAGE
The package will be distributed as a compressed "tar" file available electronically.
From the internet:
==================
'ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr'
B. INSTALLING THE PACKAGE
The following assumes the tar file is in /tmp and named 'perf71.tar.Z'.
a. login as root or use the 'su' command to obtain root authority
b. create perf71 directory and move to that directory (this example assumes the directory built is under /tmp)
# mkdir /tmp/perf71
# cd /tmp/perf71
c. extract the shell scripts out of the compressed tar file:
# zcat /tmp/perf71.tar.Z | tar -xvf -
The package will be distributed as a compressed "tar" file available electronically.
From the internet:
==================
'ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr'
B. INSTALLING THE PACKAGE
The following assumes the tar file is in /tmp and named 'perf71.tar.Z'.
a. login as root or use the 'su' command to obtain root authority
b. create perf71 directory and move to that directory (this example assumes the directory built is under /tmp)
# mkdir /tmp/perf71
# cd /tmp/perf71
c. extract the shell scripts out of the compressed tar file:
# zcat /tmp/perf71.tar.Z | tar -xvf -
III. HOW TO COLLECT DATA FOR AN AIX PERFORMANCE PROBLEM
A. Purpose:
1. This section describes the set of steps that should be followed to collect performance data.
2. The goal is to collect a good base of information that can be used by AIX technical support specialists or development lab programmers to get started in analyzing and solving the performance problem. This process may need to be repeated after analysis of the initial set of data is completed and/or AIX personnel may want to dial-in to the customer's machine if appropriate for additional data collection/analysis.
B. Collection of the Performance Data on Your System
1. Detailed System Performance Data:
Detailed performance data is required to analyze and solve a performance problem. Follow these steps to invoke the supplied shell scripts:
NOTE: You must have root user authority when executing these shell scripts.
a. Create a data collection directory and 'cd' into this directory.
Allow at least 45MB*#of_logicalcpus of unused space in whatever file system is used.
*IMPORTANT* - DO NOT COLLECT DATA IN A REMOTELY MOUNTED FILESYSTEM SINCE IPTRACE MAY HANG
For example using /tmp filesystem:
# mkdir /tmp/perfdata
# cd /tmp/perfdata
b. HACMP users:
Generaly recommend HACMP deadman switch interval be lengthened while performance data is being collected.
c. Collect our 'standard' PERF71 data for 600 seconds (600 seconds = 10 minutes). Start the data collection while the problem is already occurring with the command:
/directory_where_perfpmrscripts_are_installed/perfpmr.sh 600
The perfpmr.sh shell provided will:
- immediately collect a 5 second trace (trace.sh 5)
- collect 600 seconds of general system performance data (monitor.sh 600).
- collect hardware and software configuration information (config.sh).
In addition, if it finds the following programs available in the current execution path, it will:
- collect 10 seconds of iptrace information (iptrace.sh 10)
- collect 10 seconds of filemon information (filemon.sh 10)
- collect 60 seconds of tprof information (tprof.sh 60)
NOTE: Since a performance problems may mask other problems, it is not uncommon to fix one issue and then collect more data to work on another issue.
d. Answer the questions in the text file called 'PROBLEM.INFO' in the data collection directory created above. This background information about your problem helps us better understand what is going wrong.
IV. HOW TO SEND THE DATA TO IBM.
A. Combine all the collected data into a single binary 'tar' file and compress it:
Put the completed PROBLEM.INFO in the same directory where the data was collected (ie. /tmp/perfdata in the following example). Change to the parent directory, and use the tar command as follows:
Either use: cd /tmp; perfpmr.sh -o perfdata -z pmr#.pax.gz
or
# cd /tmp/perfdata (or whatever directory used
to collect the data)
# cd ..
# pax -xpax -vw perfdata | gzip -c > pmr#.pax.gz
B. Submission of testcase to IBM:
Internet 'ftp' access:
----------------------
The quickest method to get the data analyzed is for the customer to ftp the data directly to IBM. Data placed on the server listed below cannot be accessed by unauthorized personnel. Please contact your IBM representative for the PMR#, BRANCH#, and COUNTRY#. IBM uses all 3 to uniquely associate your data with your problem tracking record.
'ftp testcase.software.ibm.com'
Userid: anonymous
password: your_internet_email_address
(ie. smith@austin.ibm.com)
'cd toibm/aix'
'bin'
'put PMR#.BRANCH#.COUNTRY#.pax.gz'
(ie. '16443.060.000.pax.gz'
'quit'
If the transfer fails with an error, it's possible that a file already exists by the same name on the ftp server. In this case, add something to the name of the file to differentiate it from the file already on the ftp site (ex. 16443.060.000.july18.pax.gz).
Notify your IBM customer representative you have submitted the data. They will then update the defect report to indicate the data is available for analysis.
Cloning a rootvg using alternate disk installation
Using this scenario, you can clone AIX® running on rootvg to an alternate disk on the same system, install a user-defined software bundle, and run a user-defined script to customize the AIX image on the alternate disk.
The information in
this how-to scenario was tested using specific versions of AIX. The
results you obtain might vary significantly depending on your version
and level of AIX.
Because
the alternate disk installation process
involves cloning an existing rootvg to a
target alternate disk, the target alternate disk must not be already
assigned to a volume group.
In this scenario you will do the following:
- Prepare for the alternate disk installation
- Perform the alternate disk installation and customization
- Boot off the alternate disk
- Verify the operation
Step 1. Prepare for the alternate disk installation
- Check the status of physical disks on your system. Type:
Output similar to the following displays:# lspv
We can use hdisk1 as our alternate disk because no volume group is assigned to this physical disk.hdisk0 0009710fa9c79877 rootvg active hdisk1 0009710f0b90db93 None
- Check to see if the alt_disk_copy fileset
has been installed by running the following:
Output similar to the following displays if the alt_disk_copy fileset is not installed:# lslpp -L bos.alt_disk_install.rte
lslpp: 0504-132 Fileset bos.alt_disk_install.rte not installed.
- Using volume 1 of the AIX installation
media, install the alt_disk_copy fileset
by running the following:
Output similar to the following displays:# geninstall -d/dev/cd0 bos.alt_disk_install.rte
+-----------------------------------------------------------------------------+ Summaries: +-----------------------------------------------------------------------------+ Installation Summary -------------------- Name Level Part Event Result ------------------------------------------------------------------------------- bos.alt_disk_install.rte 5.3.0.0 USR APPLY SUCCESS
- Create a user-defined bundle called /usr/sys/inst.data/user_bundles/MyBundle.bnd that
contains the following filesets:
I:bos.content_list I:bos.games
- Create the /home/scripts directory:
mkdir /home/scripts
- Create a user-defined customization script called AddUsers.sh in
the /home/scripts directory:
touch /home/scripts/AddUsers.sh chmod 755 /home/scripts/AddUsers.sh
- Edit /home/scripts/AddUsers.sh to contain
the following lines:
mkuser johndoe touch /home/johndoe/abc.txt touch /home/johndoe/xyz.txt
Step 2. Perform the alternate disk installation and customization
- To clone the rootvg to an alternate
disk, type the following at the command line to open the SMIT menu
:
# smit alt_clone
- Select hdisk1 in the Target Disk to Install field.
- Select the MyBundle bundle in the Bundle to Install field.
- Insert volume one of the installation media.
- Type /dev/cd0 in the Directory or Device with images field.
- Type /home/scripts/AddUsers.sh in the Customization script field.
- Press Enter to start the alternate disk installation.
- Check that the alternate disk was created, by running the following:
# lspv
Output similar to the following displays:
hdisk0 0009710fa9c79877 rootvg hdisk1 0009710f0b90db93 altinst_rootvg
Step 3. Boot from the alternate disk
- By default, the alternate-disk-installation process changes the
boot list to the alternate disk. To check this run the following:
Output similar to the following displays:# bootlist -m normal -o
hdisk1
- Reboot the system. Type:
# shutdown -r
The system boots from the boot image on the alternate disk (hdisk1).
Step 4. Verify the operation
- When the system reboots, it will be running off the alternate
disk. To check this, type the following:
Output similar to the following displays:# lspv
hdisk0 0009710fa9c79877 old_rootvg hdisk1 0009710f0b90db93 rootvg
- Verify that the customization script ran correctly, by typing
the following:
Output similar to the following displays:# find /home/johndoe -print
/home/johndoe /home/johndoe/.profile /home/johndoe/abc.txt /home/johndoe/xyz.txt
- Verify that the contents of your software bundle was installed,
by typing the following:
Output similar to the following displays:# lslpp -Lb MyBundle
Fileset Level State Description ---------------------------------------------------------------------------- bos.content_list 5.3.0.0 C AIX Release Content List bos.games 5.3.0.0 C Games
alt_disk in AIX
alt_disk_copy:
Required filesets:
bos.alt_disk_install.boot_images
bos.alt_disk_install.rte
bos.msg.en_US.alt_disk_install.rte
alt_disk_copy -d <hdisk to clone rootvg> this will clone the rootvg to the specified disk
alt_disk_copy -e /etc/exclude.rootvg -d <hdisk> this will use the exclude list during the cloning
alt_disk_copy -T -d <hdisk> it will convert jfs to jfs2 on the new target disk (from 6.1 TL4 only)
alt_rootvg_op -X <cloned rootvg to destroy> this will destroy the cloned rootvg (alt_rootvg_op -X altinst_rootvg)
alt_rootvg_op -W -d <hdisk> this will wake up a disk (cloned filesystems will be mounted with prefix /alt_)
alt_rootvg_op -S -t <hdisk> this will put cloned rootvg to sleep (before that it will do a bosboot)
(-S: put to sleep earlier "waked up" vg, -t: rebuilds the alt. bootimage before sleep)
alt_rootvg_op -v <new cloned rootvg name> -d <hdisk> this will rename the given cloned rootvg name
(after wake-up and sleep the cloned vg name will be changed, in this case it is useful)
alt_disk_mksysb -m /mnt/aix1mksysb -d hdisk1 -k this will resore given mksysb (aix1mksysb) to hdisk1 (-k: keep device configuration)
/var/adm/ras/alt_disk_inst.log alt_disk log file
----------------------------------
alt_disk_copy: (copy hdisk0 to hdsik1)
lv names can't be longer than 11 characters (because of alt_ prefix)
do not take out that disk which was used during boot (otherwise there will be problems with bosboot)
-unmirrorvg rootvg hdisk1
-reducevg rootvg hdisk1
-bosboot -ad hdisk0
-bootlist -m normal hdisk0
-alt_disk_copy -d hdisk1
-bootlist -m normal hdisk0
after booting from hdisk1:
root@aix11: / # lspv
hdisk0 00cf5d8fe9c88a34 old_rootvg
hdisk1 00cf5d8fadcaa9a9 rootvg active
booting from the old disk:
root@aix11: / # lspv
hdisk0 00cf5d8fe9c88a34 rootvg active
hdisk1 00cf5d8fadcaa9a9 altinst_rootvg
removing the new image (keeping the old one):
-alt_rootvg_op -X altinst_rootvg <--removing the new image from hdisk1
-chpv -c hdisk1 <--clear that pv what contained the removed image
-extendvg -f rootvg hdisk1 <--extend the currently used rootvg with the cleared disk (hdisk1)
-mirrorvg -S rootvg hdisk1 <--mirroring rootvg to hdisk1 (checking: lsvg rootvg | grep STALE)(-S: -background sync)
-bosboot -ad hdisk0; bosboot -ad hdisk1 <--recreate the bootimage
-bootlist -m normal hdisk0 hdisk1 <--setup correct bootlist (checking: bootlist -m normal -o)
------------------------------------
Changing lv names (to avoid 11 characters problem):
1. # mkszfile <--creates image.data file of rootvg
2. # vi image.data <--edit image.data
3. # alt_disk_copy -d hdiskX -i /image.data -B <--give image.data fie for alt_disk_copy
--------------------------------------
ONLINE UPDATE WITH ALT_DISK_INSTALL:
unmirrorvg rootvg hdisk1 <--removing mirror ( check: lsvg -p rootvg)
chpv -c hdisk1 <--clears boot record
reducevg rootvg hdisk1 <--free up hdisk1
bosboot -ad hdisk0 <--creates boot record
bootlist -m normal hdisk0 <--sets boot list (check: bootlist -m normal -o)
installp -s <--check if anything can be commited
copy new bos.rte.install <--will be needed for checking if update will be successful (cd to this directory)
install_all_updates -pYd . <--preview of new bos.rte.install
install_all_updates -Yd . <--installs new bos.rte.install
oslevel -sg 5300-09-01-0847 <--shows which fileset is greater than current service pack, it will show bos.rte.install
instfix -i | grep SP <--it will show where to update (53-09-020849_SP)
oslevel -sl 53-09-020849 <--shows which filesets should be update
cd /mnt/5300-09-SP2 <--go to servicepack dir
install_all_updates -pYd . <--preview check
alt_disk_copy -d hdisk1 -b update_all -l /mnt/5300-09-SP2 <--this will do the update
shutdown -Fr <--new OS will boot up
smitty commit <--if needed
alt_rootvg_op -X old_rootvg <--removes cloned old OS
chpv -c hdisk0 <--clears bootrecord
extendvg -f rootvg hdisk0 <--add hdisk0 to rootvg
mirrorvg -S rootvg hdisk0 <--mirror rootvg (-S: in background)
bosboot -a <--creates boot record
bootlist -m normal hdisk0 hdisk1 <--set bootlist
Required filesets:
bos.alt_disk_install.boot_images
bos.alt_disk_install.rte
bos.msg.en_US.alt_disk_install.rte
alt_disk_copy -d <hdisk to clone rootvg> this will clone the rootvg to the specified disk
alt_disk_copy -e /etc/exclude.rootvg -d <hdisk> this will use the exclude list during the cloning
alt_disk_copy -T -d <hdisk> it will convert jfs to jfs2 on the new target disk (from 6.1 TL4 only)
alt_rootvg_op -X <cloned rootvg to destroy> this will destroy the cloned rootvg (alt_rootvg_op -X altinst_rootvg)
alt_rootvg_op -W -d <hdisk> this will wake up a disk (cloned filesystems will be mounted with prefix /alt_)
alt_rootvg_op -S -t <hdisk> this will put cloned rootvg to sleep (before that it will do a bosboot)
(-S: put to sleep earlier "waked up" vg, -t: rebuilds the alt. bootimage before sleep)
alt_rootvg_op -v <new cloned rootvg name> -d <hdisk> this will rename the given cloned rootvg name
(after wake-up and sleep the cloned vg name will be changed, in this case it is useful)
alt_disk_mksysb -m /mnt/aix1mksysb -d hdisk1 -k this will resore given mksysb (aix1mksysb) to hdisk1 (-k: keep device configuration)
/var/adm/ras/alt_disk_inst.log alt_disk log file
----------------------------------
alt_disk_copy: (copy hdisk0 to hdsik1)
lv names can't be longer than 11 characters (because of alt_ prefix)
do not take out that disk which was used during boot (otherwise there will be problems with bosboot)
-unmirrorvg rootvg hdisk1
-reducevg rootvg hdisk1
-bosboot -ad hdisk0
-bootlist -m normal hdisk0
-alt_disk_copy -d hdisk1
-bootlist -m normal hdisk0
after booting from hdisk1:
root@aix11: / # lspv
hdisk0 00cf5d8fe9c88a34 old_rootvg
hdisk1 00cf5d8fadcaa9a9 rootvg active
booting from the old disk:
root@aix11: / # lspv
hdisk0 00cf5d8fe9c88a34 rootvg active
hdisk1 00cf5d8fadcaa9a9 altinst_rootvg
removing the new image (keeping the old one):
-alt_rootvg_op -X altinst_rootvg <--removing the new image from hdisk1
-chpv -c hdisk1 <--clear that pv what contained the removed image
-extendvg -f rootvg hdisk1 <--extend the currently used rootvg with the cleared disk (hdisk1)
-mirrorvg -S rootvg hdisk1 <--mirroring rootvg to hdisk1 (checking: lsvg rootvg | grep STALE)(-S: -background sync)
-bosboot -ad hdisk0; bosboot -ad hdisk1 <--recreate the bootimage
-bootlist -m normal hdisk0 hdisk1 <--setup correct bootlist (checking: bootlist -m normal -o)
------------------------------------
Changing lv names (to avoid 11 characters problem):
1. # mkszfile <--creates image.data file of rootvg
2. # vi image.data <--edit image.data
3. # alt_disk_copy -d hdiskX -i /image.data -B <--give image.data fie for alt_disk_copy
--------------------------------------
ONLINE UPDATE WITH ALT_DISK_INSTALL:
unmirrorvg rootvg hdisk1 <--removing mirror ( check: lsvg -p rootvg)
chpv -c hdisk1 <--clears boot record
reducevg rootvg hdisk1 <--free up hdisk1
bosboot -ad hdisk0 <--creates boot record
bootlist -m normal hdisk0 <--sets boot list (check: bootlist -m normal -o)
installp -s <--check if anything can be commited
copy new bos.rte.install <--will be needed for checking if update will be successful (cd to this directory)
install_all_updates -pYd . <--preview of new bos.rte.install
install_all_updates -Yd . <--installs new bos.rte.install
oslevel -sg 5300-09-01-0847 <--shows which fileset is greater than current service pack, it will show bos.rte.install
instfix -i | grep SP <--it will show where to update (53-09-020849_SP)
oslevel -sl 53-09-020849 <--shows which filesets should be update
cd /mnt/5300-09-SP2 <--go to servicepack dir
install_all_updates -pYd . <--preview check
alt_disk_copy -d hdisk1 -b update_all -l /mnt/5300-09-SP2 <--this will do the update
shutdown -Fr <--new OS will boot up
smitty commit <--if needed
alt_rootvg_op -X old_rootvg <--removes cloned old OS
chpv -c hdisk0 <--clears bootrecord
extendvg -f rootvg hdisk0 <--add hdisk0 to rootvg
mirrorvg -S rootvg hdisk0 <--mirror rootvg (-S: in background)
bosboot -a <--creates boot record
bootlist -m normal hdisk0 hdisk1 <--set bootlist