How would one go about purging old requests. I am very comfortable with
mysql, but not comfortable removing these linked records… Is there a
utility or something I’m missing?
As far as I know, nobody’s eve3r written the RT data warehousing tool which
would take old requests and transactions and move them to an archival database.
Basically, you want to make sure you yank both tickets and transactions. If
this is merely a performance issue, there may be other ways to deal. (Column indexes, etc.)On Wed, Oct 25, 2000 at 09:48:18PM -0700, Landon Stewart wrote:
How would one go about purging old requests. I am very comfortable with
mysql, but not comfortable removing these linked records… Is there a
utility or something I’m missing?
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.
As far as I know, nobody’s eve3r written the RT data warehousing tool which
would take old requests and transactions and move them to an archival database.Basically, you want to make sure you yank both tickets and transactions. If
this is merely a performance issue, there may be other ways to deal. (Column indexes, etc.)
Is the warehousing tool feasible in your opinion? Is it the right way to
do it?
It seems to me that an innate weakness of the system is that it would always
get bigger, and that it would be impossible to run a queue with any kind of
turnover for more than n years before having to start over. Some way to
warehouse the old transactions would be very useful after a long time
running, or a shorter time with a very busy queue.
Jill
As far as I know, nobody’s eve3r written the RT data warehousing tool which
would take old requests and transactions and move them to an archival database.Basically, you want to make sure you yank both tickets and transactions. If
this is merely a performance issue, there may be other ways to deal. (Column indexes, etc.)Is the warehousing tool feasible in your opinion? Is it the right way to
do it?
The warehousing tool is certainly feasable. Essentially it would move
all the old transactions and tickets (using local criteria for the meaning of “old”)
to a seperate database which was intended for reports, data mining and archival use.
I’ve never written the tool because I’ve never been anywhere with an RT instance
that was to big or slow for easy use.
Jesse
It seems to me that an innate weakness of the system is that it would always
get bigger, and that it would be impossible to run a queue with any kind of
turnover for more than n years before having to start over. Some way to
warehouse the old transactions would be very useful after a long time
running, or a shorter time with a very busy queue.Jill
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.
The warehousing tool is certainly feasable. Essentially it would move
all the old transactions and tickets (using local criteria for the meaning of “old”)
to a seperate database which was intended for reports, data mining and archival use.
Yeah, that’s what I had in mind too. I got the imagination running a bit
too fast and soon I had an image of a system like a tape backup jukebox
equipped with a robot arm to move the media around, so one could look at
tickets from eons back. With a soft drink dispenser on the side. But
that might be overkill.
I’ve never written the tool because I’ve never been anywhere with an RT instance
that was to big or slow for easy use.
This is good to hear. Does anyone know how big RT systems get without
slowing down? What is the biggest serial number out there? I’m sure
someone can beat my 87. 
Jill
Jill Lundquist wrote:
The warehousing tool is certainly feasable. Essentially it would move
all the old transactions and tickets (using local criteria for the meaning of “old”)
to a seperate database which was intended for reports, data mining and archival use.Yeah, that’s what I had in mind too. I got the imagination running a bit
too fast and soon I had an image of a system like a tape backup jukebox
equipped with a robot arm to move the media around, so one could look at
tickets from eons back. With a soft drink dispenser on the side. But
that might be overkill.
Cool idea. Needs an automatic coffeemaker tho, unless the /dev/coffee
project
is finished ;).
I’ve never written the tool because I’ve never been anywhere with an RT instance
that was to big or slow for easy use.This is good to hear. Does anyone know how big RT systems get without
slowing down? What is the biggest serial number out there? I’m sure
someone can beat my 87.
3752 is the current serial number I’m working.
SNIP
HTH,
GW
This is good to hear. Does anyone know how big RT systems get without
slowing down? What is the biggest serial number out there? I’m sure
someone can beat my 87.
we’re at #1343 after about… 5 months? not even the faintest sign of slowing down.
| > This is good to hear. Does anyone know how big RT systems get without
| > slowing down? What is the biggest serial number out there? I’m sure
| > someone can beat my 87.
|
| we’re at #1343 after about… 5 months? not even the faintest sign of
| slowing down.
±–>8
#27892 just came rolling in a few minutes ago. Still snappy.
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]
JOC, what kind of hardware are you running on? (i’m guessing the real slowdown
would come more from the number of simultaneous transactions (users pegging away
at the db) rather than the absolute number of transcations…)
| JOC, what kind of hardware are you running on? (i’m guessing the real
| slowdown would come more from the number of simultaneous transactions
| (users pegging away at the db) rather than the absolute number of
| transcations…)
±–>8
SPARC Ultra 5, Solaris 2.6.
MySQL gets severe indigestion if there are too many simultaneous updates.
I have some serialization in front of the RT mail queues to try to avoid
this, but I’m hoping to migrate to a different database engine for RT2.
Aside from that, well, indexes are your friends.
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]
The serial number we are at now is 619 and we’ve been running RT for about
a month. I expect this to go into the 10s of thousands eventually. The
last tracking app we were using was up to 7000 or more within about 5 months.
I use RT for the support mail, abuse complaints, internal fixes and
requests for service. Its great because I can take the networking problems
and requests for services but then I can assign the support mail and abuse
complaints to our technical support department.
I’ve also setup several different support mail queues because we have
several different companies that we want to “appear” as. This makes the
auto-email reply with correct contact information and a customized company
auto-reply email.
Warehousing is definitely going to be a required function, even though the
database is running on a very fast Sparc machine with 1GB of RAM.
MySQL gets severe indigestion if there are too many simultaneous updates.
I have some serialization in front of the RT mail queues to try to avoid
this, but I’m hoping to migrate to a different database engine for RT2.
Aside from that, well, indexes are your friends.
I have been told by the great minds at mysql.com that the indexes are what
slows down the updates… since it has to rewrite the indexes at every
update. How to other engines handle this?
Most of RT’s overhead is on searching, not on updates. RT does relatively
few updates compared to the the large number of searches.On Thu, Oct 26, 2000 at 10:50:21AM -0700, bill@daze.net wrote:
MySQL gets severe indigestion if there are too many simultaneous updates.
I have some serialization in front of the RT mail queues to try to avoid
this, but I’m hoping to migrate to a different database engine for RT2.
Aside from that, well, indexes are your friends.I have been told by the great minds at mysql.com that the indexes are what
slows down the updates… since it has to rewrite the indexes at every
update. How to other engines handle this?
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
“That package looks like what I wanted, but the site was down today,
so I decided to reimplement it in Perl.”
-me
Most of RT’s overhead is on searching, not on updates. RT does relatively
few updates compared to the the large number of searches.
And since mysql is about the fastest db engine when reading, this makes RT
very fast. Thanks!
JOC, what kind of hardware are you running on? (i’m guessing the real slowdown
would come more from the number of simultaneous transactions (users pegging away
at the db) rather than the absolute number of transcations…)#27892 just came rolling in a few minutes ago. Still snappy.
#17427 on an old slow pc with no performance problems…
and rt is not the main thing on this machine;)
robert
JOC, what kind of hardware are you running on? (i’m guessing the real
slowdown would come more from the number of simultaneous transactions (users
pegging away at the db) rather than the absolute number of transcations…)
We’ve just hit #22910, and it’s pretty fast on a PII-333, SCSI2, and 256MB RAM.
Jeffrey H. Johnson - jeff@websitefactory.net - System Administration - TrN
Barnet Worldwide Enterprises - The Website Factory - www.websitefactory.net