High Utilization using Arcserve 7

[lfa...@aoncons.com]

Hi All!

I too am having problems with Arcserve 7 EE. I
have multiple NW 5.1 sp2a servers. A couple are
running Arcserve 6.6, and some are running
Arcserve 7 EE. On two of the servers running
version 7, I get extremely high utilization (98-
99%)when an Arcserve backup job starts. If I try
to cancel the job or stop Arcserve, the server
abends. If I let the job continue, it slows to a
crawl, and keep the utilization high for several
days. I always end up having to abend the server
to get the job canceled.

CA's tech support is a joke. Can anyone point me
in the right direction?

Thanks!

[chris wilson]

This was from my other post, which is similar to your problem (but not identical)

Take it for what its worth. No gaurantees, but probably worth a shot:

Parts of this post may sound bizarre, but I'm telling you this trick
works wonders in my environment.

I am on ArcServe 6.6, and I used to experience terrible server freezes
and lockups during restores, inventories, and compares. All users
logged into the server were completely locked up, and upon rebooting
the server was still so slammed they could not even login. Very bad
scenario.

Believe it or not, CA really isn't completely making stories up.
Novell does have some issues with their OS architecture, when there
are "long SCSI commands", the server will devote too many resources to
that command, and nothing else gets any attention.
It has something to do with the kernel sitting on top of DOS, and
switching to "real mode" that has these terrible effect on the some
servers, in some environments. There is no clean-cut case where I
tell whether or not it will happend.

I *think* it's a combination of drivers, Netware, ArcServe, SCSI
cards, and possibly even specific tape drives. It is VERY random.
We've seen it in about 10-20% of our offices. The other 80% think we
are lying when we cry and complain to them about our problems.

Finally: the trick that took us months to figure out. It was
suggested to us by Novell. *** Do not try this during working hours
***

At the console:

"Load DOSFAT.NSS"

Make sure that DOS is mounted as a volume by typing "Volumes" at the
console

The server seemingly does not have to switch to "real mode" (or at
least does not kill the server while switching to real mode) if DOS is
mounted as a volume.

After we applied this, we can restore, compare, inventory, and backup
at anytime without the "locking" and "not responding" problem. We've
thoroughly tested it. If we unload DOSFAT, we IMMEDIATELY see
problems. We unloaded it, tried a test restore, and the phones went
off the hook with screaming users who were locked out of their files.
The server couldn't even load "nwconfig" it was getting hit so hard.
Re-Load DOSFAT.NSS (after a 2 minute delay), and everyone is happy,
the server is responding normally.

I can't explain the details inside the Netware OS, but I can tell you
that there are some really weird things we've had to do to get things
working acceptably.

We load dosfat.nss in our autoexec.ncf. It saved our jobs! I know
our software and server are different, but this really sounds similar
to our problems

Good luck, and make sure to let us know if this was the fix.
chris

lfa...@aoncons.com wrote in message news:<L3Gu7.620$h%.1635@prv-forum2.provo.novell.com>...

[Archie McNee]

Maybe not related to your problem but I found that the Inoculan version
supplied with AS7 causes file server utilisation to sit at over 40% even
when the server is doing nothing.

Archie

<lfa...@aoncons.com> wrote in message
news:L3Gu7.620$h%.1635@prv-forum2.provo.novell.com...