<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">We do Kenneth, but most tickets don't have many file attachments, so I assume that's not an issue?<div><br></div><div>Cheers,</div><div><br></div><div>Justin<br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><br>-------------------------------------------------<br>Justin Hayes<br>OpenBet Support Manager<br><a href="mailto:justin.hayes@openbet.com">justin.hayes@openbet.com</a></span>
</div>
<br><div><div>On 29 Jun 2010, at 17:54, Kenneth Crocker wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Justin,<br><br>I didn't see this mentioned and may have missed it, but are you displaying attachements inline? That might cut back on the I/O for History. Just a thought.<br><br>Kenn<br>LBNL<br><br><div class="gmail_quote">
On Tue, Jun 29, 2010 at 8:04 AM, Justin Hayes <span dir="ltr"><<a href="mailto:justin.hayes@openbet.com">justin.hayes@openbet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As a test we've just created a long ticket in an empty RT DB and it's very fast. So does look to be DB related - contrary to our earlier investigations.<br>
<br>
I guess it must still access the DB resultset during the ticket rendering (which isn't how we thought it would work).<br>
<br>
Time to tune the hell out of mysql then.......<br>
<div class="im"><br>
Justin<br>
<br>
-------------------------------------------------<br>
Justin Hayes<br>
OpenBet Support Manager<br>
<a href="mailto:justin.hayes@openbet.com">justin.hayes@openbet.com</a><br>
<br>
</div><div><div></div><div class="h5">On 29 Jun 2010, at 15:53, Justin Hayes wrote:<br>
<br>
> Seem to be quite a few things to look at Jason. Need to figure out what they all mean first.<br>
><br>
> Justin<br>
><br>
> -------- General Statistics --------------------------------------------------<br>
> [--] Skipped version check for MySQLTuner script<br>
> [OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log<br>
> [OK] Operating on 64-bit architecture<br>
><br>
> -------- Storage Engine Statistics -------------------------------------------<br>
> [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster<br>
> [--] Data in MyISAM tables: 611M (Tables: 8)<br>
> [--] Data in InnoDB tables: 10G (Tables: 20)<br>
> [!!] Total fragmented tables: 21<br>
><br>
> -------- Performance Metrics -------------------------------------------------<br>
> [--] Up for: 19d 19h 32m 37s (110M q [64.266 qps], 222K conn, TX: 637B, RX: 39B)<br>
> [--] Reads / Writes: 98% / 2%<br>
> [--] Total buffers: 602.0M global + 134.8M per thread (150 max threads)<br>
> [!!] Maximum possible memory usage: 20.3G (262% of installed RAM)<br>
> [OK] Slow queries: 0% (229K/110M)<br>
> [!!] Highest connection usage: 100% (151/150)<br>
> [OK] Key buffer size / total MyISAM indexes: 512.0M/6.7M<br>
> [OK] Key buffer hit rate: 100.0% (84M cached / 7K reads)<br>
> [OK] Query cache efficiency: 71.4% (76M cached / 107M selects)<br>
> [!!] Query cache prunes per day: 661360<br>
> [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts)<br>
> [!!] Joins performed without indexes: 112714<br>
> [!!] Temporary tables created on disk: 33% (968K on disk / 2M total)<br>
> [OK] Thread cache hit rate: 99% (1K created / 222K connections)<br>
> [OK] Table cache hit rate: 36% (318 open / 880 opened)<br>
> [OK] Open file limit used: 14% (166/1K)<br>
> [OK] Table locks acquired immediately: 99% (39M immediate / 39M locks)<br>
> [!!] InnoDB data size / buffer pool: 10.1G/8.0M<br>
><br>
> -------- Recommendations -----------------------------------------------------<br>
> General recommendations:<br>
> Run OPTIMIZE TABLE to defragment tables for better performance<br>
> Reduce your overall MySQL memory footprint for system stability<br>
> Reduce or eliminate persistent connections to reduce connection usage<br>
> Adjust your join queries to always utilize indexes<br>
> When making adjustments, make tmp_table_size/max_heap_table_size equal<br>
> Reduce your SELECT DISTINCT queries without LIMIT clauses<br>
> Variables to adjust:<br>
> *** MySQL's maximum memory usage is dangerously high ***<br>
> *** Add RAM before increasing MySQL buffer variables ***<br>
> max_connections (> 150)<br>
> wait_timeout (< 28800)<br>
> interactive_timeout (< 28800)<br>
> query_cache_size (> 16M)<br>
> join_buffer_size (> 2.0M, or always use indexes with joins)<br>
> tmp_table_size (> 128M)<br>
> max_heap_table_size (> 64M)<br>
> innodb_buffer_pool_size (>= 10G)<br>
><br>
><br>
> -------------------------------------------------<br>
> Justin Hayes<br>
> OpenBet Support Manager<br>
> <a href="mailto:justin.hayes@openbet.com">justin.hayes@openbet.com</a><br>
><br>
> On 29 Jun 2010, at 15:22, Jason Doran wrote:<br>
><br>
>> Hi,<br>
>> If you are using mysqld have a look at "<a href="http://mysqltuner.pl/" target="_blank">mysqltuner.pl</a>" perl script (google)<br>
>> This has fixed quickly many performance issues on both RT and other<br>
>> web-based software we use. I run this every few weeks and apply suggested<br>
>> changes and then simply restart mysqld when things are quite.<br>
>><br>
>> Regards,<br>
>> Jason Doran<br>
>> Computer Centre<br>
>> NUI, Maynooth<br>
>><br>
>> On 29 Jun 2010, at 14:09, Justin Hayes wrote:<br>
>><br>
>>> Hi everyone,<br>
>>><br>
>>> I've raised this before, but we've had another look at it and still can't see how to improve things.<br>
>>><br>
>>> We put a lot of comments/replies in our tickets. Often there can be 50-100 entries in a ticket, mostly plain text. Loading such a ticket can take 10-20secs.<br>
>>><br>
>>> We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket.<br>
>>> We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success.<br>
>>><br>
>>> FWIW our RT runs on quad 3ghz Xeons with 8gb of ram.<br>
>>><br>
>>> I'd like to try and determine if we're just slow, or if this is just how long RT takes. Maybe perl is just slow.<br>
>>><br>
>>> Can anyone shed any light on how long it takes them to render long tickets in their systems? If you look at the page source it gives you a value e.g.<br>
>>><br>
>>> <span>Time to display: 24.996907</span><br>
>>><br>
>>> Can anyone share some numbers from theirs for longer tickets? It would be really appreciated.<br>
>>><br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Justin<br>
>>><br>
>>> -------------------------------------------------<br>
>>> Justin Hayes<br>
>>> OpenBet Support Manager<br>
>>> <a href="mailto:justin.hayes@openbet.com">justin.hayes@openbet.com</a><br>
>>><br>
>>><br>
>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.<br>
>>> Buy a copy at <a href="http://rtbook.bestpractical.com/" target="_blank">http://rtbook.bestpractical.com</a><br>
>><br>
><br>
><br>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.<br>
> Buy a copy at <a href="http://rtbook.bestpractical.com/" target="_blank">http://rtbook.bestpractical.com</a><br>
<br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.<br>
Buy a copy at <a href="http://rtbook.bestpractical.com/" target="_blank">http://rtbook.bestpractical.com</a><br>
</div></div></blockquote></div><br>
<br>Discover RT's hidden secrets with RT Essentials from O'Reilly Media.<br>Buy a copy at <a href="http://rtbook.bestpractical.com">http://rtbook.bestpractical.com</a></blockquote></div><br></div></body></html>