Hi!
>>>>> "Peter" == Peter Zaitsev <pz@stripped> writes:
Peter> Hello mysql,
Peter> [root@samson /root]# mysqladmin processlist | grep -v Sleep
Peter>
> +------+-------+---------------+---------+---------+-------+----------------------+------------------------------------------------------------------------------------------------------+
Peter> | Id | User | Host | db | Command | Time | State
> | Info
> |
Peter>
> +------+-------+---------------+---------+---------+-------+----------------------+------------------------------------------------------------------------------------------------------+
Peter> | 3 | titan | mars.local | counter | Query | 10 | closing tables
> | INSERT INTO st50.g00hits
> (counter_id,visitor_id,page_id,referer_page_id,browser_id,display_id,option |
Peter> | 2001 | root | localhost | st50 | Query | 9 | Flushing tables
> | flush tables st50.g00hits
> |
....
Peter> As you see here after flushing of the table which has a lot of not
Peter> flushed keyblocks (with delay_key_writes=1) has been started, after
Peter> that even really quick query, which just finds one row by a key takes
Peter> much time.
Peter> Well. Hope this problem also will be resolved by new keycache patch.
Most of this will be fixed with the key cache patch, but unfortunately
not everything; Your example shows that we will still have a problem
with how tables are closed with flush-tables. We have to plan a
little of how to get this problem solved nicely (This is however much
easier than the key cache problem)
Regards,
Monty
