[rt-users] CPU Wait Maxed Out

[Eriks Goodwin-Pfister]

I upgraded to 3.8.8 and all seems to be fine now.  :-)

I think that there were/are some user searches that were being used that were causing the overload.


----- Original Message -----
From: "Kenneth Marshall" <ktm at rice.edu>
To: "Eriks Goodwin-Pfister" <eriks at centritech.net>
Cc: "rt-users" <rt-users at lists.bestpractical.com>
Sent: Tuesday, June 1, 2010 11:12:36 AM
Subject: Re: [rt-users] CPU Wait Maxed Out

In versions prior to RT 3.8.8, certain searchs will result in the
use of a large amount of memory in the webserver process. You can
use a "graceful" restart of the apache server to reduce the size
of the process. Maybe an hourly cron job would do the trick?

Regards,
Ken

On Tue, Jun 01, 2010 at 10:57:41AM -0400, Eriks Goodwin-Pfister wrote:
> I deleted the mailq, redirected the address for the odd mailq entries
> to an alternate mailbox, etc.
>
> As for memory, I see from sorting "top" by memory usage that apache is
> the memory hog... Any idea what would cause this on an RT box?
>
>   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  2665 apache 15 0 207m 81m 3692 S 0.0 8.6 1:29.41 httpd
>  2387 apache 15 0 206m 78m 3692 S 0.0 8.3 1:44.80 httpd
>  2668 apache 17 0 206m 75m 3896 S 0.0 8.0 1:32.49 httpd
>  2496 apache 15 0 205m 70m 3880 S 0.0 7.5 1:12.07 httpd
>  2669 apache 15 0 204m 67m 3892 S 0.0 7.1 1:10.97 httpd
>  2391 apache 15 0 206m 65m 3636 S 0.0 6.9 1:07.24 httpd
>  2385 apache 15 0 210m 62m 3308 S 0.0 6.6 1:29.17 httpd
>  2401 apache 17 0 208m 57m 3644 S 0.0 6.1 1:18.16 httpd
>  2388 apache 15 0 204m 56m 3568 S 0.0 6.0 1:01.46 httpd
>  2389 apache 15 0 207m 56m 3824 S 0.0 5.9 1:10.61 httpd
>  2390 apache 15 0 208m 54m 3592 S 0.0 5.8 1:33.90 httpd
>  2493 apache 17 0 203m 50m 3844 S 0.0 5.4 1:02.30 httpd
>  2392 apache 15 0 207m 50m 3232 S 0.0 5.3 1:10.83 httpd
>  2386 apache 15 0 207m 47m 3592 S 0.0 5.0 1:24.97 httpd
>  2494 apache 15 0 205m 46m 3648 S 0.0 4.9 1:10.75 httpd
>  2492 apache 15 0 204m 43m 3812 S 0.0 4.6 1:11.58 httpd
>  2275 root 15 0 115m 15m 3116 S 0.0 1.6 0:04.33 httpd
>  2159 mysql 18 0 138m 8704 2792 S 0.0 0.9 0:01.67 mysqld
>
>
> ----- Original Message -----
> From: "Kenneth Marshall" <ktm at rice.edu>
> To: "Eriks Goodwin-Pfister" <eriks at centritech.net>
> Cc: "rt-users" <rt-users at lists.bestpractical.com>
> Sent: Tuesday, June 1, 2010 9:55:06 AM
> Subject: Re: [rt-users] CPU Wait Maxed Out
>
> On Tue, Jun 01, 2010 at 09:48:24AM -0400, Eriks Goodwin-Pfister wrote:
> > But then my question becomes, "why did this happen all of a sudden?"
> > We have not changed user loads, usage levels, etc. This is a
> > dedicated box being used by about 5 active users and 20 intermittent
> > (once a
> > week) users. Is 1 Gb of memory not enought for RT with such a light
> > loading?
> >
> > And does anyone have any idea what those odd mailq entries are? I
> > have to go in and delete several hundred of them every day or two.
> >
> > Thanks,
> > Eriks
> >
>
> Hi Eriks,
>
> Obviously, something did change or you would not be having a
> problem. :) The harder part is to discover what changed and how
> it is affecting your system. Those odd mailq entries if they
> are being fed to RT could bump the load on your system. Do
> you have any kind of filtering pre-RT to prevent bogus mail
> from hitting the RT server?
>
> Regards,
> Ken
>
> >
> > ----- Original Message -----
> > From: "Richard Skelton" <Richard.Skelton at infineon.com>
> > To: "Eriks Goodwin-Pfister" <eriks at centritech.net>
> > Sent: Tuesday, June 1, 2010 9:07:58 AM
> > Subject: Re: [rt-users] CPU Wait Maxed Out
> >
> > Hi Eriks,
> > Yes as I thought you are short on real memory.
> > Look at the swap.
> > Here is a busy 16 core Linux system of mine with load of free
> > memory:- procs -----------memory---------- ---swap-- -----io----
> > --system--
> > ----cpu---- r b swpd free buff cache si so bi bo in cs us sy
> > id wa
>
> ...lots of repetitive information deleted...
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>