On Fri, Jun 1, 2012 at 12:07 AM, Nathan Baker bak...@gmail.com wrote:
Thanks Kenn, I checked and didn't see any permissions globally set for
everyone, except the Create Ticket right is set for Everyone on each of our
queues.
I made a few more changes though and am considering the problem
Ruslan,
I agree with your recommendation in general for most installations,
especially ones larger than ours. I don't think increasing the
KeepAliveTimeout is necessary anymore now that I fixed the swapping issue,
because the initial page load does not take a long time anymore. However,
for our
Thanks Kenn, I checked and didn't see any permissions globally set for
everyone, except the Create Ticket right is set for Everyone on each of our
queues.
I made a few more changes though and am considering the problem fixed at
this point. I found that the system was doing a lot of memory
I'm going to try and separate this thread since my issue doesn't seem to be
related to the Search page or the SelectOwner field. Using the Mason
Profiler did give me some info though, it looks like it might be due to
some custom fields:
=Mason= localhost -
/Ticket/Elements/ShowCustomFields {{{
On Wed, May 30, 2012 at 6:37 PM, Nathan Baker bak...@gmail.com wrote:
I'm going to try and separate this thread since my issue doesn't seem to be
related to the Search page or the SelectOwner field. Using the Mason
Profiler did give me some info though, it looks like it might be due to some
Ruslan,
I actually started the other thread, so my details are in the first post.
That thread was sort of hijacked (no big deal) and getting messy, so I
wanted to separate them. I'm using Postgresql, not MySQL, and had already
turned on the SQL statement log and all queries seemed to be
On Wed, May 30, 2012 at 7:53 PM, Nathan Baker bak...@gmail.com wrote:
Ruslan,
I actually started the other thread, so my details are in the first post.
That thread was sort of hijacked (no big deal) and getting messy, so I
wanted to separate them. I'm using Postgresql, not MySQL, and had
Ruslan,
I wasn't aware that sessions had to be cleared, but now that you mentioned
it I looked and there were almost 10k sessions in our table. I cleared
that out and it does not seem to be slow in that section anymore. I've
also added that command to crontab to run daily.
It seems much better
Ruslan,
I guess what I was getting at is I don't think the SQL queries are the
problem here. The sum (by using your perl code) was 0.324813 seconds, much
less than 4 seconds.
I'm still trying different Apache settings, Postgresql settings, etc., but
here's a different way to explain the issue:
Okay...just an update. This is definitely directly tied to the Apache
KeepAliveTimeout setting. The default was 15 seconds for my installation,
and if I change it to 10 seconds or 60 seconds that is exactly how long of
a wait is required to make it slow again.
So from here it looks like the
Nathan,
It could be caused by granting wholesale permissions Globally for everyone
to Queues/Tickets and Custom Fields and that would make RT spend a lot of
time checking for permissions.
just a thought.
Kenn
On Wed, May 30, 2012 at 7:37 AM, Nathan Baker bak...@gmail.com wrote:
I'm going to
11 matches
Mail list logo
