Re: Honesty needed...

2005-07-02 Thread Hannah Schroeter
Hello!

On Sat, Jul 02, 2005 at 11:04:34AM +0800, Jeffrey Lim wrote:
how about the mail store then? I suppose there'll have to be some
coordinated (and thread-friendly) back-end mail store in place for
these front-end mail servers (*i'm assuming simplistic load-balancing
here - at the tcp level, rather than at the application level, or
splitting via userid, so that the different userids are actually
assigned to different mailstores).

Splitting via userid would be the simplest thing. Developping
a robust distributed mail storage system is more complicated
(been there, done that). However, for that you don't need
thread-friendly. The thing I developped (sorry, closed source)
consists of a few processes per node only, perusing select()
heavily for multiplexing. Ok, there's support for pseudo-parallel
I/O, using *fork*ed I/O helper processes and socketpairs.

But as said, doing such a thing is very complicated, but it
works quite ok in-between (after say 3 or 4 years of development),
supporting millions of users with about 80 nodes, capable of
supporting IMAP, too (with quite correct handling of IMAP's
\Recent-flag, too, which is a beast by itself).

-jf

Kind regards,

Hannah.



Re: Honesty needed...

2005-07-01 Thread Tobias Weingartner
I'm late to the game... but why not split the load over a number
of servers? Using carp for reduncancy, rdr/round-robin and/or hash,
you should be able to spread the load some.

--Toby.

On Wednesday, June 29, Jeffrey Lim wrote:
 On 6/29/05, Matt Juszczak [EMAIL PROTECTED] wrote:
  Just spoke with the boss.  My boss really wants to run SMP.  He's an
  ill-informed business man and thinks that a single 3 ghz with 4 gb RAM
  couldn't handle our mail server, which I believe it would have no problems
  at all doing.
  
 
 sounds like somebody who wouldnt know the difference anyway if u just
 went right ahead and *not* used smp, and told him otherwise, doesnt
 it?
 
 I'm not saying outright that u should really give up smp - but this is
 an option for u.
 
 -jf
 
10,000 users isn't that many.
  Either way, if hes set on SMP, then I either need to go to another *BSD
  other than FreeBSD which wont have this problem (such as OpenBSD, although
  do you know whether or not OpenBSD's SMP can support Dual Xeon's?) or
  NetBSD.  Otherwise, I have to go to linux or windows which I really don't
  want to do at all.
  
  Thanks again for your help.
  
  Regards,
  
  Matt



Re: Honesty needed...

2005-07-01 Thread Bob Beck
I concur. mail load is ideally suited for dividing up
amongst multiple machines (with then multiple i/o busses, etc. etc.).

I far prefer this method to the one big machine method.

-Bob


* Tobias Weingartner [EMAIL PROTECTED] [2005-07-01 10:11]:
 I'm late to the game... but why not split the load over a number
 of servers? Using carp for reduncancy, rdr/round-robin and/or hash,
 you should be able to spread the load some.
 
 --Toby.
 
 On Wednesday, June 29, Jeffrey Lim wrote:
  On 6/29/05, Matt Juszczak [EMAIL PROTECTED] wrote:
   Just spoke with the boss.  My boss really wants to run SMP.  He's an
   ill-informed business man and thinks that a single 3 ghz with 4 gb RAM
   couldn't handle our mail server, which I believe it would have no problems
   at all doing.
   
  
  sounds like somebody who wouldnt know the difference anyway if u just
  went right ahead and *not* used smp, and told him otherwise, doesnt
  it?
  
  I'm not saying outright that u should really give up smp - but this is
  an option for u.
  
  -jf
  
 10,000 users isn't that many.
   Either way, if hes set on SMP, then I either need to go to another *BSD
   other than FreeBSD which wont have this problem (such as OpenBSD, although
   do you know whether or not OpenBSD's SMP can support Dual Xeon's?) or
   NetBSD.  Otherwise, I have to go to linux or windows which I really don't
   want to do at all.
   
   Thanks again for your help.
   
   Regards,
   
   Matt
 

-- 
Bob Beck   Computing and Network Services
[EMAIL PROTECTED]   University of Alberta
True Evil hides its real intentions in its street address.



Re: Honesty needed...

2005-07-01 Thread Jeffrey Lim
how about the mail store then? I suppose there'll have to be some
coordinated (and thread-friendly) back-end mail store in place for
these front-end mail servers (*i'm assuming simplistic load-balancing
here - at the tcp level, rather than at the application level, or
splitting via userid, so that the different userids are actually
assigned to different mailstores).

-jf

On 7/2/05, Bob Beck [EMAIL PROTECTED] wrote:
 
 
 I concur. mail load is ideally suited for dividing up
 amongst multiple machines (with then multiple i/o busses, etc. etc.).
 
 I far prefer this method to the one big machine method.
 
 -Bob



Re: Honesty needed...

2005-06-28 Thread Joe .
Can you live with just one processor? You would probably have much
better luck with SMP disabled.

Joe

