Hello, we have an aix 6.1 LPAR that seems to be experiencing intermittient performance problems when it backs up it's Progress database to a jfs2 file system. This file system had 1 Volume group with three 8-way striped meta volumes from a symmetrix array (total of 24 symm devices all on different disks). The LV was striped - see output from lsvg and lslv commands below. I don't like the 64k stripe size it probably would have been better at 256k. There was a thought that the LV striping along with the striping on the array may be causing an issue. Does striping at the LV cause more unneccessay IOs or some other problem?
So we created an new VG with only one volume - a 24-way striped meta. It has one LV but of course no striping at the LV this time. So far we have not seen an improvement in backup times. Any thoughts?
root@wfdscr05:/prod/oe10/probkup/c#lsvg -p probkupc
probkupc:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdiskpower97 active 272 0 00..00..00..00..00
hdiskpower98 active 272 1 00..00..00..00..01
hdiskpower99 active 272 1 00..00..00..00..01
root@wfdscr05:/prod/oe10/probkup/c#
root@wfdscr05:/prod/oe10/probkup/c#lsvg -l probkupc
probkupc:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
lv_probkupc jfs2 813 813 3 open/syncd /prod/oe10/probkup/c
loglv35 jfs2log 1 1 1 open/syncd N/A
root@wfdscr05:/prod/oe10/probkup/c#lslv lv_probkupc
LOGICAL VOLUME: lv_probkupc VOLUME GROUP: probkupc
LV IDENTIFIER: 00f6618700004c0000000130054b4cf7.1 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: jfs2 WRITE VERIFY: off
MAX LPs: 2048 PP SIZE: 256 megabyte(s)
COPIES: 1 SCHED POLICY: striped
LPs: 813 PPs: 813
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: maximum RELOCATABLE: no
INTRA-POLICY: middle UPPER BOUND: 3
MOUNT POINT: /prod/oe10/probkup/c LABEL: /prod/oe10/probkup/c
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes (superstrict)
Serialize IO ?: NO
STRIPE WIDTH: 3
STRIPE SIZE: 64k
root@wfdscr05:/prod/oe10/probkup/c#
So we created an new VG with only one volume - a 24-way striped meta. It has one LV but of course no striping at the LV this time. So far we have not seen an improvement in backup times. Any thoughts?
root@wfdscr05:/prod/oe10/probkup/c#lsvg -p probkupc
probkupc:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdiskpower97 active 272 0 00..00..00..00..00
hdiskpower98 active 272 1 00..00..00..00..01
hdiskpower99 active 272 1 00..00..00..00..01
root@wfdscr05:/prod/oe10/probkup/c#
root@wfdscr05:/prod/oe10/probkup/c#lsvg -l probkupc
probkupc:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
lv_probkupc jfs2 813 813 3 open/syncd /prod/oe10/probkup/c
loglv35 jfs2log 1 1 1 open/syncd N/A
root@wfdscr05:/prod/oe10/probkup/c#lslv lv_probkupc
LOGICAL VOLUME: lv_probkupc VOLUME GROUP: probkupc
LV IDENTIFIER: 00f6618700004c0000000130054b4cf7.1 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: jfs2 WRITE VERIFY: off
MAX LPs: 2048 PP SIZE: 256 megabyte(s)
COPIES: 1 SCHED POLICY: striped
LPs: 813 PPs: 813
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: maximum RELOCATABLE: no
INTRA-POLICY: middle UPPER BOUND: 3
MOUNT POINT: /prod/oe10/probkup/c LABEL: /prod/oe10/probkup/c
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes (superstrict)
Serialize IO ?: NO
STRIPE WIDTH: 3
STRIPE SIZE: 64k
root@wfdscr05:/prod/oe10/probkup/c#