0
  1. Background: I am a .net developer, limited php coding knowledge
  2. Asking this question because I think it is a php/mysql/version/implementation issue, and not getting real information from the OSticket dev side...
  3. My coding/db knowledge tells me this is not necessarily server setup related, and as above, not getting much info from any OSticket resources.
  4. IIS7, mysql 5.6, php 5.5.13

We are running two servers. Both run Server 2008 (1 = Web, 1 = standard).

On both servers we run OSticket in an IIS environment, with php configured. (Two different osTicket implementation and databases)

On 1 server, everything works fine, with thousands of tickets. On the other server, queries take up to 90 seconds... most of them 30-40 seconds... These look like pretty simple queries... There are about 16K tickets in this db tho.. some of them have decent sized attachments...

Both servers run the same version of OSticket.

The issue reminds me of a mySQL code implementation that I once did, which also suffered these type of delays with basic queries... I had to make some simple query changes, and it sped up by a factor. This issue smells very similar.

I have tried the following in mySQL

  1. Binding to a static IP, and not using lcoalhost
  2. Skipping dns resolve
  3. Mysql InnoDB flush trx log to 0 and 2
  4. Repaired all tables optemised tables

The server is really idling. It has 16GB RAM, and 8 cores. It does run other services as well, IIS, MSSQL, etc, but as stated, it's idding. I cant see it being a server config/resources issue.

MySQL is consuming about 1gb of Ram, and at times, about 5-15% cpu.... (CPU seems high to me...)

Examples of slow queries are:

SET timestamp=1411987784;
SELECT thread.*, info.email_mid, info.headers  ,count(DISTINCT attach.attach_id) as attachments  FROM ost_ticket_thread thread  LEFT JOIN ost_ticket_email_info info
                ON (thread.id=info.thread_id)  LEFT JOIN ost_ticket_attachment attach
                ON (thread.ticket_id=attach.ticket_id
                        AND thread.id=attach.ref_id)  WHERE  thread.id=108610 AND thread.thread_type='N' GROUP BY thread.id;
# Time: 140929 12:49:44
# User@Host: osticket[osticket] @ PLM-S01 [192.168.10.11]  Id:   154
# Query_time: 28.177612  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 108472

InnoDB Status query returns:

'
=====================================
2014-09-29 14:25:16 25b0 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 57 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 1972 srv_active, 0 srv_shutdown, 5354 srv_idle
srv_master_thread log flush and writes: 7325
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 1366361
OS WAIT ARRAY INFO: signal count 1108283
Mutex spin waits 2150949, rounds 3167588, OS waits 18721
RW-shared spins 1435812, rounds 40962905, OS waits 1344494
RW-excl spins 2597, rounds 57911, OS waits 1364
Spin rounds per wait: 1.47 mutex, 28.53 RW-shared, 22.30 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 6366171
Purge done for trx''s n:o < 6366156 undo n:o < 0 state: running but idle
History list length 325
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 14, OS thread handle 0x25b0, query id 61326 localhost 127.0.0.1 osticket init
SHOW ENGINE INNODB STATUS
---TRANSACTION 0, not started
MySQL thread id 13, OS thread handle 0xa94, query id 57911 localhost 127.0.0.1 osticket cleaning up
---TRANSACTION 0, not started
MySQL thread id 6, OS thread handle 0x1cd4, query id 404 PLM-S01 192.168.10.11 osticket cleaning up
---TRANSACTION 6366167, ACTIVE 49 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 318, OS thread handle 0x20b8, query id 60114 PLM-S01 192.168.10.11 osticket updating
UPDATE ost_ticket SET isoverdue=1, updated=NOW()  WHERE ticket_id=21086
Trx read view will not see trx with id >= 6366168, sees < 6366153
------- TRX HAS BEEN WAITING 48 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 136 page no 142 n bits 216 index `PRIMARY` of table `plm_osticket`.`ost_ticket` trx id 6366167 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 24; compact format; info bits 0
 0: len 4; hex 0000525e; asc   R^;;
 1: len 6; hex 0000006123c9; asc    a# ;;
 2: len 7; hex 6f000002e201ca; asc o      ;;
 3: len 6; hex 373939353332; asc 799532;;
 4: len 4; hex 000003a0; asc     ;;
 5: len 4; hex 00000000; asc     ;;
 6: len 4; hex 00000001; asc     ;;
 7: len 4; hex 00000002; asc     ;;
 8: len 4; hex 00000002; asc     ;;
 9: len 4; hex 00000000; asc     ;;
 10: len 4; hex 0000000a; asc     ;;
 11: len 4; hex 00000000; asc     ;;
 12: len 4; hex 00000005; asc     ;;
 13: len 13; hex 3139322e3136382e31302e3836; asc 192.168.10.86;;
 14: len 1; hex 02; asc  ;;
 15: len 1; hex 01; asc  ;;
 16: len 1; hex 00; asc  ;;
 17: SQL NULL;
 18: len 5; hex 9993f541b1; asc    A ;;
 19: SQL NULL;
 20: len 5; hex 9993f541b1; asc    A ;;
 21: len 5; hex 9993ecb9a6; asc      ;;
 22: len 5; hex 9993eca222; asc     ";;
 23: len 5; hex 9993fae4da; asc      ;;

