From: Peter Arremann <loony at loonybin.org> > Then the first AnandTech benchmark article > (http://www.anandtech.com/IT/showdoc.aspx?i=2447) is exactly what you want to > look at. Huge amount of memory (when compared to the size of the database > running on the system) on a 64bit linux kernel... > We're doing the same for one of our apps called IPM. Its a PHP app running > against a quad opteron with 16GB ram. Heavy on network IO (during business > hours its rare that we don't saturate the main 100mbit link) but little disk > activity. DB size is about 2.5GB and we end up with a couple of gig for disk > buffers. CentOS4 of course... anything specific you're looking for? I think I know where you and I are differing. When you talk about "heavy [network] IO," you refer to SQL-based applications over a primary 100mbit link. In reality, the MCH bottleneck isn't much of an issue here. When I talk about "heavy [network] IO," I'm typically referring to less intelligent applications (e.g., NFS or other "raw block" transfer) over one or even multiple GbE, possibly FC-AL links (possibly direct IP, link agregated IP, maybe 1 out-of-band channel, or possibly to a Storage Area Network, SAN). Although I have built financial transaction systems that have required GbE as well as engineering. I guess this is where my terminology really differs. A lot of people are using Linux for Internet services. I've typically been using Linux for high-performance LAN systems -- both "raw block" as well as intelligent applications. My Internet connection is not my bottleneck. BTW, despite popular thought, this can be done quite inexpensively when needed. It really all depends. But in these applications, definitely _not_ going to see Opteron doing much for you over Xeon. Let alone not when running Linux or Windows (Solaris might be another story though). -- Bryan P.S. Just a follow-up, _never_ assume you're the only EE in a thread. [ Let alone don't assume I haven't designed memory controllers as part of my job, beyond just my option in computer architecture. That's why I had to "give up" in the other thread, because everytime I try to explain something, you are going to a very simplified path and I have to stop and explain it (e.g., the fact that IA-32/x86 _can_ address beyond 4GiB). ] -- Bryan J. Smith mailto:b.j.smith at ieee.org