Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Matthew Glanville
Some lucky individual (me), was able to get TSM servers with 32 GB of memory. All the documentaiton/redbooks from IBM/Tivoli on that I could find, indicates that BUFPOOLSIZE should be tuned so DB cache hit rate is 98 and of course, common sense indicates higher hit rates are bettter. There also

Re: Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Andrew Carlson
I saw something very like this. If I increase my bufpool size above 2GB, eventually TSM slows down to a crawl. I called IBM, and they tried to send me to the performance group, so I just told them nevermind, I'll put it back down to 2GB. Matthew Glanville wrote: Some lucky individual (me),

Re: Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Allen S. Rout
On Fri, 27 Jan 2006 10:11:55 -0500, Matthew Glanville [EMAIL PROTECTED] said: Unfortunately it appears that the TSM server, when using the database buffer doesn't have very good method to find things in that buffer. Thus searching through 30 GB of memory, or 10, or the class

Re: Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Matthew Glanville
Oo, neat! Do I understand you correctly to say that you've got 32G of memory and a 4G database? If you've got core of a similar size to your DB, then I suggest an experiment: instead of sticking it all in a buffer, make some RAMdisk, and stick a third copy of your DB vols there, and see if

Re: Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Richard Sims
I think the discussion could use more details about the architecture being used. If you haven't already, see IBM Technote 1208540. Richard Sims

Re: Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Allen S. Rout
On Fri, 27 Jan 2006 12:05:54 -0500, Matthew Glanville [EMAIL PROTECTED] said: BUFPOOLSIZE when it is too large, which my guess is the point at which a search through that much memory takes longer than a disk read. The larger it it gets, the slower database reads get... This mostly

Re: Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Matthew Glanville
I think the discussion could use more details about the architecture being used. If you haven't already, see IBM Technote 1208540. Richard Sims Ahh those details. TSM server 5.3.2 on Solaris 9, 64 bit, 8 cpus' 32 GB ram. DB size, 150 GB, 75% used Current BUFPOOLSIZE 1 GB My

Re: Serious performance problems with large BUFPOOLSIZE

2006-01-27 Thread Richard Sims
On Jan 27, 2006, at 1:54 PM, Allen S. Rout wrote: Sounds like that would make a fascinating chart. And the recommended formula would have led you to something like 20G, right? With the really slow points, was the cache hit percentage good? Something else that could be interesting is to set