On 2006.5.12, at 08:54 PM, Mike Schienle wrote:
On Fri, May 12, 2006 7:40 am, Mike Schienle wrote:
On Fri, May 12, 2006 7:05 am, Joel Rees wrote:
On 2006.5.12, at 10:01 AM, Mike Schienle wrote:
Hi all -
I just installed an Intel Mac Mini as a replacement for a dual 1.8
GHz
G5 at
my colocation place a couple days ago.
Can I ask a silly question in public, or would off-list be more
appropriate?
I thought that would raise an eyebrow :-)
Heh. Some trolls, at any rate, are not evil.
The G5 began having stability problems. It would stop authenticating
users
(email, ftp, logins, etc. would fail, but web server would continue)
after
anywhere from 2 to 24 hours.
My instant reaction to that would have been putting a stripped-down
whitebox running OpenBSD as a logging firewall between the G5 and the
'net, to check for attacks on the mail and ftp subsystems. Attempts to
install a trojan for the wrong processor might have been causing DOS on
the attacked services?
(I should check whether OpenBSD has drivers for IP over firewire or for
the USB to ethernet converters. If so, a Mini might do as well as a
whitebox with two NICs.)
I have two internal disks, 80 GB for OS and 250
GB for DB and web sites, and two external disks that are essentially
backups
for the internals (all 7200 RPM). I ran disk checks on all of them. I
cloned
internals to externals one at a time and had the exact same issues.
After many
attempts to hunt down the root cause (from launchd to securityd and a
few
other areas), it was time for stabs in the dark. I replaced the OS on
the
external, which was an upgrade from 10.3.x to a fresh install of
10.4. That
actually made things worse, it went from failing to authenticate to
complete
lockups within a few minutes, so back to the original setup thanks to
being
able to shuffle things around with the spare disks.
Could be an unrelated problem?
The next attempt was to start swapping/rotating RAM modules (I had
recently
gone from 1.25 GB to 4 GB), to see if one was flaky. No change. The
current
guess is a problem with the power supply. At this point I just needed
to put
something stable in place and fix the problem behind the scenes. As
soon as
that happens I expect to put the G5 back.
And here I was thinking that someone in your organization had requested
the G5 for the art department. ;:-/
Another swag might be the CPU or the heat sink?
I'm definitely happy with the Intel (dual core) Mac Mini so far.
Database
access is about 15% slower for a couple long queries (20+ minutes),
which I'm
assuming is because they went from a FW800 attachment to FW400,
though it
might be because of the internal Mac Mini disk being a 5400 RPM
laptop drive.
The mysql executable is on the internal drive, but the data lives on
the
external drive.
Yeah, the notebook grade disk will slow the thing down, about 15% would
not be unexpected. RAM reduction will tend to have more drastic effects
when it has effects. I'm not familiar enough with FW400 to hazard a
guess, although I have a gut feeling the difference is not that big
unless there's constant bulk (>100MB) raw data motion.
20 minutes is a long query, indeed. I'd be tempted, once you have the
G5 back up, to keep the Mini on-line and run the DB on the one and the
web server on the other.
Actually, the data was on the internal 250 GB disk on the G5, rather
than the
external FW800 drive. Now it's on the external 250 GB disk attached
via FW400.
The query uses about 30 fields from 8 joined tables to pull out 200 KB
from 19
GB.
Mike Schienle
One reason I was interested, if you were planning to keep the Mini on
line, I'd be interested in what strategies you have for wear and tear,
my experience being that notebook-grade disks running full-time tend to
burn out after about a year.
I have my personal web site on my old clamshell iBook, and it runs a
dynamic DNS client every ten minutes via cron. That basically keeps the
disk spinning constantly. Burned out a drive last year, and I'm worried
it will burn out a drive this year. So I'm thinking of putting the
client on a RAM disk, although, since I wrote the client in perl, I
suspect that I'd then have to copy perl itself to the RAM disk as well.
Another thought would be, since I really don't need it to run exactly
at a specific time, to simply keep the client process running in a
sleep loop.
