Floyd Wellershaus wrote:
> we have had some network issues.
> The sars don't look different or excessive.
> We are doing a full archive every night, and the database hasn't grown
> much since last week, so that's not it.
>
> I am trying to be able to intrpret the onstat -g stq so that I can
> hopefully see if the tape drive may be the bottleneck or the server end.
>
> Thanks,
> floyd
Haven't done it in a while (no backup performance problems to
interprete) but If I recall it correctly:
full queue is where arcbackup1 has put data to get backed up . Empty
queue is where there are backup buffers for arcbackup1 to get grabbed
for additional pages.
So if you see almost always buffers in full queue (and waiters on empty
queue) I'd assume that the storage manager (or XBSA interface) does not
grab the data quick enough for IDS. --> search for problems downstream
of onbar (i.e. , network , storage manager, tape library...).
If it is almost always empty queue which has all the buffers, arcbackup1
does not deliver fast enough. --> IDS or chunk disk subsystem not fast
enough.
If it is the later case, check read performance on all the chunks.
Here is a little UNIX command to help you doing a dd on all chunks.
It dumps the dd commands to a file called ddfile , assumes 2k pages size
and you need to replace <chunk> with something that greps all and only
your chnks in the onstat -d output.
(If you have other page sizes adjust bs, and the factor to calculate
count and skip in the awk command)
NB! There are probably better and more sophisticated ways out there ,
but its a quick way to *****s disk speed for IDS.
!Disclaimer: AS-IS, no warranty, no liablibilty , not tested
extensively! )
onstat -d | grep <chunk> | tr -s ' ' | cut -f 4,5,6,8 -d' ' | awk
'{skip=$1/2; count=($2-$3)/2; printf "dd if="$4" of=/dev/null bs=2k
skip=%d count=%d",skip, count ; print ""}' >ddfile
HTH
Tilman
|
