On Saturday 16 September 2006 02:43, Amos Shapira wrote: > 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.
Yes we do. We probably ran out of memory. > 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? It's not available for Sarge. > > > > 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, I'll see. > > 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. Right. > > > 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. Hmmm.... I'm pretty sure 4 GB will quickly become inadequate. And like I said, we don't need 64 GB now, but we may need it in the future. > > > > 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. Hmmm... the purpose of Eskimo is to serve the community. We do that by setting up web and other Internet services there. At the moment, Eskimo can handle it pretty well, albeit one time when a PostNuke page got slashdotted, it ended up completely disabling Apache (but we're not sure why). We don't have too many users, and most of them are administrators who set up admin tasks there. > > 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. It is a production system. Regards, Shlomi Fish --------------------------------------------------------------------- Shlomi Fish [EMAIL PROTECTED] Homepage: http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. ================================================================= 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]
