On Friday 15 September 2006 02:02, Amos Shapira wrote: > On 15/09/06, Shlomi Fish <[EMAIL PROTECTED]> wrote: > > Hi Amos! > > > > Gmail does not quote the last line of the original message before the > > response. As a result, your message is messed up. > > I switched to plain text mode now. Hope it'll help. > > I also reply only to linux-il since this is the only mailing list on > which I'm subscribed (and cross-posting is usually against netiquette, > and most relevant people are on linux-il anyway). >
OK. > > > > 2. We'd like to configure a 2 GB swap partition. However, I need the > > > > RAID array to back up the data on one of the 2 GB swap partitions of > > > > the SCSI disks. However, the RAID array is currently completely > > > > inactive, and we need > > > > to activate it. Lior, can you please step on it? > > > > > > As a last-resort fall-back line before system crash - maybe consider > > > using dynamic swap space allocators like swapd or swapspace: > > > > > > http://packages.debian.org/unstable/admin/swapd > > > http://packages.debian.org/unstable/admin/swapspace > > > > If we have 3 GB or so of memory, then I don't suppose we'll need more > > swap. > > 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. > 2. I suggested this as an extra precaution to be used when the only > other option is for the system to give up and start killing processes > or generally go south. OK. > > > > (the copyright file should usually point to the upstream site. It > > > appears that Eskimo already runs Sarge but these packages are not > > > available there - it's about time to upgrade to Etch. I didn't find > > > these packages in Backports). > > > > Etch... has Etch been stabilised yet? > > It's not officially stable but it's been practically usable for a long > time now. I have two such system now (my home and work desktops) and > they are superb. As far as I followed, already being supported by the > Debian Security Team so this part (which should probably be number one > on the list of production servers requirements) is covered. I see. OK. > > > > Do you have information on what's hogging the system's memory and for > > > what? Possibly a more scalable and stable way to handle the problem > > > should be to try to avoid or minimize the memory hog. > > > Usually when the system uses so much swap it's already crawling. > > > > Well, we recently switched from ezmlm to using sympa which has a daemon > > that consumes about 10% of the memory, and possibly some other things. > > 10% doesn't explain running out of memory. > 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. > > > > 64GB memory is going to be expensive. > > > > That's not what I meant sorry. What I meant was that the computer model > > could support up to at least 64 GB of memory in case we'll need to scale > > to this amount of memory in the future. > > If you have the money for it then go for it: > http://www.sun.com/servers/x64/x2200/ > other servers in this series offer pretty amazing redundancy options > (you can practically replace any part of the system except the chassis > without taking it down). > (disclaimer: I own SUNW shares) OK. Of course, Hamakor can make a plea for donations. > > From where I sit it looks like you are jumping too far ahead - a > mail+web server of this scale shouldn't require more than the 2-4Gb > you can put on your current system. By the time you'll get around to > actually take advantage of more memory the hardware scene might be > different and more importantly - hardware supporting this amount of > RAM will probably cost half or less than current prices. > > For your consideration. 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. > > > > As for the 500MHz it sounds indeed > > > poor but what's the CPU utilization like right now? What does it choke > > > on? > > > > Well, the machine seems to be responsive enough. But we may need more CPU > > to serve dynamic content. > > 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. 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]
