On 16/09/06, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> 1. I got the impression from your ogirinal post that the root cause
> for the reboot was running out of memory. Isn't it so?
Well the system became unresponsive. We don't know why, but we guess it was
due to lack of memory.
I understand that. It's just that you don't have any evidence as to
what happened. How about running things like collectd
(http://packages.debian.org/testing/utils/collectd) to get a better
feel of what's happening on the system?
> Also first thing I found about Simpa was this:
> http://www.sympa.org/doc/html/node2.html#SECTION00220000000000000000
> (tuning)
I couldn't find any information in this document about *how* to tune.
It's a promo-like page. My point being that this software can be tuned
and tweaked (at least according to this page).
OK. Of course, Hamakor can make a plea for donations.
Such a plea should usually explain and convince potential donors why
exactly such hardware is necessary and is the best use of Hamakor's
money.
Yes, but I don't know how much we'll need to scale in the future. I figure we
can get a Xeon or Athlon-based chip which support up to 64 GB of RAM, but are
still 32-bit.
That's a difference between an excellent system manager and others -
doing such a job properly means to find the requirements of the
software that you plan to run on this hardware then adjust
accordingly. Just throwing lots of silicon at a problem without
understanding your precise requirements has a chance that you'll still
won't solve your problem (because you just guessed your requirements
and invested in the wrong kind of hardware) and leave you with less
money for the right stuff.
> So the current CPU resource is sufficient for CURRENT requirements? I
> got the impression you are trying to prevent the system from crashing
> because of some resource shortage, isn't it? If not then what's this
> discussion about? "Eskimo is a 500MHz Pentium III, let's replace it"?
> If it works then why break it?
Well, it works but like I said, we could always use a faster box for
PHP/Perl/MySQL/etc.
That's called "to plan" - decide what you intend to run on this
hardware beforehand and plan accordingly, with an upgrade path in
mind.
For a start - maybe setup some "release cycle" where relevant users
put up an explanation of what they want to install on the server in
the next, say, 3-6 month, assess the impact of that software on the
server (disk, memory, cpu, network, security, database kinds, maximum
response times, access requirements, uptime requirements, reliability
requirements, failover, "business case" (why is this software a useful
thing to run on this server), whatever) then merge these requirements
into a full picture of what's expected from the system by its users
then decide what, when and how to do things so the requirements are
met. Wash, rinse, repeat.
Many times during this planning process users will discover that they
can use an already existing component on the system, or that they can
cooperate with other user's requirements, or that their requests are
unreasonable or other things.
BTW - it's supposed to be a production system (as far as I know) -
users should test and experiment on other systems and when they know
what to expect from the software they want on this server they can
start the request process.
Cheers,
--Amos
--
"Military justice is to justice what military music is to music"
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
