ontape pipe restore times
Mark was piping an ontape level-0 archive over rsh to a remote server (ontape -s ... | rsh server ontape -p) on IDS 11.50 AIX, capping out at ~12 MB/s and ~4.5 hours, with ARCHIVE_BUF_COUNT and TAPEBLK tweaks making no difference. Art pointed out that 100 Mbit Ethernet equals ~12 MB/s, so the link was already saturated; the only real fix is gigabit hardware. Madison and Paul suggested compressing the stream (gzip | rsh | gunzip), which raised throughput to ~40 MB/s. Others mentioned pigz or bzip2 as faster alternatives, with a caution about CPU usage.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
11.50.FC8 AIX 5.3
I am looking to see if there is anyway an ontape pipe restore could be mande
to restore faster. (ontape -s -L 0 -t STDIO | rsh server ontape -p -t STDIO).
During my testing the best thruput I can realize so far is around
12meg/second. The network is local , fast ethernet 100meg/second.
Instance is 300 gigs, out of which there are 200 gigs of used space . Out of
that metric is ~105 gigs of total used blobspace blob pages. So far the best
thruput obtained is around 3000 pages/second (12 mg/second ) which equates to
around 4.5 hours to restore. I have tried allocating more transport buffers
(ARCHIVE_BUF_COUNT) from the default of 4 to 24 (and even higher) and
increased TAPEBLK to much higher values (16384) but that had no impact at all.
It pretty much appears with pipe restores the transfer rate is limited by the
OS and/or network somehow. FYI, using a tape dev I can restore the server < 2
hrs so that kind of pushes blame away from i/o.
Regards,
Mark
ontape -s -L -o -t STDIO | gzip | rsh server | gunzip | ontape -p -t ST=DIO
You might want to execute into a remote script.
From: "MARK JALKIEWICZ" <mark.jalkiewicz@verizon.net>
To: ids@iiug.org,
Date: 08/17/2012 12:04 PM
Subject: ontape pipe restore times [28067]
Sent by: ids-bounces@iiug.org
11.50.FC8 AIX 5.3
I am looking to see if there is anyway an ontape pipe restore could be
mande
to restore faster. (ontape -s -L 0 -t STDIO | rsh server ontape -p -t
STDIO).
During my testing the best thruput I can realize so far is around
12meg/second. The network is local , fast ethernet 100meg/second.
Instance is 300 gigs, out of which there are 200 gigs of used space . O=
ut
of
that metric is ~105 gigs of total used blobspace blob pages. So far the=
best
thruput obtained is around 3000 pages/second (12 mg/second ) which equa=
tes
to
around 4.5 hours to restore. I have tried allocating more transport buf=
fers
(ARCHIVE_BUF_COUNT) from the default of 4 to 24 (and even higher) and
increased TAPEBLK to much higher values (16384) but that had no impact =
at
all.
It pretty much appears with pipe restores the transfer rate is limited =
by
the
OS and/or network somehow. FYI, using a tape dev I can restore the serv=
er <
2
hrs so that kind of pushes blame away from i/o.
Regards,
Mark
***********************************************************************=
********
Forum Note: Use "Reply" to post a response in the discussion forum.
=
Your network is 100 megaBITS per second which at 8bits per byte works out to
12 megaBYTES per second. You are getting maximum throughput now. To get more
you will have to upgrade your network infrastructure an nic cards to GB or
better.
Art
Sent from my Galaxy S®IIIMARK JALKIEWICZ <mark.jalkiewicz@verizon.net>
wrote:11.50.FC8 AIX 5.3
I am looking to see if there is anyway an ontape pipe restore could be mande
to restore faster. (ontape -s -L 0 -t STDIO | rsh server ontape -p -t STDIO).
During my testing the best thruput I can realize so far is around
12meg/second. The network is local , fast ethernet 100meg/second.
Instance is 300 gigs, out of which there are 200 gigs of used space . Out of
that metric is ~105 gigs of total used blobspace blob pages. So far the best
thruput obtained is around 3000 pages/second (12 mg/second ) which equates to
around 4.5 hours to restore. I have tried allocating more transport buffers
(ARCHIVE_BUF_COUNT) from the default of 4 to 24 (and even higher) and
increased TAPEBLK to much higher values (16384) but that had no impact at all.
It pretty much appears with pipe restores the transfer rate is limited by the
OS and/or network somehow. FYI, using a tape dev I can restore the server < 2
hrs so that kind of pushes blame away from i/o.
Regards,
Mark
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Or compress the data
Cheers
Paul
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art S.
Kagel
Sent: Friday, August 17, 2012 1:42 PM
To: ids@iiug.org
Subject: RE: ontape pipe restore times [28069]
Your network is 100 megaBITS per second which at 8bits per byte works out to
12 megaBYTES per second. You are getting maximum throughput now. To get more
you will have to upgrade your network infrastructure an nic cards to GB or
better.
Art
Sent from my Galaxy SRIIIMARK JALKIEWICZ <mark.jalkiewicz@verizon.net>
wrote:11.50.FC8 AIX 5.3
I am looking to see if there is anyway an ontape pipe restore could be mande
to restore faster. (ontape -s -L 0 -t STDIO | rsh server ontape -p -t
STDIO).
During my testing the best thruput I can realize so far is around
12meg/second. The network is local , fast ethernet 100meg/second.
Instance is 300 gigs, out of which there are 200 gigs of used space . Out of
that metric is ~105 gigs of total used blobspace blob pages. So far the best
thruput obtained is around 3000 pages/second (12 mg/second ) which equates
to
around 4.5 hours to restore. I have tried allocating more transport buffers
(ARCHIVE_BUF_COUNT) from the default of 4 to 24 (and even higher) and
increased TAPEBLK to much higher values (16384) but that had no impact at
all.
It pretty much appears with pipe restores the transfer rate is limited by
the
OS and/or network somehow. FYI, using a tape dev I can restore the server <
2
hrs so that kind of pushes blame away from i/o.
Regards,
Mark
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
thanks Madison, that certainly improved things. restoring at 40mg/sec now.. Regards, Mark
>> Your network is 100 megaBITS per second which at 8bits per byte works out to 12 megaBYTES per second. yeah, I missed that part in my crunching. You are getting maximum throughput now. To get more you will have to upgrade your network infrastructure an nic cards to GB or better. >> sometimes very soon I am told. the compress/uncompress seems to have helped things along for the time being. Thanks, Mark
This would be faster than gzip if you are now CPU rather than network limited (no difference with gunzip): http://zlib.net/pigz Regards, Doug Lawry
Yes, but don't run it during production times it will tend to eat every CPU cycle it can get ahold of. Bzip2 is another one, about as fast as gzip but lighter overhead and bunzip is faster than gunzip. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Sun, Aug 19, 2012 at 4:11 AM, DOUG LAWRY <douglawry@hotmail.com> wrote: > This would be faster than gzip if you are now CPU rather than network > limited > (no difference with gunzip): > > http://zlib.net/pigz > > Regards, > Doug Lawry > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340ecd37529d04c79d89b5