Sorry for the delay in posting the summary (Upgrade insanity prevails!).
Firstly, thank you to all who replied for taking the time to write -- I
appreciate your effort.
Secondly, I haven't had the time to implement or even test out any of the
suggestions. There was a variety of experiences represented in the replies
so I'm still sorting them out.
Thirdly, I chose to post each reply rather than summarize because of the
variety of people's uses and experiences. Additionally, since each reply had
so much helpful information I was afraid that if I summarized I might miss
something that somebody reading this might find important. My apologies if
this is too long.
Here's my original question:
Dear Managers -
Has anybody run the disk degragmentation utility that is available from the
CDE ? We'd like to try defragmenting our drives but not ever having done
this before we're concerned with what affects it may have on our system.
We're 4.0E running AdvFS. We have about 1 gb of memory with only a 1 gb
swap partition. The primary uses of this machine is as a database server
(Oracle 7.3.4) and a bit as an application file server. Any and all
thoughts are welcome. I will summarize.
Thank you -
Andy
And here are the replies:
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
> Have a look at the root crontab and see if it's being run automatically...
I know it does under 4.0D.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
With only 1GB of swap, I'd recommend running this when your system is not
being used very much as performance might dip enough to affect response
times. I've never used the CDE front end for this but running the command
line took longer than I had hoped - about 20 minutes on a lightly-used RAID
0+1 set of only 12GB. I have a 4100 with 4 CPUs 4GB of memory and 10GB of
swap.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
I've never used the CDE version, and I have a weekly command line defragment
built in to my backup script that works fine.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
One word of warning. In ver.4.0b crashes due to ADVFS log file problems
were not uncommon. Almost every machine crash I had was related to ADVFS
log file until I increased the log files from the default 512 to 8192. I am
now on 4.0f and it has been rock solid so far. I do not know if this
problem occurs in 4.0e or not.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
Running the defrag once a week works well for me... The file system
performance never really degrades when I run it once a week.... I could
probably do monthly... It depends on the in flow and outflow that you deal
with.
My recommendation is that you just put a command line defrag in cron and run
it during your slowest time.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
It probably just runs defragment, the AdvFS defragmentation
utility. If you want to find out more about the command,
read the manual page for it and whatever is in the AdvFS
admin. guide. The guide is in the documentation directory
of the Associated Products CDROM with the AdvFS utilities.
You might want to run it with the options to report on
fragmentation first. Then if the domain needs defragmentation
you can run it again. It can be fairly I/O intensive when
moving data around, so running it off hours may be wise.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
Hi,
I'm not sure if it is the same program. But we were told the defrag program
that is automatically put in root's crontab just eats system resources.
#0 3 * * 4 /usr/sbin/acct/dodisk > /var/adm/diskdiag &
#1 1 * * * test -x /usr/sbin/defragcron && /usr/sbin/defragcron -p
>>/usr/adm/defragcron.log 2>&1
Compaq told us to remove it from the crontab until they did some firmware
and software fixes in the future. (I don't know when)
We've run it on relatively small systems (6-12Gb) running AdvFS and it was a
hog. Both in system resources and the amount of time it took.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
Andy, I've run defragment against an AdvFS domain and had success with it
running on a "live" system....but I've heard that it is in your best
interest to have all user activity ceased while running it - there are
known bugs... If your domain is spanned over multiple 'volumes' (which can
be checked using showfdmn) - you may also want to look at the balance
utility.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
1) There is a fairly simple procedure for doing the increase of the log
files which I lost when my mail server crashed about 3months ago. If you
give CompaqUnix support a call and tell them that you want the procedure for
increasing the ADVFS log file size, then they will email it to you quickly.
Essentially it consists of using the switchlog command to switch the log
file to a second volume with in the domain. Then you switch the log file
back with a parameter that increases the size. The specific sequence and
syntax you will need to get from Compaq or the archives for the email group.
2) Following is the called shell script that I use to defrag once a week....
Another note.. I have heard that "defragcon" causes problems. I would
comment out or delete from your crontab.
!/bin/ksh
#
. /etc/profile
# /all/scripts/fs-defragment2.s
# This script defragments the ADVFS file systems
# Since this ADVFS file systems change rarely, the commands
# are hard-coded. 'fs-defragment1.s' writes into its own
# log file. 'fs-defragment2.s' is run by the backup script
# and has no log file defined. Standard out/error is written
# to the backup log
#
# ###################################
#
echo "Defragmenting root_domain `date` "
/usr/sbin/defragment -t 30 -v root_domain
sleep 5
echo "#############################"
echo "#############################"
#
echo "Defragmenting usr_domain `date` "
/usr/sbin/defragment -t 45 -v usr_domain
sleep 5
echo "#############################"
echo "#############################"
#
echo "Defragmenting image_domain `date` "
/usr/sbin/defragment -t 30 -v image_domain
sleep 5
echo "#############################"
echo "#############################"
echo "Defragmenting all_domain `date` "
/usr/sbin/defragment -t 300 -v all_domain
sleep 5
echo "#############################"
echo "#############################"
The -t parameter sets a maximum time that the procedure will run and is not
all that important. The -v gives a verbose output and I like having the
information in my log.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
Yes, defragment has a switch that will give you info about the extent of the
defragmentation without actually running the defrag.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
Run a man on defragment to get the syntax.
Hi, I was running defragment on our domains weelkly from cron as I had
previously found that it could make a significant difference to peformance.
HOwever a recent kernel panic was attributed to the defragment utility.
The enginerr I spoke to said that the recommended way to run defragment was
to unmount all file sets in the domain, run verify on the domain and then
run defragment. This kills of any chance of automating the procedure for
us.
>=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<
=
I never run this tool, I use the following line in root's crontab:
1 1 * * * test -x /usr/sbin/defragcron && /usr/sbin/defragcron -p
>>/usr/adm/defragcron.log 2>&1
Never had any Problems. It defrags only AdvFS (no UFS, no swap). Takes about
30
to 45 minutes on a 4.3 GB disk with 3 GB in 3 different domains. On a system
with the above 4.3 GB disk an an additional 9 GB disk (one domain) it can
take
over 3 hours. In this time the system load is above 1 and exhibits peaks
(load about 2.5) from time to time. No idea why the peaks. Any program is
just
slowed down by the disk activity and the system load.
I recommend using defragcron every night via crontab.
Received on Fri Oct 29 1999 - 19:36:27 NZDT