We have a IBM RS6000 F50 running AIX 4.3.3 with 3 CPU's and 9 mirrored disks
and 1.5 GB internal memory. DBMS Basis 9.1 runs on it. This database can be
compared with Oracle regarding performance. However it's not
multi-threading.
We are thinking of upgrading hardware. The F50 cannot handle the job
anymore. The Basis DBMS runs on AIX, Linux and SUN. Our database will be
around 60 GB and should be spreaded on multiple disks (at least 4). In total
we need at least 10 disks (20-40 GB). We need 2-4 GB memory.
The solution should be cheap but also reliable. So, we prefer cheap memory
and cheap (instead of expensive IBM SSA disks) SCSI or even IDE disks.
Please advise.
Regards,
Louis Banens
Ga voor linux met een nas van network appliance, neem dan wel Gb netwerk
voor je nas.
Nobody could possibly answer this question correctly without a heck of
a lot more information. You didn't even mention the basics like where
your bottleneck is.
Thanks for answering.
The bottleneck is CPU and I/O. The database queries take part most of the
bottleneck. We use a relational database model in which we query several
tables with multiple fields to query for (also nested queries). Also, we
expect the amount of concurrent queries to grow quite a bit. Let's say
100-200%.
Things I would like to know is, how does an F50 which is 7 years old now
compare with other newer hardware. Do we stay at the same performance level
(for CPU, I/O) if we buy a Linux box or is a Linux box even less powerful,
or a lot more than such an old F50. Of course this depends on the type of
Linux hardware but I hope to get some advise from the experts what
possibilities there are. Also what would be the advantage of going for Linux
(hardware) and what would be the advantage staying at IBM (or SUN). I think
that the price/performance level is an important factor here.
Regards,
Louis
"David A.Lethe" <da...@santools.com> wrote in message
news:poffev41150eekjak...@4ax.com...
You mention that the database is not multi-threaded. Is it multi-process?
Ie if you buy a 4 CPU server, will it be able to take advantage of it,
or will you be limited to one process being active?
This determines how you can scale it. If it is essentially a single process,
you buy the fastest single or dual processor box you can find. If it
is too slow in a year or two, you replace it. (If it is too slow
now, you've got trouble.)
If the DB can take advantage of multiple processors, you look to buy a box
where you have a bit of room to grow.
The other factor is licensing costs; if the license is too high for
multiprocessor boxes, then the first option of buying the latest
and fastest small box and upgrading it in a year or two can be cheaper.
--
Leach
The Sun blades (or IBM blades) are a nice setup for multiprocess
applications. Go with more memory.. ie 4GB rather than more CPU power.
Also prefer the gigabit ethernet and replace your switches etc
accordingly. I would recommend against load balancing 100/10
ethernets.
Check also how the Basis database is accessed. Is it for example plain
SQL92 commands or even ODBC? I dont know Basis at all, but it might be
resource hungry compared with firebird, postgres or db2. Just
something to think about.
Dave
"Louis" <nos...@nospam.nl> wrote in message news:<3ee728e8$0$49103$e4fe...@news.xs4all.nl>...
Well, I know for sure that we have 3 CPU's on 2 boards. And it runs. See
output of lsc command below,
architecture PowerPC Processor architecture
implementation PowerPC_604 Processor Implementation
version PowerPC_604 Processor version
clock_speed 330.9 CPU clock speed in MHz (approximation)
width 32 Processor width (bits)
ncpus 3 Number of CPUs
realmem 2097152 Amount of usable real memory (Kilobytes)
cache_attrib 1 Split instruction and data cache
icache_size 32 L1 instruction cache size (Kilobytes)
icache_asc 4 L1 instruction cache Associativity
icache_block 32 L1 instruction cache block size (bytes)
icache_line 32 L1 instruction cache line size (bytes)
dcache_size 32 L1 data cache size (Kilobytes)
dcache_asc 4 L1 data cache Associativity
dcache_block 32 L1 data cache block size (bytes)
dcache_line 32 L1 data cache line size (bytes)
L2_cache_size 256 L2 cache size (Kilobytes)
L2_cache_asc 1 L2 cache associativity
tlb_attrib 1 Split instruction and data TLB
itlb_size 128 Instruction TLB size (entries)
itlb_asc 2 Instruction TLB associativity
dtlb_size 128 Data TLB size (entries)
dtlb_asc 2 Data TLB associativity
resv_size 32 Size of reservation (bytes)
priv_lck_cnt 0 Spin lock count in supervisor mode
prob_lck_cnt 0 Spin lock count in problem state
rtc_type RTC_POWER_PC RTC type
virt_alias 0 Hardware aliasing not supported
cach_cong 0 Number of page bits for cache synonym
Xint 312500 Used in time base conversion
Xfrac 12969 Used in time base conversion
Regards,
Louis Banens
"Dave Smith" <dave...@hotmail.com> wrote in message
news:32066b97.03061...@posting.google.com...