On 6/28/05, Matt Juszczak [EMAIL PROTECTED] wrote:
 Hi all,
 
 Some of you have read my posts from the previous few days but I am really
 stuck right now.  Sorry if this is repeated information for anyone.
 
 We're running FreeBSD at work on our main mail server, which is now
 crashing 2 times per day.  I need to find a new solution soon, or I could
 risk losing my job which would really stink.
 
 The machine itself is fine, and I know this because 1) I've tested the
 memory and 2) This problem I am experiencing is occuring on more than one
 machine.
 
 OpenBSD is known for its stability, and I'm wondering what everyone's
 opinion on stability would be with a SuperMicro Dual Xeon 3.06 ghz (SMP)
 and 4 GM RAM, running postfix with LDAP and 10,000 users.  If I can get a
 stable system up and running I'll be really happy.
 
 Apparently, there is something called a ttwakeup bug and there's some SMP
 code problems in FreeBSD 5.4 that wasn't apparent in 4.11 (which is why
 that runs stable for me) causing all these problems.  I would hope that
 with the branch off of OpenBSD these problems wouldn't exist in the OS.
 
 Any responses would be appreciated :)
 
 Regards,
 
 Matt



Re: Honesty needed...

2005-06-28 Thread Matt Juszczak

Either, I think in general SMP is tough to get stable. People with
more experience will hopefully reply and explain in more detail. For
now I, personally, would disable smp on freebsd just to keep it
stable.



I just dont know if this will keep it stable or not.  Others are reporting 
that the bug is in ttwakeup and the other is that its a bug in IPF, which 
I currently use


Thats why I'm at a dilemma right now.  Do I keep things as they are, turn 
SMP off on FreeBSD 5.4, and risk problems in the future?  Or do I switch 
to OpenBSD now, hope it works, and have a stable solution while FreeBSD 
becomes more stable.




Re: Honesty needed...

2005-06-28 Thread Rogier Krieger
On 6/28/05, Matt Juszczak [EMAIL PROTECTED] wrote:
 My boss really wants to run SMP.  He [...] thinks that a single 3 ghz
 with 4 gb RAM couldn't handle our mail server [...]

To avoid making CLM's, you should realise these lists are archived indefinitely.

If things are crashing twice a day and you believe SMP is the culprit,
disable it to get your immediate problem out of the way. That way
you'll have the time to properly test another platform to see whether
it does perform - with SMP as you so desire - the way you want it to.

If your mail server comes down crashing due to CPU shortage, the worst
you've done is that you have a problem that is about as bad as the one
you had originally: a crashing mail server.

And of course, that's just my take on things.

Cheers,

Rogier

-- 
If you don't know where you're going, any road will get you there.



Re: Honesty needed...

2005-06-28 Thread Matt Juszczak

According to
http://www.freebsd.org/security/
the current estimated EOL for 4.11 is January 31, 2007

That said, since you think IPF is causing problems, have your tried disabling 
IPF and running either ipfilter or PF  (or doing the filtering on a dedicated 
firewall box)?


--Matt



Yep, I will try that.  Anyway, I appreciate all of your help, I think this 
discussion has veered off from my original intentions and I think it 
should be taken off list since it is now considered O.T.


Again, I'm appreciate all your input and I'm going to continue my research 
and see where it goes.


Regards,

Matt



Re: Honesty needed...

2005-06-28 Thread Matt Rowley

According to
http://www.freebsd.org/security/
the current estimated EOL for 4.11 is January 31, 2007

That said, since you think IPF is causing problems, have your tried 
disabling IPF and running either ipfilter or PF  (or doing the filtering on 
a dedicated firewall box)?


--Matt


--On Tuesday, June 28, 2005 15:10:16 -0400 Matt Juszczak [EMAIL PROTECTED] 
wrote:



What's wrong with FreeBSD 4.11? You said it's stable for you. OpenBSD is
going to be a big change for you on short notice with little testing.
Everyone says the 4.x branch is much more stable than the 5.x branch
anyway.



It is, but its unsupported.  If I go back to 4.11, within 6 months I
would have to go back to 5.x anyway.  I'd rather not waste time doing
that.




Re: Honesty needed...

2005-06-28 Thread Vjacheslav Borisov
We're running FreeBSD at work on our main mail server, which is now 
crashing 2 times per day.  I need to find a new solution soon, or I 
could risk losing my job which would really stink.


http://www.dragonflybsd.org/

From Wikipedia, the free encyclopedia.

In computing, the DragonFly BSD operating system is a fork of FreeBSD. 
Matt Dillon, a long-time FreeBSD and Amiga developer, started work on 
DragonFly BSD in June 2003 and announced it on the FreeBSD mailing lists 
on 16 July 2003.


Dillon started DragonFly in the belief that the methods and techniques 
being adopted for threading and SMP in FreeBSD 5 would lead to a poorly 
performing system that would be very difficult to maintain. He sought to 
correct these suspected problems within the FreeBSD project. Others in 
the project did not think highly of his ideas, which is among the 
reasons his ability to directly change the FreeBSD code was revoked. 
Despite this, the DragonFly BSD and FreeBSD projects still work together 
contributing bug fixes, driver updates and other system improvements to 
each other.


Intended to be the logical continuation of the FreeBSD 4.x series, 
DragonFly is being developed in an entirely different direction from 
FreeBSD 5, including a new Light Weight Kernel Threads implementation 
and a light weight ports/messaging system. Many concepts planned for 
DragonFly were inspired by the AmigaOS.