Regarding your low CPU utilization during expiration: this seems normal.
I did a lot of research (on expiration) afer seeing a similar situation on my
server.
It turns out that expiration is a serial, single threaded operation. Meaning
expiration will only ever use, at most, one CPU.
So if you have a 4-way box, the most you will ever see is expiration using 25%
(of the box). So you 5-10% seems a little low, but normal.
The only way I've found to increase expiration processing is to increase the IO
and the disks that the database is on.
Miles
----------------------------------------------------------------------------------------------
Miles Purdy
System Manager
Information Systems Team (IST),
Farm Income Programs Directorate (FIPD),
Agriculture and Agri-Food Canada (AAFC)
6th Floor 200 Graham Ave. Mailing: PO box 6100
Winnipeg, MB, CA R3C 4N3
R3C 4L5
Office contact: Mobile contact:
purdym AT fipd.gc DOT ca purdym AT
rogers.blackberry DOT net
ph: (204) 984-1602 fax: (204) 983-7557 Cell: (204) 291-8758
"If you hold a UNIX shell up to your ear, can you hear the C?"
-------------------------------------------------------------------------------------------------
>>> throuda AT HTD DOT CZ 10-Sep-04 4:10:29 AM >>>
Hi all,
I have a question for people that are administering simillar TSM system like
me.
TSM server on Sunfire 6800, 4x UltraSparcIII 1.2GHz, Solaris 5.9, Veritas VM
3.5 MP3. Database and diskpools at HP512 disk array with 2x 2Gbit FC HBA
connect.
About 500 TSM nodes including fileservers, Oracle DB, MS Exchange, MS SQL.
About 800-1000GB daily data througput. TSM DB has 54GB allocated space and
about 80% utilization.
Now what is going about: there is about 4 milions examined and about 1
milion deleted objects (average values) during expiration process, which
takes about 3-4 hours every day. This means about 15000obj/min effective
speed, but I know, this value is greatly dependent on deleted object and
less on examined object. Here is last 20 days in table:
DATUM MINT EXAMINED DELETED OBJ_MIN
---------- ------ --------- --------- --------
2004-08-22 263 3398758 615560 12874.0
2004-08-23 228 3351541 612942 14635.5
2004-08-24 206 2484002 650679 12000.0
2004-08-24 28 338548 153478 11674.0
2004-08-24 41 763327 658053 18174.4
2004-08-25 239 2906026 718224 12108.4
2004-08-26 242 3054086 752255 12568.2
2004-08-27 250 3168014 846850 12621.5
2004-08-28 242 2989464 634817 12302.3
2004-08-29 263 3050878 721088 11556.3
2004-08-30 229 2887915 564426 12556.1
2004-08-31 269 3688850 850329 13662.4
2004-09-02 17 148694 124645 8260.7
2004-09-03 209 2140264 1305591 10191.7
2004-09-04 382 5130891 1520585 13396.5
2004-09-05 302 4220154 566306 13927.9
2004-09-06 253 4245286 593276 16713.7
2004-09-07 236 4193877 628473 17695.6
2004-09-08 83 824472 290712 9815.1
2004-09-09 137 2099219 410653 15211.7
2004-09-09 244 3891087 1064453 15881.9
We are monitoring whole system day by day (CPU, disk groups I/O, memory,
network ...blablabla) and there is seen from these data, that CPU is largely
loaded during backups (70-90%), but not during expiration (5-10%). Database
disks have average activity about 0,5MByte/s read and 0,5Mbyte write during
both backups and expiration, and about 12Mbyte/s read during TSM database
backup. But there is about 25% processing time waiting for I/O during both
backups and expiration. There is SELFTUNEBUFPOOLSIZE activated, bufferpool
is 131072 KB and last 2 months no increase was registered.
I have some other experiences on smaller TSM systems with different
configurations, on different hardware and platforms, but all these systems
are much more loaded during expiraton process than during backups. I want to
ask, if somebody has system with similar sizing in production and if these
values (I mean low load affect of expiration process) seems OK, or what si
your expiriences with expirations. Am I supposed to find some bottlenecks in
filesystem/OS/TSM settings? Or is this fenomen caused by size of TSM
environment and is it normal?
Thanks for any suggestions
Tomas Hrouda
Storage Specialist
HTD s.r.o. Praha
CZECH REPUBLIC
throuda AT htd DOT cz
|
