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: [EMAIL PROTECTED] [EMAIL PROTECTED] 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?" ------------------------------------------------------------------------------------------------- >>> [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
