Facebook的Mark大神最近一直在测试5.6的性能，并且发现了不少问题. 看来Facebook是要跳过5.5，直接上5.6了。同为互联网行业，Facebook的许多需求和我们是类似的，online ddl， 热点数据更新问题等。。。
当然，我最关注的还是5.6存在的bug。
related blog:
http://mysqlha.blogspot.com/2013/03/mysql-56-cached-update-only-workload.html
http://mysqlha.blogspot.com/2013/03/mysql-56-no-odirectnofsync-for-you.html
related bug:
http://bugs.mysql.com/bug.php?id=45892
提到两个问题，一个是从5.6.7开始innodb_flush_method有一个新值：O_DIRECT_NO_FSYNC。他的含义也很简单。当文件被设置为O_DIRECT时，如果将其设置为O_DIRECT_NO_FSYNC时，就无需在写文件后，再做一次flush（实际上是随后的调用逻辑性能太差了，而不仅仅是fsync很慢的缘故）。
从函数fil_flush可以很清晰的看到，fil_buffering_disabled为true时，很快就释放全局锁fil_system->mutex，返回。根据mark的测试，其性能提升也非常理想：
update-only & IO-bound workload
updates/second for update 1 row by PK via sysbench
8 16 32 64 128 256 concurrent clients
18234 24359 10379 9795 9843 10283 O_DIRECT
17996 26853 30265 28923 29293 29477 O_DIRECT_NO_FSYNC
可惜的是，这种设置只对部分文件系统是安全的，一些文件系统，例如XFS,即使设置了O_DIRECT，还需要将Metadata信息fsync到磁盘。另外当free list为空时（脏页太快，Page cleaner跟不上），用户线程可能去从LRU获取一个空闲block，这会导致如下backtrace。
os_thread_sleep,fil_flush,fil_flush_file_spaces,buf_flush_sync_datafiles,
buf_flush_single_page_from_LRU,buf_LRU_get_free_block,
buf_page_init_for_read,buf_read_page_low,..
这种场景发生在IO-BOUND负载下，即使在扫描lru也没有发现非脏block可以转移到free list后，会去尝试从lru尾部刷一个脏block（buf_flush_single_page_from_LRU），然后将其放到free list上，这其中如果包含了sync操作，显然会大大的影响用户线程的性能。
第二个问题是，Mark在测试的过程中，发现多个bp instance场景下，产生了性能倒退(bp instance 从1到8，qps性能下降了差不多1倍)，详细见http://bugs.mysql.com/bug.php?id=68555）, backtrace如下：
buf_flush_list, log_preflush_pool_modified_pages, log_checkpoint_margin, log_check_margins, log_free_check, row_upd, row_upd_step, row_update_for_mysql, ha_innobase::update_row
当更新记录时，由于要写redo log，需要确保buffer有足够的空间(log_free_check)，是否需要刷日志由log_sys->check_flush_or_checkpoint来标记，当为true时，表示可能有log需要刷磁盘，或者需要 preflush buffer pool page，或者需要做一次checkpoint。当lsn – last_checkpoint_lsn >max_checkpoint_age时候，这个值必须为TRUE。
注意在log_free_check中检查check_flush_or_checkpoint时未持有log_sys->mutex。
在判断是否需要做checkpoint时（log_checkpoint_margin），如果脏页的LSN范围（从每个bp instance的flush list上查看）大于max_modified_age_sync了，需要去做刷脏页操作（log_preflush_pool_modified_pages）
Mark指出的问题是，如果有线程在做flush，后来的线程进入log_preflush_pool_modified_pages，轮询每个Bp instance，如果每个bp都正在做flush，那么就会返回false，可能会去强制将log_sys->check_flush_or_checkpoint设置为TRUE，后面新来的线程因此可能持续的进入log_preflush_pool_modified_pages->buf_flush_list函数去轮询每个bp instance，有任意一个bp instance正在被刷新，都会导致返回值为false。线程在将log_sys->check_flush_or_checkpoint这样一个全局可见的变量设置为true后会继续loop。
讨论还在继续，持续关注中….
