[rt-users] Optimize system specifically for RT

[Rob Munsch]

While by no means an expert, i noticed some stuff:

> In more detail, Gateway E4100 desktop with Pentium4/2.8GHz w/Hyperthreading enabled, 4x256MB

> -------- Performance Metrics -------------------------------------------------
> [!!] Maximum possible memory usage: 1.2G (120% of installed RAM)

You have a gig of ram on the box, and the !! here is telling you your
current vars allow MySQL to grab 1.2 GB.  Unless / until you increase
the box's ram, you need to lower the various buffers significantly, as
there's still system/OS mem to consider.

>    Reduce your overall MySQL memory footprint for system stability

That's what it's sayin' here.

>    When making adjustments, make tmp_table_size/max_heap_table_size equal

This just means what it says: if you tweak one to X, make sure the
other is also exactly X.

>  *** MySQL's maximum memory usage is dangerously high ***
>  *** Add RAM before increasing MySQL buffer variables ***

Again talking about your lack of RAM, and saying "Don't do what we
recommend below until you add some!"

>    tmp_table_size (> 32M)
>    max_heap_table_size (> 16M)

In this section, it means "adjust these variables HIGHER," greater
than their current values, which are 32 and 16M respectively.
However, as per previous 2 warnings: 1) you can't adjust anything
higher right now, until you lower the other buffer values, since
you're asking for more total RAM than you physically have; and 2) when
you adjust these, make sure they're the same size.  So, assuming you
had more RAM, you'd want to kick tmp_table_size up above 32M; and when
you do, make sure max_heap_table_size is adjusted to the same number.

> Checking MySQL for
>        mysql> show variables like 'tmp_table_size';
>        | tmp_table_size | 33554432 |
>        mysql> show variables like 'max_heap_table_size';
>        | max_heap_table_size | 16777216 |

The recommendations show you this: they say "make it greater than <the
current amount>."



> I can't add RAM the box is full.  I figure 4x256MB of slow RAM is better than 2x256MB of DDR400 (1GB slow is better than 512MB of faster RAM.)

if you have 4 slots, and they have quarter-gig sticks in them, why
wouldn't you be able to chuck them and get new sticks?  Even if you
just replaced them with half-gig sticks - dirt cheap - you'd double
your RAM.

better yet, get gig sticks.

> I'm not sure if it's telling me to set tmp_table_size and max_heap_table_size both to less than 16M.  Since it says they should be the same, and the heap is being flagged as being >16M, I was thinking of setting them both to 12M.

It's saying to make them both greater than 32M.  The recommendation
for the larger is "make it greater than the current value of 32M," and
"keep them both the same," with the caveat "but not until you do
something about your total RAM usage."

> The /etc/my.cnf is mostly, along w/stuff about password and whatnot that I don't think matter for this particular thread.  Mostly pulled from "my-large.cnf" example, disabling federated and bdb, and enabling innodb by uncommenting the lines.

> key_buffer = 256M
> myisam_sort_buffer_size = 64M
> query_cache_size= 16M

This is your only current option to reduce usage right now, and i
don't know how much room you have not knowing your DB's habits.  Try
gently lowering these if more physical RAM is impossible for whatever
reason, and restarting MySQL.

> # You can set .._buffer_pool_size up to 50 - 80 %
> # of RAM but beware of setting memory usage too high
> innodb_buffer_pool_size = 256M
> innodb_additional_mem_pool_size = 20M
> # Set .._log_file_size to 25 % of buffer pool size
> innodb_log_file_size = 64M

Same 'ere.

> I'm not sure if perceived "slowness" is due to webserver or MySQL or something else.  And partly, it's just

It's possible that MySQL is getting into fistfights with your system
for RAM right now, due to all of the above.

Hope this all helps in some way.


-- 
/chown -R us:us /yourbase