Paul,
I know it's been a while since you posted this but I wanted to share my
insights. We've received the same complaints.
The problem is not TSM per se, but the fact that I/O is interrupt-based
and the interrupt service routines run at high-priority. This also
affects any scan process, including anti-virus. For years, the AV writers
set their software to scan at the lowest possible priority, only to have
it create a huge impact on the machine anyway.
No matter how low a priority the process runs, once it tells the storage
system to read a file, that file read will run at high priority until it
completes the transaction.
On the network, there is another factor to consider, that was discussed
recently by Intel engineers in one of the IEEE computer magazines.
Incoming network data ends up being placed in memory by the NIC driver
without being cached by the CPU. When the NIC generates the interrupt
telling the CPU to process the received data, its absence in every level
of CPU cache causes a cache miss and at today's clock cycles, a stall of
several hundred cycles while the addresses and data make their way into
the cache hierarchy. Since at the start of every standard TSM backup, the
client receives over the network the list of files already known to TSM,
that qualifies as "incoming data". Outgoing data is less of a factor
since the processor is setting up the data in the various buffers.
Therefore, what we've chosen to do is this:
* provide a set of hourly schedules spread between 8 pm and 5 am; a PC -
CAD workstation in our case - can be set to "backup no earlier than xxx".
If I have an engineer who frequently works till 8 pm, I can schedule his
PC to backup at 11 pm, for example. We also have a special "noon" backup
schedule for docked laptops.
* tune TCP window size to reduce the number of acknowledgements;
* tune the client aggregation settings to minimize the number of data
bursts; we have our system set to create 48 MB aggregates by default. The
larger the aggregate, the fewer number of transfers will be made, but the
more memory will be needed to buffer the aggregate under construction.
* turn off anti-virus scanning on files "when opened for backup"; all PCs
have real-time scan enabled so it isn't necessary to re-scan when backing
up.
Hope this helps.
Tab Trepagnier
TSM Administrator
Laitram LLC
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 04/25/2006
01:13:58 PM:
> We have a small number of users here who are complaining that when a
> TSM backup runs on their client system, it monopolizes use of their
> network card. They are looking for a way to throttle back TSM's use
> of the network. Has anyone else run into this? Any ideas? The only
> thing I've come up with is to configure a secondary NIC at 10MB/s and
> point these users at that card. This seems crude to me, so other
> ideas would be welcome.
>
> ..Paul
>
>
> --
> Paul Zarnowski Ph: 607-255-4757
> Manager, Storage Systems Fx: 607-255-8521
> 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
|
