Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Dwindling\s+Performance\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Dwindling\s+Performance\s*$/: 13 ]

Total 13 documents matching your query.

1. Dwindling Performance (score: 1): Author: Andy Carlson <andyc AT ANDYC.CARENET DOT ORG>; Date: Tue, 13 Jan 2004 20:38:10 -0600; We are having terrible performance with one of our instances of TSM. I have suspicions, but I want to hear what you guys say. Here is what we have: 2 instances of TSM - TSMI and TSMU (TSMI is the pro; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00306.html (12,371 bytes)
2. Re: Dwindling Performance (score: 1): Author: Roger Deschner <rogerd AT UIC DOT EDU>; Date: Wed, 14 Jan 2004 00:58:13 -0600; I have posted many times in the past saying you should never do a database unload/reload to gain performance. But this just might be the one case where it might make sense - the remaining half of a s; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00307.html (15,065 bytes)
3. Re: Dwindling Performance (score: 1): Author: Joe Howell <jhowell_tsm AT YAHOO DOT COM>; Date: Wed, 14 Jan 2004 05:33:10 -0800; Andy - what kind of clients do you have? I've had problems with Windows clients all trying to do systemobject backups simultaneously and had to reorganize my nightly work to split out the systemobjec; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00324.html (13,232 bytes)
4. Re: Dwindling Performance (score: 1): Author: Richard Sims <rbs AT BU DOT EDU>; Date: Wed, 14 Jan 2004 08:51:41 -0500; Andy - We'd like to help, but would need a lot more information about the context of the issue, and in particular what you've already investigated. I'd refer you first to the TSM Performance Tuning; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00325.html (11,829 bytes)
5. Re: Dwindling Performance (score: 1): Author: Andy Carlson <andyc AT ANDYC.CARENET DOT ORG>; Date: Wed, 14 Jan 2004 08:07:21 -0600; Thanks for the quick response. Expiration is not finishing. Before the main backups start, it maybe expires 200000 objects, but during the backup window it slows to a crawl. It picks up some during t; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00326.html (17,113 bytes)
6. Re: Dwindling Performance (score: 1): Author: Andy Carlson <andyc AT ANDYC.CARENET DOT ORG>; Date: Wed, 14 Jan 2004 08:09:23 -0600; I'll supply as much information as anyone wants if they have any clues about what could be going on. I will take a look at the current performance book, but I have looked at it in the past. Andy Carl; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00327.html (12,726 bytes)
7. Re: Dwindling Performance (score: 1): Author: "Scott, Brian" <bscott AT EDS DOT COM>; Date: Wed, 14 Jan 2004 10:50:34 -0500; Andy, Have you thought about using the TSM Journal Service? If you're building a ton of directories/files but not backing up much the journal will cut down on the processing and keep your sessions do; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00329.html (17,795 bytes)
8. Re: Dwindling Performance (score: 1): Author: Ben Bullock <bbullock AT MICRON DOT COM>; Date: Wed, 14 Jan 2004 08:52:50 -0700; Hmmm, interesting that the expire inventory grinds to a halt during incremental backups. My setup is AIX similar to yours (host, DB size) although my disks are on locally attached SSA drives. I recen; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00330.html (19,060 bytes)
9. Re: Dwindling Performance (score: 1): Author: Dwight McCann <dwight AT TRIXIE.ISC.UCSB DOT EDU>; Date: Thu, 15 Jan 2004 09:59:48 -0800; Roger, I really enjoyed and appreciated your response on this issue, but you've got me to wondering at bit. I'm running TSM 5.1.8 on Win2K with 2G RAM. I looked at my migration times which are about; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00363.html (14,805 bytes)
10. Re: Dwindling Performance (score: 1): Author: Roger Deschner <rogerd AT UIC DOT EDU>; Date: Thu, 15 Jan 2004 13:56:14 -0600; Oh, how I love quoting directly from IBM manuals: "If the value falls below 98%, consider increasing the size of the database buffer pool. For larger installations, performance could imporve signific; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00372.html (16,304 bytes)
11. Re: Dwindling Performance (score: 1): Author: "Rushforth, Tim" <TRushforth AT WINNIPEG DOT CA>; Date: Thu, 15 Jan 2004 15:41:55 -0600; Note that with SELFTUNEBUFPOOLSIZE, there are some limits on the size of the bufferpool. It used to be 10% of real memory for Windows. (Which you are not at if you have 2GB memory.) Check for the fol; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00381.html (17,070 bytes)
12. Re: Dwindling Performance (score: 1): Author: Chris Murphy <cmurphy AT IDL.STATE.ID DOT US>; Date: Thu, 15 Jan 2004 14:57:26 -0700; <snip> Memory is so cheap that you can afford to throw lots of it at it. Hi Dwight, I wanted to throw out one note of caution. I completely agree with Roger: memory is too cheap to rob your system of; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00382.html (12,416 bytes)
13. Re: Dwindling Performance (score: 1): Author: Ben Bullock <bbullock AT MICRON DOT COM>; Date: Thu, 15 Jan 2004 15:07:25 -0700; I ~LOVE~ to hear words like that ;-) BUY MORE MEMORY.... BUY MORE MEMORY... YOU ARE FEELING VERY SLEEPY.... Ben (FYI, I work for Micron, a DRAM manufacturer) http://www.crucial.com or http://www.micr; /usr/local/webapp/mharc-adsm.org/html/ADSM-L/2004-01/msg00383.html (13,019 bytes)

Current List: 1 - 13
Page: [1]