<quote> That sounds more like a resource constraint problem on the server </quote>

 

I agree but see below (I’ve munged some of the information):

 

Running Fine:

 

top - 11:25:54 up 33 days, 16:05,  1 user,  load average: 0.00, 0.00, 0.00

Tasks: 256 total,   1 running, 255 sleeping,   0 stopped,   0 zombie

Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   3872832k total,  2476000k used,  1396832k free,   217676k buffers

Swap:  2064380k total,    11676k used,  2052704k free,  1092156k cached

 

Not responding:

 

top - 13:42:33 up 33 days, 18:22,  1 user,  load average: 0.00, 0.00, 0.00

Tasks: 256 total,   1 running, 255 sleeping,   0 stopped,   0 zombie

Cpu(s):  0.1%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   3872832k total,  2564764k used,  1308068k free,   218068k buffers

Swap:  2064380k total,    11676k used,  2052704k free,  1103772k cached

 

System Log (from the Admin Page of the website during the most recent issue):

 

Mon Apr 20 13:46:05 2015            notice   OTRS-CGI-61      User: dritchie authentication ok (Method: sha256, REMOTE_ADDR: 10.0.255.00).

Mon Apr 20 13:40:04 2015            info        OTRS-otrs.PostMasterMailbox.pl-61       POP3S: Fetched 2 email(s) from xxxxxxxxxxxxxxxxxxxxxxxx

Mon Apr 20 13:40:04 2015            info        OTRS-otrs.PostMasterMailbox.pl-61       Sent agent 'NewTicket' notification to 'dritchie@mtcperformance.com'.

Mon Apr 20 13:40:04 2015            info        OTRS-otrs.PostMasterMailbox.pl-61       New Ticket [61008259/WARNING. Someon] created

                (TicketID=8257,Queue=Raw,Priority=3 normal,State=new)

 

 

/var/log/http/access_log (covering the same time frame):

 

**my successful logout from earlier**

 

10.0.255.00 - - [20/Apr/2015:13:09:52 -0500] "GET /otrs-web/js/js-cache/ModuleJS_ecdc48f1f171c4862d8934c0aba66b85.js HTTP/1.1" 200 368

                "http://ticketxx.yyyy.com/otrs/index.pl?Action=Logout;ChallengeToken=6uM1wcJWJ2ydJMcA1uyxnjGKveSZQ0nB;" "Mozilla/5.0 (Windows NT 6.1; Win64; x64)

                AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.18 Safari/537.36"

 

** My attempt to login**

 

10.0.255.00 - - [20/Apr/2015:13:41:45 -0500] "GET / HTTP/1.1" 302 26 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36

                (KHTML, like Gecko) Chrome/43.0.2357.18 Safari/537.36"

 

**NOTE: this is my testing if the apache server is responding correctly**

 

10.0.255.00 - - [20/Apr/2015:13:42:10 -0500] "GET /server-status?refresh=25 HTTP/1.1" 200 6482 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64)

                AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.18 Safari/537.36"

 

**successful login**

 

10.0.255.00 - - [20/Apr/2015:13:46:02 -0500] "GET /otrs/index.pl?Action=AdminPostMasterFilter;Subaction=AddAction HTTP/1.1" 200 3594 "-"

                "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.18 Safari/537.36"

 

 

 

/var/log/http/error_log

 

nothing

 

Notice that the Apache log shows an attempt to log in at 13:41:45 while the System Log (from the admin page of the website) shows nothing until the successful login at 13:46:05 (also shown at 13:46:02 in the Apache Access Log).

 

 

Any Ideas?

 

 

Thank You

 

Dennis

 

From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of David Boyes
Sent: Monday, April 20, 2015 9:58 AM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] question

 

The 15 minutes can be to get a logon screen.

Or if already logged in to switch screens.

 

That sounds more like a resource constraint problem on the server running the OTRS code than a database problem – OTRS is a relatively large application, and can be fairly demanding on application server resources. Try monitoring CPU, swap and memory utilization at 5 minute intervals on the OTRS server for a few days and see if there’s any correlation to the problem periods – if the OTRS server is thrashing, the database response is irrelevant. Eliminate that possibility first, and then start looking at database performance.