Re: Intel EM64T vs. Opteron
On 14 Oct 2005, at 8:06 am, mike wrote: Basically, I'd be looking at an Intel 830D (3.0ghz, dual-core, EM64T) processor-based system, with 1 gig of ram and SATA HD vs. a single-core Opteron 1.8ghz (or a dual-processor NOT dual-core Opteron 1.8ghz) system, same HD and same RAM. Has anyone had the opportunity to benchmark this, or have any real experience with changing the underlying platform? Our experience with IBM HS20 blade servers shows the 2.4 GHz Opteron blows the 3.2 GHz EM64T out of the water on our bioinformatics codes, which are predominantly limited by integer performance and memory bandwidth. And uses a lot less power (this is significant when you have about 1000 processors in the cluster!). No more EM64T for us, at least for a while. One thing to be careful with, if it's a dual CPU opteron machine that you're benchmarking, is that you need a really up to date kernel that gets the NUMA topology right; our initial benchmarks were disappointing, and it turned out that the the numa topology stuff in the kernel was exactly backwards, so every process was always accessing memory local to the other CPU. This has been fixed in recent kernels. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice on hardware
On 23 Aug 2005, at 10:53 pm, Elaine Tsiang YueLien wrote: On Tue, 2005-08-23 at 16:16 -0400, Lennart Sorensen wrote: A server chipset with multiple cpus on the other hand, with sata and all, may be a bit harder to get fully working. I haven't tried. I am a little nervous about that. I have scanned the last few months of this list - there does not seem to be any problem in principle with getting amd64-k8-smp itself going, only with drivers or packages to go with it. Is there no data point for Sarge on such a system? The vendors are bundling Red Hat and Suse licenses. I hope to get help on this list if I can't get all the wheels to turn. In return, I will certainly share all the trials and tribulations of such an adventure. We're currently trying Debian on an HP blade server with quad dual- core Opteron CPUs. I haven't heard any howls of pain from my colleagues yet - it just seems to work, at a first impression. Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mysqld on debian-amd64/testing crashing with signal 11
On 23 Jun 2005, at 16:09, Ed Fisher wrote: Hi folks, I've been experiencing a problem with mysql-server-4.1 on two different amd64 machines, running two different versions of the package. The errors in the log are similar to http://lists.debian.org/debian- amd64/2005/03/msg00481.html -- but I don't know if the source of the segfault is a client QUIT command. I don't think it is. It's occurred about 10 times in the past 7 days, at seemingly random intervals. I switched to a second server yesterday afternoon, and less than 6 hours later mysqld on the new server segfaulted. The servers get about 300qps on average, about half updates and half selects. I turned on query logging after about the third day, despite the performance hit, and couldn't see any abnormal queries in the logs. Presumably whatever query that causes the segfault, though, wouldn't get logged. Since the mysqld in debian doesn't seem to output a backtrace on crash, I can't use that for further debugging. I'm open to any suggestions, and please let me know if there's any further information I can provide. I'd try the debug build from MySQL themselves; this should give you more information about the source of the crash (if it happens again with their build). Either way, this will help you give more info to the Debian MySQL maintainer; if the bug is not reproduced with MySQL AB's own build, then it's likely a problem with the Debian build, specifically, which is useful information. If the bug is reproduced on the MySQL AB build, then you can try the latest MySQL AB build (4.1.12a, I think) and see if that fixes it. If so, that again is useful information for the Debian maintainer. If it doesn't fix it, you can then file a bug report directly with MySQL AB, and then file one with the Debian package that references the upstream bug report. Bugs in MySQL are not uncommon - I found a pretty basic one in MySQL 4.1.8 a few months back, and used the above process; reported the bug to MySQL AB, and their fix emerged in 4.1.10, so they weren't too slow. To be honest, on our machines at work, I don't use the Debian MySQL packages, except for client-only machines. I prefer to have more direct control over the version of MySQL the servers are running... Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
