Max_allowed_packet. The max_allowed_packet variable is used to control the maximum size of a query sent to MySQL. It’s function is fairly well defined in the manual but there is a significant gotcha that exists when changing the size of max_allowed_packet while using replication. When the replication threads are created the global max_allowed_packet value is copied in to the thread context like doing a set session command in the slave connection. This is done because replication enforces max_allowed_packet a bit differently than other threads. It accounts for both the size of the packet and the overhead of the replication header.
This makes the max_allowed_packet enforcement accurate in replication but it means that the slave thread won’t account for set global max_allowed_packet=N until replication is restarted. I think this has flown under the radar because as soon as the slave hits a query that is larger than max_allowed_packet the i/o thread dies. Last_Error: Could not parse relay log event entry. Utf8_general_ci vs utf8_unicode_ci. Innodb buffer. November 3, 2007 by Peter Zaitsev39 Comments My last post about Innodb Performance Optimization got a lot of comments choosing proper innodb_buffer_pool_size and indeed I oversimplified things a bit too much, so let me write a bit better description.
Innodb Buffer Pool is by far the most important option for Innodb Performance and it must be set correctly. I’ve seen a lot of clients which came through extreme sufferings leaving it at default value (8M). So if you have dedicated MySQL Box and you’re only using Innodb tables you will want to give all memory you do not need for other needs for Innodb Buffer Pool. This of course assumes your database is large so you need large buffer pool, if not – setting buffer pool a bit larger than your database size will be enough. You also may choose to set buffer pool as if your database size is already larger than amount of memory you have – so you do not forget to readjust it later.
The third important memory consumer would be OS cache. Innodb_flush_method. Properties: Description: This variable changes the way InnoDB open files and flush data to disk and is should be considered as very important for InnoDB performance.
By default, InnoDB uses fsync() (without O_DSYNC) to flush both log and data files. Setting this variable to O_DIRECT will result in InnoDB using O_DIRECT while opening files and fsync() to flush both data and log files. O_DIRECT is useful when an application maintains it's own caching mechanism which is very well true for MySQL/InnoDB. O_DSYNC makes InnoDB to use O_SYNC to open and flush the log files, and uses fsync() to flush data files. For Windows, the flush method is always async_unbuffered. Recommendation: If you are not doing anything unusual like SAN storage etc (which otherwise also you should reconsider before doing), always use O_DIRECT for this. Read More: System performance benchmark. Sort. August 18, 2007 by Peter Zaitsev26 Comments I took the same table as I used for MySQL Group by Performance Tests to see how much MySQL can sort 1.000.000 rows, or rather return top 10 rows from sorted result set which is the most typical way sorting is used in practice.
I tested full table scan of the table completes in 0.22 seconds giving us about 4.5 Million of rows/sec. Obviously we can’t get sorted result set faster than that. I placed temporary sort files on tmpfs (/dev/shm) to avoid disk IO as a variable as my data set fits in memory anyway and decided to experiment with sort_buffer_size variable. The minimum value for sort_buffer_size is 32K which gives us the following speed: Not bad ! Mysql> show status like "sort%"; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Sort_merge_passes | 321 | | Sort_range | 0 | | Sort_rows | 10 | | Sort_scan | 1 | +-------------------+-------+ 4 rows in set (0.00 sec) Wait it is not right. Nope. Datadir.