Large tickets in RT

Hi.

Just wondered if anyone have successfully put tickets with attachments
larger than 16 MB into RT? I’m having huge troubles with this (Getting
"[Tue Jun 17 20:18:55 2003] [warning]: DBD::mysql::st execute failed:
Got packet bigger than ‘max_allowed_packet’ at
/usr/local/share/perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 410."
Even though I’m using mysql 4.0.13 (which is suppose to have a max
limit of 2 gb) , and has configured max_allowed_packet to be 200M …

zeus:/opt/rt3/var/log# mysqld --help|grep max_allowed_packet
–max_allowed_packet=#
max_allowed_packet 209714176

That is, when I get this far. I’ve also seen mailgate die with “Out of
Memory”, and the Apache instance which handles these mails stalls with
99% cpu use and heavy memory use for a few minutes whenever I test
these things before I eventually get the message over. This is kind of
critical for us, since we use RT to accept advertisements for our
weekly publication. If I can’t fix this soon, we’ll be forced to go
back to Exchange Public Folders (angst).

Marcus

Hi.

Just wondered if anyone have successfully put tickets with attachments
larger than 16 MB into RT? I’m having huge troubles with this (Getting
“[Tue Jun 17 20:18:55 2003] [warning]: DBD::mysql::st execute failed:
Got packet bigger than ‘max_allowed_packet’ at
/usr/local/share/perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 410.”
Even though I’m using mysql 4.0.13 (which is suppose to have a max
limit of 2 gb) , and has configured max_allowed_packet to be 200M …

zeus:/opt/rt3/var/log# mysqld --help|grep max_allowed_packet
–max_allowed_packet=#
max_allowed_packet 209714176

That is, when I get this far. I’ve also seen mailgate die with “Out of
Memory”, and the Apache instance which handles these mails stalls with
99% cpu use and heavy memory use for a few minutes whenever I test
these things before I eventually get the message over.

Perhaps your system ulimit for RT’s processes is limiting the process
size.

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Even though I’m using mysql 4.0.13 (which is suppose to have a max
limit of 2 gb) , and has configured max_allowed_packet to be 200M …

Can you check the version of the client library used by DBD::Mysql ?
It could be an older installation from MySQL3.xx times.

That is, when I get this far. I’ve also seen mailgate die with “Out of
Memory”, and the Apache instance which handles these mails stalls with
99% cpu use and heavy memory use for a few minutes whenever I test
these things before I eventually get the message over.

This is to be expected, all data is held several times in memory.
Using Postgres would be somewhat worse because Postgres will not accept
NUL-Bytes in Records and RT creates another base64 encoded copy of the
data.

Greetings,
,eM"“=. a”-. Michael van Elst
dWWMWM" - :GM==; mlelstv@dev.de.cw.net
:WWMWMw=–. "W=’ cable & wireless
9WWMm==-.
“-Wmw-” CABLE & WIRELESS

Even though I’m using mysql 4.0.13 (which is suppose to have a max
limit of 2 gb) , and has configured max_allowed_packet to be 200M …

Can you check the version of the client library used by DBD::Mysql ?
It could be an older installation from MySQL3.xx times.
Indeed it could, and it was. I had just been checking that I had the
latest D::m . You just saved my day! Remember to collect your
complimentary beer the next time you visit Oslo :slight_smile:

That is, when I get this far. I’ve also seen mailgate die with “Out of
Memory”, and the Apache instance which handles these mails stalls with
99% cpu use and heavy memory use for a few minutes whenever I test
these things before I eventually get the message over.
This is to be expected, all data is held several times in memory.
Using Postgres would be somewhat worse because Postgres will not accept
NUL-Bytes in Records and RT creates another base64 encoded copy of the
data.

Indeed, it is still slow on large attachments (like 5-10 min on 17
megs), but at least it’s stopped eating my tickets. Now I won’t have to
be punished with Exchange :smiley:

Marcus.