[MySQL 5.6] innodb_flush_method新值O_DIRECT_NO_FSYNC 及bug#68555

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。


讨论还在继续,持续关注中….

update @3月8号

Mark 提交了一个新bug#68588, fil_flush中sleep的时间过长

原创文章,转载请注明: 转载自Simple Life

本文链接地址: [MySQL 5.6] innodb_flush_method新值O_DIRECT_NO_FSYNC 及bug#68555

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *