Thread: Hardware question for a DB server
Hello, we plan to buy a dedicated server to host our database. Here is the proposal I was given (with a second identical server fro backup using log shipping): ========================= IBM X3650 (This is a 2U server, can hold 8 Drives) 2 x QC Xeon E5450 (3.0GHz 12MB L2 1333MHz 80W) 8 x 2GB RAM (16GB total) 2.5" SAS Hotswap ServeRAID-8K SAS Controller 8 x 73GB 15K 2.5" SAS Drive CD/DVD Drive Remote Supervisor Adapter II Slimline Redundant Power 4 Year, 24x7 2hour support/warranty ========================= I would like specialists advices. If you need additional details, please let me know. Thanks in advance for your help Thank you Pascal
What type of usage does it need to scale for? How many concurrent connections? What size database? Data warehousing or OLTP-type workloads? Ratio of reads/writes? Do you care about losing data? One question that's likely going to be important depending on your answers above is whether or not you're getting a battery-backed write cache for that ServeRAID-8K. -- Mark Lewis On Wed, 2008-03-12 at 19:58 +0100, Pascal Cohen wrote: > Hello, we plan to buy a dedicated server to host our database. > Here is the proposal I was given (with a second identical server fro > backup using log shipping): > ========================= > IBM X3650 (This is a 2U server, can hold 8 Drives) > 2 x QC Xeon E5450 (3.0GHz 12MB L2 1333MHz 80W) > 8 x 2GB RAM (16GB total) > 2.5" SAS Hotswap > ServeRAID-8K SAS Controller > 8 x 73GB 15K 2.5" SAS Drive > CD/DVD Drive > Remote Supervisor Adapter II Slimline > Redundant Power > 4 Year, 24x7 2hour support/warranty > > ========================= > > I would like specialists advices. > > If you need additional details, please let me know. > > Thanks in advance for your help > > Thank you > > Pascal >
Mark Lewis wrote: > What type of usage does it need to scale for? How many concurrent > connections? What size database? Data warehousing or OLTP-type > workloads? Ratio of reads/writes? Do you care about losing data? > I expected those questions but I was sure that I would forget or ignore some ;) - This Database will be accessed by Web applications but also by an XMPP server. This means that those are not complex requests but we may have a number of high parallel requests for small results. Ideally as many connections as possible would be nice. - I am not sure but I would say from what I found thanks to Google is that we are probably closer to an OLTP type workload (but I may be wrong) - Size of the DB: a few Gb but not yet more than the 16Gb. - It is a read mainly database (8/9 reads for 1 write) with potential batch updates - We cannot afford (anymore) losing data. > One question that's likely going to be important depending on your > answers above is whether or not you're getting a battery-backed write > cache for that ServeRAID-8K. > > -- Mark Lewis > > On Wed, 2008-03-12 at 19:58 +0100, Pascal Cohen wrote: > >> Hello, we plan to buy a dedicated server to host our database. >> Here is the proposal I was given (with a second identical server fro >> backup using log shipping): >> ========================= >> IBM X3650 (This is a 2U server, can hold 8 Drives) >> 2 x QC Xeon E5450 (3.0GHz 12MB L2 1333MHz 80W) >> 8 x 2GB RAM (16GB total) >> 2.5" SAS Hotswap >> ServeRAID-8K SAS Controller >> 8 x 73GB 15K 2.5" SAS Drive >> CD/DVD Drive >> Remote Supervisor Adapter II Slimline >> Redundant Power >> 4 Year, 24x7 2hour support/warranty >> >> ========================= >> >> I would like specialists advices. >> >> If you need additional details, please let me know. >> >> Thanks in advance for your help >> >> Thank you >> >> Pascal >> >> > >
On Wed, 12 Mar 2008, Mark Lewis wrote: > One question that's likely going to be important depending on your > answers above is whether or not you're getting a battery-backed write > cache for that ServeRAID-8K. Apparently there's a 8k-l and an regular 8-k; the l doesn't have the cache, so if this one is a regular 8-k it will have 256MB and a battery. See http://www.redbooks.ibm.com/abstracts/TIPS0054.html?Open#ServeRAID-8k From Pascal's description of the application this system sounds like overkill whether or not there's a cache. For scaling to lots of small requests, using things like using connection pooling may end up being more important than worring about the disk system (the database isn't big enough relative to RAM for that to be too important). -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith wrote: > On Wed, 12 Mar 2008, Mark Lewis wrote: > >> One question that's likely going to be important depending on your >> answers above is whether or not you're getting a battery-backed write >> cache for that ServeRAID-8K. > > Apparently there's a 8k-l and an regular 8-k; the l doesn't have the > cache, so if this one is a regular 8-k it will have 256MB and a > battery. See > http://www.redbooks.ibm.com/abstracts/TIPS0054.html?Open#ServeRAID-8k It is the solution with RAM and battery. > >> From Pascal's description of the application this system sounds like > overkill whether or not there's a cache. For scaling to lots of small > requests, using things like using connection pooling may end up being > more important than worring about the disk system (the database isn't > big enough relative to RAM for that to be too important). > I agree with what you are saying. We are using Java with a pool of connections to access the DB. Today our database is really small compared to the RAM but it may evolve and even will probably grow (hope so which would be a good situation). Thanks for your advices/remarks.
On Fri, Mar 14, 2008 at 1:24 PM, Pascal Cohen <pcohen@wimba.com> wrote: > I agree with what you are saying. We are using Java with a pool of > connections to access the DB. Today our database is really small > compared to the RAM but it may evolve and even will probably grow (hope > so which would be a good situation). > Keep in mind that differential cost between a mediocre and a good RAID controller is often only a few hundred dollars. If that means you can scale to 10 or 100 times as many users, it's an investment worth making up front rather than later on.