>> On Mon, 22 May 2006 11:57:20 -0500, Dave Mussulman <mussulma AT UIUC DOT
>> EDU> said:
> On Fri, May 19, 2006 at 10:05:38PM -0400, Allen S. Rout wrote:
> I don't have a lot of a priori knowledge of TSM, so any sizing
> recommendations I've seen have come from the Performance Guides,
> interviews with a few admins, and general consensus from web
> searches I've done. I agree that if the general concern is getting
> database operations done in a managable timeframe, as long as I can
> architect the db disk well enough, it should size-scale-up fairly
> well. Thoughts on that?
Well, I know of instances with 500G databases which are viewed as
"Well ripe for splitting", rather than as "Screaming panic crisis",
which is what that would be on my disk plant. So the ceiling is high.
If you plan for possible splitting, and implement it as the scaling
becomes inconvenient, you should be good. And if that's "never", then
your overhead for the e.g. library manager instance is not bad.
You have a luxury which, I anticipate, many onlookers are envying:
you're starting from scratch. That'll help. :)
> My numbers come from the Networker reports on the last full. [...]
OK, I'd have to punt that to "not enough data". But since the
transition won't be instantaneous in any case, you will be able to
sketch the problem beforehand.
>> I like the 'beefy box' solution for all purposes except test instance.
>> Make sure it's got plenty of memory. 6G? 8?
> Can you clarify the memory needs? I was thinking 2G of RAM per
> instance; would I need more?
Um. This is a need I have poorly quantified in my own shop. What I
know is that I've got 4G for my 11 instances with a total DB
allocation in the 250GB range. I've got 5G of swap, and I use it;
sometimes I use all of it. I'm not sure where it's going all the
time, because, though I occasionally wait for 3-7 seconds for a
response on 'q proc', the client interaction does not "seem" to
suffer. But I don't really know what that means.
Your LM instance will consume negligible core. I have 9 instances
consuming >200M core total, >160M resident. Oh, heck with this. Here.
Top Processes Procs=191 mode=4 (1=Basic, 2=CPU 3=Perf 4=Size 5=I/O w=wait-procs
PID %CPU Size Res Res Res Char RAM Paging Command
Used KB Set Text Data I/O Use io other repage 0 dsmserv
962606 0.0 488244 324760 4464 320296 0 8% 0 0 0 dsmserv
741538 7.0 430616 164560 4464 160096 178356 4% 0 0 0 dsmserv
761968 2.0 424252 177924 4464 173460 22749814 4% 0 0 0 dsmserv
696478 0.0 325512 36608 4464 32144 0 1% 0 0 0 dsmserv
1310754 0.0 322328 115380 4464 110916 0 3% 0 0 0 dsmserv
757808 2.5 252976 171596 4464 167132 169561 4% 0 0 0 dsmserv
790706 4.0 248324 180948 4464 176484 600614 4% 0 0 0 dsmserv
868510 0.0 244196 163280 4464 158816 0 4% 0 0 0 dsmserv
946258 0.0 222660 164312 4464 159848 0 4% 0 0 0 dsmserv
397336 9.0 192108 76844 4464 72380 87697718 2% 0 0 0 dsmserv
835662 0.0 134928 19676 4464 15212 0 0% 0 0 0 dsmserv
1409074 0.0 126216 11536 4464 7072 0 0% 0 0 0 dsmserv
This is quiet, stabilized behavior.
NMON is your friend, AIX folks.
- Allen S. Rout
|
