Re: Server Hardware Configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Performance questions are terrible to answer because 
we all use our systems in different ways. Here's my 
2 bits for what they're worth.

> The idea behind the first is to keep the
> entire database in memory, by way of the disk cache.

What you describe is a real-time system. Does your 
requirements call for real-time performance ?
Remember that performance from memory is much more 
expensive than disk i/o (at least up to a certain point).

> A web interface allows people to accept, or (usually) 
> discard the trapped messages.

IMHO this means no real-time.

> So, most data is write once, read at most once, delete.

This is not exactly an optimum case for caching. I would
suggest thinking really hard before going for an all memory
solution. From what you write I would suggest a firm focus 
on disc i/o.

But in the end the best person to ask really is yourself.
How is the system loaded ? Is disk i/o maxed out ?
Are the cpu's overload'ed ? Is it paging like cracy ?

I suggest looking at your current bottleneck first.
It's likely to be the most cost-efficient route out.

Could also be some magic pg tunning tricks out there
you've missed. Who knows. I spent two weeks on google
and tuning last year with amazing results.

Also remember that pg collects performance statistics. 
Those will help a lot in finding out what's really 
going on. This can also reveal where the database is 
being used inefficient by the application, missing 
index'es etc.

At present I'm running a 130gig base on a 4gig mem 
four way 6650 with an external (fiber channel) raid 
5 box.

I admit the load is not that terrible or time sensitive
(web self-service) but the performance is still pretty
hot. The requests are very scattered so i/o is key. My
cache benefit is mostly from the index's.

Good luck in your quest for "bang per buck" ;-)

Cheers,

John

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
       message can get through to the mailing list cleanly

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux