If we disabled the stock SM filtering plugin is they an alternative
we could use with SM?
Don't use the Filters plugin if you have any other alternative.
Server-side filtering at delivery time will always be faster than doing it
in PHP at login. If you use Cyrus IMAPd, use SIEVE. There's even a
> If we disabled the stock SM filtering plugin is they an alternative
> we could use with SM?
Don't use the Filters plugin if you have any other alternative.
Server-side filtering at delivery time will always be faster than doing it
in PHP at login. If you use Cyrus IMAPd, use SIEVE. There's ev
Hi all,
>- make *sure* you are *not* using the filtering plugin that comes
> stock with SM; it is highly inefficient to filter mail using PHP
We have a similar issue at our site, concurrency is around 100 users at
any one time.
I've noticed that our inital login speed is slowed down hugely
I did, but no change:
bash$ sysctl -w kern.maxfiles=65536
kern.maxfiles: 12328 -> 65536
bash$ sysctl -w kern.maxfilesperproc=32768
kern.maxfilesperproc: 11095 -> 32768
Output of top:
last pid: 53114; load averages: 0.53, 0.25, 0.12up
9+20:05:09 15:41:11
78 processes: 2 running, 76 sle
Since you're running FreeBSD, my solution may not work for you, but ...
check your file handles!
Viren Patel wrote:
I have been following this thread with great interest.
Here are my 4 cents. We have a webmail setup as follows:
Dual AMD Athlon MP 2400 w/ 1 GB RAM
RAID 5 (3 ATA133 7200 RPM d
More thoughts that may or may not have made it into this thread (sorry,
not reading as closely as I should be...):
- try disabling server side threading if it was even on (and
supported) in the first place
- make *sure* you are *not* using the filtering plugin that comes
stock with SM; it i
Hello Lesli,
On Monday, November 15, 2004, Lesli St. Clair wrote...
> I've been struggling with SquirrelMail for two months. At about 300
> users, the CPU is maxed out and the load average on a dual-Ghz CPU Sun
> machine climbs into the 80s.
[..]
I've been reading most of this thread over, and f
> When a visitor sucessfully logs in SM causes the IMAP server to do a lot
> of work. Fist is last to parse the inbox for message and get the first
> pages worth. At the same time it has to parse all the folders to check
> for unread message in the folders so it can make us the side display.
> Non
> Getting even more OT, but I'm curious, John, to hear how you have
> architected your machines. Please do divulge. Do you actually run SM
> on more than one box? If so, how do you share sessions? Data/attach
> dirs? NFS? Do you have a 'real' load balancer? etc...
We use LVS to load balance
John Madden said:
>> So the load problem is caused by whatever SM does at login--the first
>> mail pull? caching? sorting?
>
> And PHP session creation. Not to beat the already-mamed horse, but have
> you tried out the database-based sessions yet?
>
> John
>
>
>
>
> --
> John Madden
> UNIX Systems
I have been following this thread with great interest.
Here are my 4 cents. We have a webmail setup as follows:
Dual AMD Athlon MP 2400 w/ 1 GB RAM
RAID 5 (3 ATA133 7200 RPM disks with 8MB cache)
Adaptec 2400 ATA RAID controller
Linksys Gigabit NIC (gigabit uplink to router ;-))
Fr
Getting even more OT, but I'm curious, John, to hear how you have
architected your machines. Please do divulge. Do you actually run SM
on more than one box? If so, how do you share sessions? Data/attach
dirs? NFS? Do you have a 'real' load balancer? etc...
--
- Turck MMCache is insanely faster than PHP Accelerator (PHP-A), if
that's what you had been using:
http://turck-mmcache.sourceforge.net/index_old.html
Intriguing ... Would you not agree that "insanely" is overselling its
performance over PHP-A? Reading the stats on that page I come up with a
~mar
> I think you may need to dig deeper into the whole authentication
> process, but I don't think that SM is the bad guy here. I think your
> issue is between IMAP and LDAP.
I disagree. That IMAP/LDAP work happens *every time a user clicks,* not
just on the initial login. Something else is going o
> So the load problem is caused by whatever SM does at login--the first
> mail pull? caching? sorting?
And PHP session creation. Not to beat the already-mamed horse, but have
you tried out the database-based sessions yet?
John
--
John Madden
UNIX Systems Engineer
Ivy Tech State College
[EMA
om: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lesli
St. Clair
Sent: Tuesday, November 16, 2004 1:03 PM
To: Peter P. Benac
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [SM-USERS] Giving up on SM because of CPU and load issues
Peter P. Benac wrote:
> Sorry for picking this t
Peter P. Benac wrote:
Sorry for picking this thread up late, but I was curious if you have run any
performance monitoring tools on this box or are you just assuming the SM is
the culprit. At the very least have you run and monitored TOP on this
machine to see who your top processes are.
I'm using
Sorry for picking this thread up late, but I was curious if you have run any
performance monitoring tools on this box or are you just assuming the SM is
the culprit. At the very least have you run and monitored TOP on this
machine to see who your top processes are.
My mail server is on a E-220-R d
Thanks, but we use ldap (on another box) for logins.
SqM wrote:
I ran into something similar with high load on a web server
hosting homepages.. Load in the 40's..
If you have the user data base in NIS.. (i.e. passwd)
Make sure that you do not have it in the password file as well..
Or.. Make sure th
p dont think said:
> Just skimmed this thread and have two thoughts:
>
>
> - Turck MMCache is insanely faster than PHP Accelerator (PHP-A), if
> that's what you had been using:
> http://turck-mmcache.sourceforge.net/index_old.html
Intriguing ... Would you not agree that "insanely" is overselling
I ran into something similar with high load on a web server
hosting homepages.. Load in the 40's..
If you have the user data base in NIS.. (i.e. passwd)
Make sure that you do not have it in the password file as well..
Or.. Make sure that the search order is NIS -> PASSWD file
If the password fil
Just skimmed this thread and have two thoughts:
- Turck MMCache is insanely faster than PHP Accelerator (PHP-A), if
that's what you had been using:
http://turck-mmcache.sourceforge.net/index_old.html
- SM 1.5.1 has better header caching mechanisms that might lighten the
load a bit
---
On Mon, 15 Nov 2004, John Madden wrote:
> > That surprises me. We aren't a Linux shop--yet--and I'm not sure I'm
> > willing to start setting up Linux boxes will-nilly for this. I'm curious
> > why Intel would be better than sparc, though.
>
> Try it out on a [higher-end] Desktop PC -- the per
Lesli St. Clair said:
> I can put it on a dual or quad CPU sun box, with plenty of RAM. I have
used both PHP acceleration and the IMAP proxy. On my current system,
users login about every 12 seconds, on average, during busy periods. We
use iPlanet 5.2 for IMAP (which does not do server side sorting
On Mon, 15 Nov 2004 17:05:55 -0500, Lesli St. Clair <[EMAIL PROTECTED]> wrote:
> Not a larger percentage, no.
>
> I just did an experiment with the load testing software.
>
> I had it run a 500-user session with users logging in 5 seconds apart.
> The 4-CPU machine didn't go crazy--but the CPU wa
Not a larger percentage, no.
I just did an experiment with the load testing software.
I had it run a 500-user session with users logging in 5 seconds apart.
The 4-CPU machine didn't go crazy--but the CPU was used up pretty well
and the LA hit about 8-12.
Then I changed the parameters to 500 user
Always from source! And yes, fresh php, too. It was an untouched machine
that hadn't been used for anything else.
Ralf Hildebrandt wrote:
* Lesli St. Clair <[EMAIL PROTECTED]>:
I thought of that, but I tried a fresh install of apache 2.x
From source?
What about PHP?
begin:vcard
fn:Lesli St. Cl
> Just as an example: I'm simulating 500 users on this 4-CPU sparc. Here's
> the top output:
> 166 processes: 159 sleeping, 3 running, 4 on cpu
> CPU states: 12.7% idle, 82.7% user, 4.7% kernel, 0.0% iowait, 0.0%
What does it look like if you simulate, say, 10 users? Do your httpd's
end up co
* Lesli St. Clair <[EMAIL PROTECTED]>:
> I thought of that, but I tried a fresh install of apache 2.x
>From source?
What about PHP?
--
_
Charité - Universitätsmedizin Berlin
_
Ralf Hildebrandt
I thought of that, but I tried a fresh install of apache 2.x and the
beta of the next release of SM, and saw the same thing, at least insofar
as apache using more than its share of the cpu. Really, this whole thing
is bizarre! I have an identical model machine running as a spamtrap/AV
machine,
* Lesli St. Clair <[EMAIL PROTECTED]>:
> Fresh install of apache 1.3x, SM, and mysql, but the same revs etc.
Maybe a bug in the software? I've seen that on RH systems -- apache
starts hogging the cpu.
--
Ralf Hildebrandt (i.A. des IT-Zentrum) [EMAIL PROTECTED]
Charite - Universitätsmed
> It doesn't happen with iPlanet's built in webmail, but we wanted
> something with more features. Also, I wanted something that didn't need
> to be rebranded everytime I apply an email system hotfix. That's the
> downside of all-in-one solutions like iPlanet/SunOne.
Yeah. AFAIK, iplanet's client
Fresh install of apache 1.3x, SM, and mysql, but the same revs etc.
Ralf Hildebrandt wrote:
* Lesli St. Clair <[EMAIL PROTECTED]>:
I was absolutely convinced that something was misconfigured when I saw
the LA over 80. So I moved it to anther, identical machine and got the
same thing. Then I moved
* Lesli St. Clair <[EMAIL PROTECTED]>:
> I was absolutely convinced that something was misconfigured when I saw
> the LA over 80. So I moved it to anther, identical machine and got the
> same thing. Then I moved it to the 4-CPU monster.
Installed with the same software?
--
Ralf Hildebrandt (i.
I was absolutely convinced that something was misconfigured when I saw
the LA over 80. So I moved it to anther, identical machine and got the
same thing. Then I moved it to the 4-CPU monster.
The ONLY problem was CPU. RAM, swap, disk I/O all were taking a nap.
Ken Brush wrote:
On Mon, 15 Nov 200
> That surprises me. We aren't a Linux shop--yet--and I'm not sure I'm
> willing to start setting up Linux boxes will-nilly for this. I'm curious
> why Intel would be better than sparc, though.
Try it out on a [higher-end] Desktop PC -- the performance may change your
mind. Sun is hyping Solaris
John Madden wrote:
First off, I'd recommend not using Sun hardware for this sort of thing -
mid-range intels will blow the doors of of sparcs for this sort of
processing. Secondly, we have to consider how this load testing software
works -- what, exactly, is it doing within SM? We support about
I suspect it is the SM/iPlanet combo. But I can't change our email
infrastructure just for a webmail interface. I'm disappointed, because I
do like SM.
Norrin Radd wrote:
Lesli st. Clair,
Sorry to hear about your pain and suffering. Although
I have only fractions of expertise of the much more
qu
Lesli st. Clair,
Sorry to hear about your pain and suffering. Although
I have only fractions of expertise of the much more
qualified people on this list and My load is only
about half of yours, are you married to iPlanet IMAP?
I use Courier and it seems to be holding up nicely,
although we only h
39 matches
Mail list logo
