[rt-users] Recommendation / Feature Request for Table Layouts
Hi, I would very much appreciate a way of avoiding line breaks in certain Columns in a RT Search result. Specifically columns like Created Relative often break like 17 hours ago ... or in German ... vor 17 Stunden This looks like this: http://www.nehmer.net/~torben/rt-users/2010-07-01-09.00.44.png I have tried adding a nowrap option in the search definition, but RT strips it out. The thing here is, that a nowrap here would often actually save space. Best regards, Torben Nehmer --- Torben Nehmer Diplom Informatiker (FH) Business System Developer CANCOM Deutschland GmbH Messerschmittstr. 20 89343 Scheppach Germany Tel.: +49 8225 - 996-1118 Fax: +49 8225 - 996-41118 torben.neh...@cancom.demailto:torben.neh...@cancom.de www.cancom.dehttp://www.cancom.de CANCOM Deutschland GmbH Sitz der Gesellschaft: Jettingen-Scheppach HRB 10653 Memmingen Geschäftsführer: Paul Holdschik, Christian Linder Diese E-Mail und alle mitgesendeten Dateien sind vertraulich und ausschließlich für den Gebrauch durch den Empfänger bestimmt! This e-mail and any files transmitted with it are confidential intended solely for the use of the addressee! Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] custom field text area sizes
Hi all Does anybody know if there is a way to increase the size of a textbox for a custom field. It seems to default to about 25, and wont budge if you try to override that by adding a size= flag to the html eg input type=text class=text name=Object-RT::Ticket-%$TicketObj-Id%-CustomField-14-Valuesid=Object-RT::Ticket-%$TicketObj-Id%-CustomField-14-Values size-70 regards Garry -- Dr Garry Booth IT Services Loughborough University Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Going crazy with RT 3.8 and Timezones for Display Dates
Hi Torsten,
try this:
my $DUEDATE = $self-TicketObj-FirstCustomFieldValue('Date');
my $DUETIME = $self-TicketObj-FirstCustomFieldValue('Time');
my $DUE = $DUEDATE. .$DUETIME;
my $DATE = RT::Date-new( $session{'CurrentUser'} );
$DATE-Set(
Format = 'unknown',
Value = $DUE,
Timezone = 'UTC',
);
$self-TicketObj-SetDue( $DATE-ISO );
return 1;
Chris
Am 30.06.2010 18:44, schrieb Torsten Brumm:
Hi RT Users,
since we are planing our RT 3.8 migration, we are cross checking all our
scrips and some scrips with time calculaltions driving me mad.
Example from RT 3.6.x
We have two CF's: Date and the other Time
CF.Date
CF.Time
The user is entering the date and the time in utc normally - our RT is
running in UTC
Then i have a tiny scrip:
my $DUEDATE = $self-TicketObj-FirstCustomFieldValue('Date');
my $DUETIME = $self-TicketObj-FirstCustomFieldValue('Time');
my $DUE = $DUEDATE. .$DUETIME;
$self-TicketObj-SetDue($DUE);
return 1;
Under RT 3.6. RT was setting this simply to the entered values, all was
fine.
Now with RT 3.8 RT the user is able to enter his timezone offset for
Display and RT is adding the Timezone Difference to this value.
Any hints how to prevent this? or to make sure to get the correct value,
entered by the user?
Torsten
--
MFG
Torsten Brumm
http://www.brumm.me
http://www.elektrofeld.de
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] custom field text area sizes
Hi Please ignore my last, fat fingers I fear, added an extra - apols Garry Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] How to not send a notification to requestor when resolved a specify ticket ?
Hi Everybody, Im a new user of RT / RTFM, I looking for a way to specify for one ticket that we don't want to send a mail to requestor. I can see options in scrip #10 but i think it 's not the good way. Can someone help me for this problem ? Thanks in advance, Regards. (sorry for my poor english) Fabrice Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
We do Kenneth, but most tickets don't have many file attachments, so I assume that's not an issue? Cheers, Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 17:54, Kenneth Crocker wrote: Justin, 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. Kenn LBNL On Tue, Jun 29, 2010 at 8:04 AM, Justin Hayes justin.ha...@openbet.com wrote: 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. I guess it must still access the DB resultset during the ticket rendering (which isn't how we thought it would work). Time to tune the hell out of mysql then... Justin - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:53, Justin Hayes wrote: Seem to be quite a few things to look at Jason. Need to figure out what they all mean first. Justin General Statistics -- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log [OK] Operating on 64-bit architecture Storage Engine Statistics --- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 611M (Tables: 8) [--] Data in InnoDB tables: 10G (Tables: 20) [!!] Total fragmented tables: 21 Performance Metrics - [--] Up for: 19d 19h 32m 37s (110M q [64.266 qps], 222K conn, TX: 637B, RX: 39B) [--] Reads / Writes: 98% / 2% [--] Total buffers: 602.0M global + 134.8M per thread (150 max threads) [!!] Maximum possible memory usage: 20.3G (262% of installed RAM) [OK] Slow queries: 0% (229K/110M) [!!] Highest connection usage: 100% (151/150) [OK] Key buffer size / total MyISAM indexes: 512.0M/6.7M [OK] Key buffer hit rate: 100.0% (84M cached / 7K reads) [OK] Query cache efficiency: 71.4% (76M cached / 107M selects) [!!] Query cache prunes per day: 661360 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts) [!!] Joins performed without indexes: 112714 [!!] Temporary tables created on disk: 33% (968K on disk / 2M total) [OK] Thread cache hit rate: 99% (1K created / 222K connections) [OK] Table cache hit rate: 36% (318 open / 880 opened) [OK] Open file limit used: 14% (166/1K) [OK] Table locks acquired immediately: 99% (39M immediate / 39M locks) [!!] InnoDB data size / buffer pool: 10.1G/8.0M Recommendations - General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce your overall MySQL memory footprint for system stability Reduce or eliminate persistent connections to reduce connection usage Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** max_connections ( 150) wait_timeout ( 28800) interactive_timeout ( 28800) query_cache_size ( 16M) join_buffer_size ( 2.0M, or always use indexes with joins) tmp_table_size ( 128M) max_heap_table_size ( 64M) innodb_buffer_pool_size (= 10G) - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 29 Jun 2010, at 15:22, Jason Doran wrote: Hi, If you are using mysqld have a look at mysqltuner.pl perl script (google) This has fixed quickly many performance issues on both RT and other web-based software we use. I run this every few weeks and apply suggested changes and then simply restart mysqld when things are quite. Regards, Jason Doran Computer Centre NUI, Maynooth On 29 Jun 2010, at 14:09, Justin Hayes wrote: Hi everyone, I've raised this before, but we've had another look at it and still can't see how to improve things. 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. We don't have any slow queries - all the time seems to be in the code rendering the history of the ticket. We've had a go at stripping functions out of ShowHistory, ShowTransaction and ShowTransactionAttachmments but not had much success. FWIW our RT runs on quad 3ghz Xeons with 8gb of ram. I'd like to try and determine if we're just
Re: [rt-users] Slow Ticket History 3.8.8
Thanks a lot for this response Kim. r.e. the joins without indexes. How can we work out which indexes we need? I'd have thought this would cause slow queries but we're not seeing any... We're trying to tune on our test server before making any changes to live, however the hardware etc is different so not sure it it's going to be that useful an excercise. This is what we're not getting on test - we still get long ticket load times and we've done a lot of the recommended tuning: [OK] Logged in using credentials passed on the command line General Statistics -- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.0.75-0ubuntu10.2 [OK] Operating on 64-bit architecture Storage Engine Statistics --- [--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 131M (Tables: 15) [--] Data in InnoDB tables: 10G (Tables: 81) [!!] Total fragmented tables: 2 Performance Metrics - [--] Up for: 3m 44s (9K q [41.304 qps], 73 conn, TX: 17M, RX: 2M) [--] Reads / Writes: 99% / 1% [--] Total buffers: 11.0G global + 3.5M per thread (150 max threads) [!!] Maximum possible memory usage: 11.5G (149% of installed RAM) [OK] Slow queries: 0% (20/9K) [OK] Highest usage of available connections: 9% (14/150) [OK] Key buffer size / total MyISAM indexes: 3.0G/4.6M [OK] Key buffer hit rate: 97.8% (453 cached / 10 reads) [OK] Query cache efficiency: 89.0% (8K cached / 9K selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 22 sorts) [OK] Temporary tables created on disk: 14% (28 on disk / 195 total) [OK] Thread cache hit rate: 80% (14 created / 73 connections) [OK] Table cache hit rate: 95% (121 open / 127 opened) [OK] Open file limit used: 7% (80/1K) [OK] Table locks acquired immediately: 100% (773 immediate / 773 locks) [!!] InnoDB data size / buffer pool: 10.7G/6.0G Recommendations - General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Reduce your overall MySQL memory footprint for system stability Enable the slow query log to troubleshoot bad queries Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** innodb_buffer_pool_size (= 10G) - Justin Hayes OpenBet Support Manager justin.ha...@openbet.com On 30 Jun 2010, at 08:55, Kim Pedersen wrote: Hi Justin, Our RT instance is much smaller than yours, but we had very similar problems. Optimizing MySQL using the output from the tuner script made nearly all the speed issues go away. The one remaining issue we had with slow queries was resolved after the upgrade to 3.8.8 Your key buffer size looks like overkill - probably want to reduce that, and you have many joins done without indexes - that's a performance killer. Your InnoDB memory allocation looks like it needs to be increasing. Overall I'd say your database performance is skewed towards ISAM performance and not InnoDB (Which is what RT3 uses by default) Kim On 2010-06-29 10:53, Justin Hayes wrote: Seem to be quite a few things to look at Jason. Need to figure out what they all mean first. Justin General Statistics -- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log [OK] Operating on 64-bit architecture Storage Engine Statistics --- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 611M (Tables: 8) [--] Data in InnoDB tables: 10G (Tables: 20) [!!] Total fragmented tables: 21 Performance Metrics - [--] Up for: 19d 19h 32m 37s (110M q [64.266 qps], 222K conn, TX: 637B, RX: 39B) [--] Reads / Writes: 98% / 2% [--] Total buffers: 602.0M global + 134.8M per thread (150 max threads) [!!] Maximum possible memory usage: 20.3G (262% of installed RAM) [OK] Slow queries: 0% (229K/110M) [!!] Highest connection usage: 100% (151/150) [OK] Key buffer size / total MyISAM indexes: 512.0M/6.7M [OK] Key buffer hit rate: 100.0% (84M cached / 7K reads) [OK] Query cache efficiency: 71.4% (76M cached / 107M selects) [!!] Query cache prunes per day: 661360 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts) [!!] Joins performed without indexes: 112714 [!!] Temporary tables created on disk: 33% (968K on disk / 2M total) [OK] Thread cache hit rate: 99% (1K created / 222K
Re: [rt-users] Slow Ticket History 3.8.8
I'd heard of this before and thought I'd removed them. Just checked on live and
they're still there.
However removing them seems to have made no difference. Still taking 20+seconds
for a ticket with 130 comments/replies (+ other status changes etc).
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 1 Jul 2010, at 11:51, Raed El-Hames wrote:
Justin,
Do you use Transaction custom fields, if you do n’t ; try and comment out
lines 70,71,72 from html/Ticket/Elements/ShowTransaction
% if ( $Transaction-CustomFieldValues-Count ) {
/Elements/ShowCustomFields, Object = $Transaction
% }
See if that improves things for you.
Some of our monitoring tickets can have up to 500 updates, such tickets use
to take up to 20s to load, once I commented out the above lines, load time is
now down to less than 5 seconds.
Regards;
Roy
From: rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Justin Hayes
Sent: 01 July 2010 11:39
To: Kenneth Crocker
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Slow Ticket History 3.8.8
We do Kenneth, but most tickets don't have many file attachments, so I assume
that's not an issue?
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 29 Jun 2010, at 17:54, Kenneth Crocker wrote:
Justin,
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.
Kenn
LBNL
On Tue, Jun 29, 2010 at 8:04 AM, Justin Hayes justin.ha...@openbet.com
wrote:
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.
I guess it must still access the DB resultset during the ticket rendering
(which isn't how we thought it would work).
Time to tune the hell out of mysql then...
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 29 Jun 2010, at 15:53, Justin Hayes wrote:
Seem to be quite a few things to look at Jason. Need to figure out what
they all mean first.
Justin
General Statistics
--
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log
[OK] Operating on 64-bit architecture
Storage Engine Statistics
---
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 611M (Tables: 8)
[--] Data in InnoDB tables: 10G (Tables: 20)
[!!] Total fragmented tables: 21
Performance Metrics
-
[--] Up for: 19d 19h 32m 37s (110M q [64.266 qps], 222K conn, TX: 637B, RX:
39B)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 602.0M global + 134.8M per thread (150 max threads)
[!!] Maximum possible memory usage: 20.3G (262% of installed RAM)
[OK] Slow queries: 0% (229K/110M)
[!!] Highest connection usage: 100% (151/150)
[OK] Key buffer size / total MyISAM indexes: 512.0M/6.7M
[OK] Key buffer hit rate: 100.0% (84M cached / 7K reads)
[OK] Query cache efficiency: 71.4% (76M cached / 107M selects)
[!!] Query cache prunes per day: 661360
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts)
[!!] Joins performed without indexes: 112714
[!!] Temporary tables created on disk: 33% (968K on disk / 2M total)
[OK] Thread cache hit rate: 99% (1K created / 222K connections)
[OK] Table cache hit rate: 36% (318 open / 880 opened)
[OK] Open file limit used: 14% (166/1K)
[OK] Table locks acquired immediately: 99% (39M immediate / 39M locks)
[!!] InnoDB data size / buffer pool: 10.1G/8.0M
Recommendations
-
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
Reduce or eliminate persistent connections to reduce connection usage
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
max_connections ( 150)
wait_timeout ( 28800)
interactive_timeout ( 28800)
query_cache_size ( 16M)
join_buffer_size ( 2.0M, or always use indexes with joins)
tmp_table_size ( 128M)
max_heap_table_size ( 64M)
innodb_buffer_pool_size (= 10G)
Re: [rt-users] Going crazy with RT 3.8 and Timezones for Display Dates
Hi Chris,
this i already tried. The problem is more that the timezone offset is only
for display, not for calculation used (so far i figured already) and i have
really no idea how to fix it. one possible way could be:
1. If a user is entering this fields, check the users timezone and use the
offset to work with the utc values...
i will play around a little more...
Torsten
2010/7/1 Christian Loos cl...@netcologne.de
Hi Torsten,
try this:
my $DUEDATE = $self-TicketObj-FirstCustomFieldValue('Date');
my $DUETIME = $self-TicketObj-FirstCustomFieldValue('Time');
my $DUE = $DUEDATE. .$DUETIME;
my $DATE = RT::Date-new( $session{'CurrentUser'} );
$DATE-Set(
Format = 'unknown',
Value = $DUE,
Timezone = 'UTC',
);
$self-TicketObj-SetDue( $DATE-ISO );
return 1;
Chris
Am 30.06.2010 18:44, schrieb Torsten Brumm:
Hi RT Users,
since we are planing our RT 3.8 migration, we are cross checking all our
scrips and some scrips with time calculaltions driving me mad.
Example from RT 3.6.x
We have two CF's: Date and the other Time
CF.Date
CF.Time
The user is entering the date and the time in utc normally - our RT is
running in UTC
Then i have a tiny scrip:
my $DUEDATE = $self-TicketObj-FirstCustomFieldValue('Date');
my $DUETIME = $self-TicketObj-FirstCustomFieldValue('Time');
my $DUE = $DUEDATE. .$DUETIME;
$self-TicketObj-SetDue($DUE);
return 1;
Under RT 3.6. RT was setting this simply to the entered values, all was
fine.
Now with RT 3.8 RT the user is able to enter his timezone offset for
Display and RT is adding the Timezone Difference to this value.
Any hints how to prevent this? or to make sure to get the correct value,
entered by the user?
Torsten
--
MFG
Torsten Brumm
http://www.brumm.me
http://www.elektrofeld.de
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
--
MFG
Torsten Brumm
http://www.brumm.me
http://www.elektrofeld.de
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Going crazy with RT 3.8 and Timezones for Display Dates
Hi Torsten, normally you don't need to worry about timezones in date calculations. You should always normalize all dates to UTC and then do the calculations. May you can give an example of you date calculations? Chris Am 01.07.2010 14:10, schrieb Torsten Brumm: Hi Chris, this i already tried. The problem is more that the timezone offset is only for display, not for calculation used (so far i figured already) and i have really no idea how to fix it. one possible way could be: 1. If a user is entering this fields, check the users timezone and use the offset to work with the utc values... i will play around a little more... Torsten Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Hi Roy,
We've logged the SQL statements on the test server - virtually every query is
.000s of a second. Yet the ticket we're using on there still takes 12s to
render.
So the queries seem ok. However I know that having a huge ticket in a small DB
is much faster (say 2s). So it *seems* to be DB or server related, I just don't
know how...
Thanks,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 1 Jul 2010, at 12:28, Raed El-Hames wrote:
Hi Justin;
Our database is ~ 59G, the attachments table is ~ 40G.
In our setup , the web server is different hardware to the db servers , and
the db servers are 2 * dual core 2.6 AMD processors with 16G Ram,
A stupid question, but did you restart apache after you commented out the
ShowTransaction lines ?
What version of RT by the way?
Do you use UseSQLForACLChecks?? I found it slows things a bit as it tries to
build long joins with cached group members and groups etc.
In terms of debug; if you have not done this yet enable DBIx-SearchBuilder
StatementLog
Set($StatementLog,’debug’); in your etc/RT_SiteConfig.
Then try to load the ticket, then from your rt.log grab some of the sql
statements generated and try executing them on the sql server via sql
console, and see if any are slow , for any slow queries try an explain and
see what indexes are used.
Something else I also try is to put debug lines with timestamps within the
html page itself and see which component taking the longest time, then do the
same within the slowest component breaking it into various parts to determine
which bit of code is taking the longest time etc etc.
Feel free to mail me again if you need further help.
Regards;
Roy
From: Justin Hayes [mailto:justin.ha...@openbet.com]
Sent: 01 July 2010 12:08
To: Raed El-Hames
Subject: Re: [rt-users] Slow Ticket History 3.8.8
Hi Raed,
How big is your DB? We've got about 10gb in Attachments. If we put a really
long ticket in an empty DB performance is excellent.
So something is wrong with the server/DB, we just don't know what.
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 1 Jul 2010, at 11:51, Raed El-Hames wrote:
Justin,
Do you use Transaction custom fields, if you do n’t ; try and comment out
lines 70,71,72 from html/Ticket/Elements/ShowTransaction
% if ( $Transaction-CustomFieldValues-Count ) {
/Elements/ShowCustomFields, Object = $Transaction
% }
See if that improves things for you.
Some of our monitoring tickets can have up to 500 updates, such tickets use
to take up to 20s to load, once I commented out the above lines, load time is
now down to less than 5 seconds.
Regards;
Roy
From: rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Justin Hayes
Sent: 01 July 2010 11:39
To: Kenneth Crocker
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Slow Ticket History 3.8.8
We do Kenneth, but most tickets don't have many file attachments, so I assume
that's not an issue?
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 29 Jun 2010, at 17:54, Kenneth Crocker wrote:
Justin,
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.
Kenn
LBNL
On Tue, Jun 29, 2010 at 8:04 AM, Justin Hayes justin.ha...@openbet.com
wrote:
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.
I guess it must still access the DB resultset during the ticket rendering
(which isn't how we thought it would work).
Time to tune the hell out of mysql then...
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 29 Jun 2010, at 15:53, Justin Hayes wrote:
Seem to be quite a few things to look at Jason. Need to figure out what
they all mean first.
Justin
General Statistics
--
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log
[OK] Operating on 64-bit architecture
Storage Engine Statistics
---
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 611M (Tables: 8)
[--] Data in InnoDB tables: 10G (Tables: 20)
[!!] Total fragmented tables: 21
Performance Metrics
-
[--] Up for: 19d 19h 32m 37s (110M q [64.266
Re: [rt-users] Slow Ticket History 3.8.8
On Thu, Jul 01, 2010 at 02:30:56PM +0100, Justin Hayes wrote: Hi Roy, We've logged the SQL statements on the test server - virtually every query is .000s of a second. Yet the ticket we're using on there still takes 12s to render. So the queries seem ok. However I know that having a huge ticket in a small DB is much faster (say 2s). So it *seems* to be DB or server related, I just don't know how... Thanks, Justin Wild conjecture: The time is spent grabbing the attachments from the database. For the small database, all of them are available in just a few reads. For the large database, each attachment or update will need to have its own seek/read and will not typically be cached. Cheers, Ken Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Slow Ticket History 3.8.8
Have you read next links? Maybe you could be good for your server.
http://wiki.bestpractical.com/view/PerformanceTuning
http://wiki.bestpractical.com/view/CleanupSessions
Good luck!
Hi Roy,
We've logged the SQL statements on the test server - virtually every
query is .000s of a second. Yet the ticket we're using on there still
takes 12s to render.
So the queries seem ok. However I know that having a huge ticket in a
small DB is much faster (say 2s). So it *seems* to be DB or server
related, I just don't know how...
Thanks,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 1 Jul 2010, at 12:28, Raed El-Hames wrote:
Hi Justin;
Our database is ~ 59G, the attachments table is ~ 40G.
In our setup , the web server is different hardware to the db servers
, and the db servers are 2 * dual core 2.6 AMD processors with 16G Ram,
A stupid question, but did you restart apache after you commented out
the ShowTransaction lines ?
What version of RT by the way?
Do you use UseSQLForACLChecks?? I found it slows things a bit as it
tries to build long joins with cached group members and groups etc.
In terms of debug; if you have not done this yet enable
DBIx-SearchBuilder StatementLog
Set($StatementLog,’debug’); in your etc/RT_SiteConfig.
Then try to load the ticket, then from your rt.log grab some of the
sql statements generated and try executing them on the sql server via
sql console, and see if any are slow , for any slow queries try an
explain and see what indexes are used.
Something else I also try is to put debug lines with timestamps within
the html page itself and see which component taking the longest time,
then do the same within the slowest component breaking it into various
parts to determine which bit of code is taking the longest time etc etc.
Feel free to mail me again if you need further help.
Regards;
Roy
*From:* Justin Hayes [mailto:justin.ha...@openbet.com]
*Sent:* 01 July 2010 12:08
*To:* Raed El-Hames
*Subject:* Re: [rt-users] Slow Ticket History 3.8.8
Hi Raed,
How big is your DB? We've got about 10gb in Attachments. If we put a
really long ticket in an empty DB performance is excellent.
So something is wrong with the server/DB, we just don't know what.
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 1 Jul 2010, at 11:51, Raed El-Hames wrote:
Justin,
Do you use Transaction custom fields, if you do n’t ; try and comment
out lines 70,71,72 from html/Ticket/Elements/ShowTransaction
% if ( $Transaction-CustomFieldValues-Count ) {
/Elements/ShowCustomFields, Object = $Transaction
% }
See if that improves things for you.
Some of our monitoring tickets can have up to 500 updates, such
tickets use to take up to 20s to load, once I commented out the above
lines, load time is now down to less than 5 seconds.
Regards;
Roy
*From:* rt-users-boun...@lists.bestpractical.com
mailto:rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] *On Behalf Of
*Justin Hayes
*Sent:* 01 July 2010 11:39
*To:* Kenneth Crocker
*Cc:* rt-users@lists.bestpractical.com
mailto:rt-users@lists.bestpractical.com
*Subject:* Re: [rt-users] Slow Ticket History 3.8.8
We do Kenneth, but most tickets don't have many file attachments, so I
assume that's not an issue?
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 29 Jun 2010, at 17:54, Kenneth Crocker wrote:
Justin,
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.
Kenn
LBNL
On Tue, Jun 29, 2010 at 8:04 AM, Justin Hayes
justin.ha...@openbet.com mailto:justin.ha...@openbet.com wrote:
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.
I guess it must still access the DB resultset during the ticket
rendering (which isn't how we thought it would work).
Time to tune the hell out of mysql then...
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 29 Jun 2010, at 15:53, Justin Hayes wrote:
Seem to be quite a few things to look at Jason. Need to figure out
what they all mean first.
Justin
General Statistics
--
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.37-1ubuntu5.4-log
[OK] Operating on 64-bit architecture
Storage Engine Statistics
---
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 611M
Re: [rt-users] Slow Ticket History 3.8.8
Thanks Alberto. Will look at those as well.
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com
On 1 Jul 2010, at 14:42, Alberto Villanueva wrote:
Have you read next links? Maybe you could be good for your server.
http://wiki.bestpractical.com/view/PerformanceTuning
http://wiki.bestpractical.com/view/CleanupSessions
Good luck!
Hi Roy,
We've logged the SQL statements on the test server - virtually every
query is .000s of a second. Yet the ticket we're using on there still
takes 12s to render.
So the queries seem ok. However I know that having a huge ticket in a
small DB is much faster (say 2s). So it *seems* to be DB or server
related, I just don't know how...
Thanks,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 1 Jul 2010, at 12:28, Raed El-Hames wrote:
Hi Justin;
Our database is ~ 59G, the attachments table is ~ 40G.
In our setup , the web server is different hardware to the db servers
, and the db servers are 2 * dual core 2.6 AMD processors with 16G Ram,
A stupid question, but did you restart apache after you commented out
the ShowTransaction lines ?
What version of RT by the way?
Do you use UseSQLForACLChecks?? I found it slows things a bit as it
tries to build long joins with cached group members and groups etc.
In terms of debug; if you have not done this yet enable
DBIx-SearchBuilder StatementLog
Set($StatementLog,’debug’); in your etc/RT_SiteConfig.
Then try to load the ticket, then from your rt.log grab some of the
sql statements generated and try executing them on the sql server via
sql console, and see if any are slow , for any slow queries try an
explain and see what indexes are used.
Something else I also try is to put debug lines with timestamps within
the html page itself and see which component taking the longest time,
then do the same within the slowest component breaking it into various
parts to determine which bit of code is taking the longest time etc etc.
Feel free to mail me again if you need further help.
Regards;
Roy
*From:* Justin Hayes [mailto:justin.ha...@openbet.com]
*Sent:* 01 July 2010 12:08
*To:* Raed El-Hames
*Subject:* Re: [rt-users] Slow Ticket History 3.8.8
Hi Raed,
How big is your DB? We've got about 10gb in Attachments. If we put a
really long ticket in an empty DB performance is excellent.
So something is wrong with the server/DB, we just don't know what.
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 1 Jul 2010, at 11:51, Raed El-Hames wrote:
Justin,
Do you use Transaction custom fields, if you do n’t ; try and comment
out lines 70,71,72 from html/Ticket/Elements/ShowTransaction
% if ( $Transaction-CustomFieldValues-Count ) {
/Elements/ShowCustomFields, Object = $Transaction
% }
See if that improves things for you.
Some of our monitoring tickets can have up to 500 updates, such
tickets use to take up to 20s to load, once I commented out the above
lines, load time is now down to less than 5 seconds.
Regards;
Roy
*From:* rt-users-boun...@lists.bestpractical.com
mailto:rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] *On Behalf Of
*Justin Hayes
*Sent:* 01 July 2010 11:39
*To:* Kenneth Crocker
*Cc:* rt-users@lists.bestpractical.com
mailto:rt-users@lists.bestpractical.com
*Subject:* Re: [rt-users] Slow Ticket History 3.8.8
We do Kenneth, but most tickets don't have many file attachments, so I
assume that's not an issue?
Cheers,
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 29 Jun 2010, at 17:54, Kenneth Crocker wrote:
Justin,
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.
Kenn
LBNL
On Tue, Jun 29, 2010 at 8:04 AM, Justin Hayes
justin.ha...@openbet.com mailto:justin.ha...@openbet.com wrote:
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.
I guess it must still access the DB resultset during the ticket
rendering (which isn't how we thought it would work).
Time to tune the hell out of mysql then...
Justin
-
Justin Hayes
OpenBet Support Manager
justin.ha...@openbet.com mailto:justin.ha...@openbet.com
On 29 Jun 2010, at 15:53, Justin Hayes wrote:
Seem to be quite a few things to look at Jason. Need to figure out
what they all mean first.
Justin
General Statistics
Re: [rt-users] RTFM issue.
On Tue, Jun 29, 2010 at 04:10:01PM -0500, Mark Jenks wrote: I have RTFM 2.4.2 installed and seems to be mostly working correctly. But I can't finish setting it up to see. I don't have a place to put comments into the FAQ, so the notes that I found was to create a custom field. I have a Custom field called Body, Fill in one text area, applies to RTFM, and group rights are all set up. When I click on the Applies to and get the error: could not find component for path '/Elements/RT__FM__ClassCollection/ColumnMap' Hi I've bounced your bug report to rtfm-bugs It looks like an incompatibility crept in with the new Admin Format changes in 3.8.8 -kevin pgppKEhrzIHgn.pgp Description: PGP signature Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] webmux.pl error - Apache won't start
On Wed, Jun 30, 2010 at 04:48:34PM +0200, Joop van de Wege wrote: This one is simpler might help since it doesn't include the problem module. Further do you have the latest of Apache::DBI installed? If my memory is correct I had problems that make testdeps didn't detect if I had it installed. Had to do that by hand. I believe RT is only going to check for Apache::DBI if you said --with-web-handler=modperl2. Otherwise it assumes you're using fastcgi -kevin pgpvR2nCttODV.pgp Description: PGP signature Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Going crazy with RT 3.8 and Timezones for Display Dates
Hi.
I think you want to construct date object using user who set those cfs and
use timezone user. SetDue method has no diff between 3.6 and 3.8, it takes
ISO in utc.
01.07.2010 16:11 пользователь Torsten Brumm torsten.br...@googlemail.com
написал:
Hi Chris,
this i already tried. The problem is more that the timezone offset is only
for display, not for calculation used (so far i figured already) and i have
really no idea how to fix it. one possible way could be:
1. If a user is entering this fields, check the users timezone and use the
offset to work with the utc values...
i will play around a little more...
Torsten
2010/7/1 Christian Loos cl...@netcologne.de
Hi Torsten,
try this:
my $DUEDATE = $self-TicketObj-FirstCustomFieldValue('Date');
...
--
MFG
Torsten Brumm
http://www.brumm.me
http://www.elektrofeld.de
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] Do not understand how RTAddress works
To list, I have a couple questions about how ?? works. When I read about it in RT_Config.pm I do not get a clear understanding of what addresses it is talking about. C$RTAddressRegexp is used to make sure RT doesn't add itself as a ticket CC if the setting above is enabled. It is important that you set this to a regular expression that matches all addresses used by your RT. This lets RT avoid sending mail to itself. It will also hide RT addresses from the list of One-time Cc and Bcc lists on ticket reply. Set($RTAddressRegexp , undef); I don't really understand what addresses it is talking about. I have 157 Queue addresses, each with a different address. Do I have to list all those? What about the email address for the users? I'm not real quick on how the email/address works in terms of this setup, Can someone offer an explanation that is a little more clear? Thanks. Kenn LBNL Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
