From: Peter Arremann <loony@xxxxxxxxxxxx>
> 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@xxxxxxxx
