I have heard of any performance problems with my patch. People have reported really good perf. with thousands of users. Nobody has reported anything with radius auth. used at the same time. Not being able to test any other cases, e.g. local auth. and maildir, radius, and mbox, etc.. doesn't help you. Like Clifton said, check your stats. Watch vmstat statistics. Even strace some of the processes to see what calls they spend the most time in.
--Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] http://www.asteroid-b612.org "You find magic from your god, and I find magic everywhere" .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. On Tue, 20 Jan 2004, Clifton Royston wrote: > On Mon, Jan 19, 2004 at 03:47:38PM +0100, Bart Dumon wrote: > > i'm running qpopper 4.0.5 on linux (2.4.x) with maildir patch > > (0.12) and pam_radius for authentication. > > > > right now, i'm suffering from high cpu load averages once it's > > gets too busy the load will skyrocket to abnormal high values > > and the service will become unavailable untill it's restarted. > > this typically happens during peak times when we receive 15 pop > > sessions/sec. > > > > at first it thought it was radius related because i'm seeing the > > following error message during the peak times: > > > > Jan 19 14:07:41 xxx popper[13404]: pam_radius_auth: RADIUS server x.x.x.x failed > > to respond > > > > but even with a more performant radius, the problem persists, it > > looks like the radius errors are a consequence of the problem and > > not the real cause. > > everything is pointing in the direction of the amount of pop sessions > > whenever you get to the 13-14pops/sec barrier, qpopper seems to > > be giving up. it's not traffic related because the amount of traffic > > is higher outside the peak hours. > > Usually this kind of overload is due to many users having large > mailboxes (e.g. 30MB and up) in the old UNIX mbox format. In this > format, the file needs to be recopied to update the messages' status > when popped, which results in the POP sessions completely saturating > your disk I/O bandwidth. > > I have also seen some Radius daemons show a tendency to die under > this type of heavy load. > > I haven't seen reports of this with maildir format. However, what > you're describing is consistent with I/O bandwidth saturation. > > If you are saturating your disk bandwidth, you'll see a large number > of concurrent tasks waiting to run ("load" as shown by the uptime > command or xload) but a high proportion of idle time shown by vmstat. > At that point you'll need to try to figure out why all this bandwidth > is still going on even with maildir format; I don't use that patch, so > I can't help with troubleshooting it. > -- Clifton > > -- .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] http://www.asteroid-b612.org "You find magic from your god, and I find magic everywhere" .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
