The Need for Throughput - Need Ideas Please
 

Hello! Thank you for reading. I am building a maximum throughput Oracle Linux server. If you have suggestions for the following, I would really appreciate it!

I will be running Oracle 12g and a network, disk intensive forecasting tool

- Drives- SSD or 10,000 RPM Raid 1+0, or combo of both
- CPU - I am not current on the latest. Some 4 quad I would suppose
- Memory - 32 gig + FlashFire
- Network - Some gig card either internal or external

Any suggestions? Thank You!

Hi,

Welcome to LQ!

What's maximum? What are your load requirements?

No specifics, so no one will know the specific needs therefore unable to make recommendations. What does Oracle spec for your applications requirement(s)?

FYI: I suggest that you look at 'How to Ask Questions the Smart Way' so in the future your queries provide information that will aid us in diagnosis of the problem or query.



oracle licenses costing a little fortune, I expect Oracle or your Oracle reseller can advise a cost effective hardware configuration that match your exact needs.

Source: I create hardware configs for my customers for a similarly priced software (not a database though)

Here's my $0.02... (and remember, YMMV):

More spindles always seems to be better with Oracle. Don't put data files and their indices on the same spindle. I work with two different departments at work that are using Oracle and the folks with the slower CPUs and only 2GB of RAM seem to get more throughput than the group that has the faster CPUs and 12GB RAM. The big difference was that the system with the slower CPUs had more disks accessed through multiple controllers. The group with the faster CPU seemed to think they could get their throughput via brute force and only used a single disk controller with larger disks. Moral: Don't overlook the potential for a performance hit due to long I/O queues. Spreading your data across more disks always seems to be a win. If you can still use it, Oracle used to prefer that you do raw I/O to the disks and avoid going through the OS disk/filesystem buffers. (I never saw a big advantage to that -- at least for the work loads we were dealing with -- and haven't seen anyone using raw devices for some years now. I know we left that idea behind about ten years ago. Besides, it complicated the backup process.)

Memory? With Oracle you never seem to have enough. Oracle used to produce some insane benchmarks by running them on systems with gigantic amounts of RAM and fiddling with the database to that it was essentially entirely loaded into memory.

Oracle used to have a performance tuning guide. I have a really old one but the DBAs that I work with have newer guides. Can't remember if they were one of the standard manuals you could get from Oracle or whether they were written by others. I recall referring to my copy when I'd sit down with the DBAs to see what we could do to wring more performance out of the system after some new application started banging away at the database. Not all of it covered things that I could do -- much it would be more applicable to the DBA who'd be looking at the database performance statistics and figuring out how to tune queries -- but sometimes a kernel parameter change or more hardware might be needed.

One thing to watch out for that I've noticed and seems to be a real performance killer: If Oracle is allowed to automatically extend files it tends to extend them in small increments (at least I haven't run into any DBAs that know how to prevent that) and you wind up with lots of small files being used by the database. The effect on performance is especially horrific if the file that Oracle is extending in dribs and drabs is being used as Oracle query temp space.

Hope some of the above helps.

--
Rick

I had to laugh when I reread your reply. Yep, you could build a system using a single 1TB disk or a slew of SSDs and in each case you would achieve "maximum throughput". For that system configuration. Once upon a time, your system design would have a response time or transaction/sec you were shooting for when N users were using the system, etc. When you failed to hit that, you knew you needed to identify the bottlenecks and make changes to the system.

Every day I see folks submitting change requests for some pretty significant upgrades to systems that were installed only a few months ago. Oracle filesystems filling up after only a couple of months of operation? Crazy requests for RAM? Geez. When you have a 6 month old system and you're asking to double the RAM to 128GB someone's going to wonder how much effort actually went into the initial requirements gathering/analysis/etc. phase of that project.

Hopefully, the OP has been thinking of how the system is going to need to run for the first year or so. (Management isn't real fond of IT people constantly asking for upgrade money. Especially nowadays.)


--
Rick

Hi,

Personally, I would look beyond the first year for a new sys-gen. Over-sizing is just as bad as under if not done properly. Spanning things across multiple media can be beneficial when done properly is just one example. Ramdisk is another area that is sometimes overlooked but can be used to benefit throughput. I could go on and on but it's not in my job description to perform this action for the OP. :)

It happens all the time, people think that hitting things from general hardware specifics will meet the needs. Each site has specific requirements and each sys-gen should be setup to meet the local requirements. Both hardware & software should be sized or setup to meet the local requirements. That is where IT should interact with reputable vendors/suppliers.

Yes, from a IT perspective you had better get things right from the start. Or things will roll other than just wheels.

Thanks!
 

Thank You All!