------------------
---TRANSACTION 6366153, ACTIVE 351 sec fetching rows, thread declared inside InnoDB 1070
mysql tables in use 2, locked 0
33 lock struct(s), heap size 6544, 33 row lock(s), undo log entries 208
MySQL thread id 314, OS thread handle 0x1864, query id 61324 PLM-S01 192.168.10.11 osticket Sending data
SELECT thread.*, info.email_mid, info.headers  ,count(DISTINCT attach.attach_id) as attachments  FROM ost_ticket_thread thread  LEFT JOIN ost_ticket_email_info info
                ON (thread.id=info.thread_id)  LEFT JOIN ost_ticket_attachment attach
                ON (thread.ticket_id=attach.ticket_id
                        AND thread.id=attach.ref_id)  WHERE  thread.id=109028 AND thread.thread_type=''M'' GROUP BY thread.id
Trx read view will not see trx with id >= 6366154, sees < 6366114
--------
FILE I/O
--------
I/O thread 0 state: wait Windows aio (insert buffer thread)
I/O thread 1 state: wait Windows aio (log thread)
I/O thread 2 state: wait Windows aio (read thread)
I/O thread 3 state: wait Windows aio (read thread)
I/O thread 4 state: wait Windows aio (read thread)
I/O thread 5 state: wait Windows aio (read thread)
I/O thread 6 state: wait Windows aio (write thread)
I/O thread 7 state: wait Windows aio (write thread)
I/O thread 8 state: wait Windows aio (write thread)
I/O thread 9 state: wait Windows aio (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
 ibuf aio reads: 0, log i/o''s: 0, sync i/o''s: 2
Pending flushes (fsync) log: 0; buffer pool: 0
7329448 OS file reads, 28218 OS file writes, 9771 OS fsyncs
1264.75 reads/s, 16384 avg bytes/read, 4.51 writes/s, 1.70 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 17, seg size 19, 3190 merges
merged operations:
 insert 3265, delete mark 252, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 722273, node heap has 1 buffer(s)
566.90 hash searches/s, 68.35 non-hash searches/s
---
LOG
---
Log sequence number 5444405216
Log flushed up to   5444396184
Pages flushed up to 5444396184
Last checkpoint at  5444396184
1 pending log writes, 0 pending chkp writes
3744 log i/o''s done, 0.67 log i/o''s/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 373637120; in additional pool allocated 0
Dictionary memory allocated 399883
Buffer pool size   22272
Free buffers       1010
Database pages     21261
Old database pages 7828
Modified db pages  12
Pending reads 1
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 16540365, not young 61439991
2726.25 youngs/s, 8876.23 non-youngs/s
Pages read 7329387, created 989, written 23206
1264.80 reads/s, 0.21 creates/s, 3.63 writes/s
Buffer pool hit rate 950 / 1000, young-making rate 107 / 1000 not 351 / 1000
Pages read ahead 61.74/s, evicted without access 7.81/s, Random read ahead 0.00/s
LRU len: 21261, unzip_LRU len: 0
I/O sum[59357]:cur[18], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
1 queries inside InnoDB, 0 queries in queue
2 read views open inside InnoDB
Main thread id 8924, state: flushing log
Number of rows inserted 3212, updated 1123, deleted 8, read 132865050
1.58 inserts/s, 0.25 updates/s, 0.00 deletes/s, 19276.61 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
'

I would appreciate some ideas about where I could start fiddling...

2
  • Seems to be an I/O bottleneck. Are you sure the server's actually idle? Resource Monitor will show the state of your disk as well. Are these virtual servers? If so, check the underlying disks too.
    – Nathan C
    Sep 29, 2014 at 12:51
  • Hi Nathan. There is some disk activity... but not overly so... And the one workign well, is a virtual server, in the cloud. The other one, not working so well, is a physical server/OS combo. 16GB ram, 8 cores etc. Sep 29, 2014 at 13:01

1 Answer 1

0

I eventually got this issue sorted by exporting the DB, creating a new DB, and importing the old data.

Don't ask me why it worked, but it did.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .