From: Mohamed K. Ahmed (mkahmed@vsc.teksystems.com)
Date: Tue Nov 26 2002 - 10:55:16 EST
Thanx to Dr. Tom Blinn and Johan Brusche
Pointed out that /dev/ntape/tape0c is the one that uses high denisty
like the old /dev/nrmt0h, see man tz for more useful information.
Also using the -C switch means doing compression on the software level
(ie by the system), while I had a tape drive DLT892 that does
compression by itself (better let the tape drive do it) and for an old
system as my AS2100, this software compression was consuming a lot of
CPU %.
Below are the replies:
---------------------------------------------
>From Dr. Tom Blinn:
"One thing I can see here is that you are asking vdump to do data
compression in software (that's what the -C switch does). Whether
this is useful depends on your tape drive (if your tape drive can
do compression in the drive, you are USUALLY better off letting
the drive do the compression, it's got dedicated hardware to do
it, and if you can't feed it data fast enough because you've got
a single thread of execution on the host trying to compress data
on the fly before sending it to the tape drive, then you wind up
with the drive not able to stream data onto the tape, which takes
up more tape space, plus if the drive is trying to compress data
that was already compressed by the host system, it can wind up
taking MORE space on the tape!).
Since this is just an AS2100, it does not surprise me at all that
you can consume 100% of a CPU doing data compression. While this
may have changed from some earlier patch level, it's not surprising
at all to me. I can't tell whether you have a valid baseline for
comparison from your mail. My advice is consider turning off data
compression in the host software and let the tape drive do it if
it does in fact support hardware data compression (almost ALL of the
current modern tape drives do that unless you tell them not to).
There is a reference page -- it's either "tz" or "tape" or something
of that nature (try "apropos tape" to find it) that should tell you
the magic decoder method for tape drive names; I believe that the "c"
name is high density with compression enabled for tape drives that do
support that mode."
-----------------------------------------
>From Johan Brusche:
"Don't use the -C switch on vdump !!
On the contrary use the tape0c device for compression and NOT the tape0
device.
In V4.0x rmt0h is the device WITH compression rmt0m WITHOUT.
on V5.x tape0c is the same as rmt0h.
The tape drive is doing the compression probably better than
the CPU."
Thanx to all
Mohamed
----- Original Message -----
From: "Mohamed K. Ahmed" <mkahmed@vsc.teksystems.com>
Date: Friday, November 22, 2002 12:06 pm
Subject: 5.1 vdump 99.9% CPU
> Hi all,
>
> I have a couple of systems that I upgraded to V5.1 patchkit #5
> While I am doing a vdump for some files, I noticed that it takes
> longer time than before, and the CPU usage is very very high.
> This happens on all systems with V 5.1, may be I have to tweak the
> 5.1 version with something that I hope you can help me with.
>
> Please advice
>
> Mohamed
>
> Here is some outputs for one of the systems, it is AS2100 3 CPUs 2
> GB memory, 4GB swap
>
>
> ps -ef:
>
> root 1648 648 0.0 11:08:00 ?? 0:00.03 sh -
> c /c01/oracle/backup/cron_backup > /c01/oracle/backup/syslog/root.log
> root 1649 1648 0.0 11:08:00 ?? 0:00.02 [sh]
> root 1653 1649 0.0 11:08:00 ?? 0:00.03
> sh /c01/oracle/backup/cronbackup.com
> root 1852 628 0.0 11:09:30 ?? 0:00.24
> rpc.ttdbserverd
> root 3530 1653 100.4 11:25:54 ?? 37:47.42 vdump -
> 0 -u -C -f /dev/ntape/tape0 /c01
>
>
> # vmstat 2 7
> Virtual Memory Statistics: (pagesize = 8192)
> procs memory pages intr
>
> cpu
> r w u act free wire fault cow zero react pin pout in sy
> cs us sy id
> 7 173 32 133K 105K 16K 686K 73K 231K 0 234K 0 74 67K
> 419 27 32 41
> 6 174 32 133K 105K 16K 355 36 107 0 124 0 42 65K
> 327 36 31 33
> 6 174 32 133K 105K 16K 264 28 120 0 127 0 44 69K
> 326 35 32 33
>
> Total swap allocation:
> Allocated space: 546667 pages (4.17GB)
> Reserved space: 8538 pages ( 1%)
> In-use space: 3 pages ( 0%)
> Available space: 538129 pages ( 98%)
> # psrinfo
> 0 on-line since 11/22/2002 11:00:36
> 1 on-line since 11/22/2002 11:00:36
> 2 on-line since 11/22/2002 11:00:36
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:00 EDT