技术细节

  • 在前述的文章(参考)中,我们实现了带有一个隐藏层的神经网络,并使用该神经网络对手写数字0/1进行识别。本文对该神经网络的识别效果以及相关的超参数的配置做一些分析与优化。

    这里涉及的超参数包括了学习率、迭代次数、隐藏层神经元的个数,这里对这三个参数的不同取值进行了相关测试,并观察训练时间与模型效果。

    不同学习率的模型训练

    学习率应该是这里最为重要参数了。在相同的迭代次数下(这里取500),不同的学习率展现出了非常大的差异。这里从0.001开始、尝试了:0.001、0.005、0.01、0.1、0.5等取值。详细的数据如下:

    可以看到,不同的学习率展现出了训练效率的差异非常大:

    • 在相同的迭代次数(均取500)情况下,学习率增加到0.1之后,预测错误率降低到了0.09%,并且再增加学习率,预测错误率并没有提升
    • 在学习率,从0.001增加到了最后的0.5之后,在进行了相同的迭代次数时,训练的目标函数取值下降一直都较为明显

    学习率如何影响目标函数的收敛速度

    右图展示了学习率取值分别为0.1和0.01时,目标函数的收敛速度趋势图。可以看到:

    • 学习率为 0.1 时,在迭代约40次以前,目的函数的收敛速度非常快,并快速的收敛到了非常低的水平
    • 学习率为0.01时,迭代到100次时,代价依旧非常高

    从这次实现代码也可以看到,学习率对于模型的训练效率有这至关重要的影响。如果学习率选择不合适,则会耗费大量计算资源进行非常慢的训练。那么,如果选择合适的学习率以进行更加高效进行梯度下降迭代,这是一个比较复杂的问题,这里暂时先挖个小坑在这里,待后续再做更多讨论。

    迭代次数 epoch 如何影响模型

    这里选取学习率为0.01,隐藏层10个人工神经元,从而观测随着“迭代次数”效率如何影响:

    可以看到,当迭代不够充分时,目标函数收敛还不够时,模型效果也会比较差。随着迭代次数不断增加,目标函数下降就不再明显了。完整的目标函数收敛趋势如下图:

    隐藏层神经元个数与模型效果

    这里观察隐藏层神经元个数与模型效果趋势图。这里分别测试了1、10、50、100、150、300个神经元时候模型的表现,如下图:

    从测试来看,在这个案例中,随着隐藏层神经元个数的增加并不会提升模型性能的。这可能暗示了,此类任务(图像识别相关)使用前馈神经网络时,其性能可能较差。

    部分识别失败的图片

    在该模型与训练下,部分识别失败率比较高的图片如下:

    9879
    8325
    9634
    3073
    2185

  • 关闭 InnoDB 的 redo log

    ·

    在 MySQL 实例恢复时(尤其是逻辑备份的恢复),为了获得更快的恢复速度,通常会关闭二进制日志(Binary Log),并且将 InnoDB 的日志持久化级别调整到最低。从 MySQL 8.0.21起[1],更进一步的,可以彻底的关闭 InnoDB redo 从而获得更好导入速度。后续的 8.4 / 9.0 / 9.1 可以使用该特性。

    在本文的测试中,可以看到关闭 InnoDB redo log 导入速度可以提升约 26%

    使用场景

    最为常见的就是在进行大量数据导入时,希望能够加速数据导入的过程。

    管理命令

    可以使用如下的命令关闭/或打开 InnoDB redo log:

     ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG

    关闭 InnoDB redo log

    mysql>  ALTER INSTANCE DISABLE INNODB REDO_LOG;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> SHOW STATUS LIKE '%Innodb_redo_log_enabled%';
    +-------------------------+-------+
    | Variable_name           | Value |
    +-------------------------+-------+
    | Innodb_redo_log_enabled | OFF   |
    +-------------------------+-------+
    1 row in set (0.02 sec)
    
    

    打开 InnoDB redo log

    mysql> ALTER INSTANCE ENABLE INNODB REDO_LOG;
    Query OK, 0 rows affected (1.02 sec)
    
    mysql> SHOW STATUS LIKE '%Innodb_redo_log_enabled%';
    +-------------------------+-------+
    | Variable_name           | Value |
    +-------------------------+-------+
    | Innodb_redo_log_enabled | ON    |
    +-------------------------+-------+
    1 row in set (0.00 sec)

    执行该命令的权限

    因为该命令对数据库影响巨大,所以也引入独立的权限 INNODB_REDO_LOG_ENABLE来管理该命令的执行权限。具体参考:

    mysql> GRANT INNODB_REDO_LOG_ENABLE ON *.* to 'data_load_admin';

    性能对比

    这里做应该简单的性能对比,看看关闭 InnoDB Redo Log 导入速度会提升多少。

    # mysql -uroot test -e "show status like 'Innodb_redo_log_enabled'"
    +-------------------------+-------+
    | Variable_name           | Value |
    +-------------------------+-------+
    | Innodb_redo_log_enabled | ON    |
    +-------------------------+-------+
    #  mysql -uroot test -e "truncate table passenger"
    # time mysql -uroot test < passenger.1000.sql > /dev/null
    
    real	0m3.109s
    user	0m0.017s
    sys	0m0.013s
    # mysql -uroot test -e "truncate table passenger"
    # mysql -uroot test -e "ALTER INSTANCE DISABLE INNODB REDO_LOG"
    # time mysql -uroot test < passenger.1000.sql > /dev/null
    
    real	0m2.286s
    user	0m0.022s
    sys	0m0.009s

    在这个初步测试中,可以观察到,在关闭 InnoDB Redo 之后,到如时间从 3.109s 降低到了 2.286s,在该导入中,节省时间约 26%的时间。

    参考文档

  • 在不同的云厂商,购买相同规格的MySQL实例(如4vCPU-16GB),获得的性能相同吗?

    dataaliyun_202409_hangzhou->stdbenchtencent_202409_beijing_exclusive->stdbenchhwcloud_202409_beijing_x86->stdbenchbaiducloud_202409_beijing->stdbenchaws_202409_tokyo_m6i->stdbenchazure_202409_east_asia_4c16g->stdbenchgcp_202409_tokyo_80_enterprise->stdbenchoci_202409_tokyo_8039->mysql_on_4_ecpu
    47102559225572206163920257233551
    897029936467441013313365413415936
    161466016141822972986427654825028054
    3222155223361352012022121571036348578317
    4827905247701784916448165161197367458130
    6432704264952011418187181181276180717838
    9636846290772088321007207821330096758504
    128396972991820128210292244613388106208198
    192389993061020521220912259013478115078043
    256383563105221187216652232312985118727907
    384396793122421729211672190212904121318209
    512403333180522647216272159112930121068386
    cpu_capacity80.493.3163.673.9110.956.349.9114.7

    测试结果概述

    在本次测试中:阿里云RDS MySQL性能表现最好,极限的QPS达到了4万;其次是腾讯云,达到了3.2万;第二梯队是华为云、百度云和AWS,极限的QPS约2.2万;之后是Azure、Google云,极限QPS约1.2万;最后是Oracle云,极限QPS约8500。详细的数据和趋势图,可以参考以上的图、表,这里不再详述。

    (more…)
  • 近日,MySQL发布了8.4版本,这是一个新的稳定版。在MySQL版本规划中,在2026年8.0.x生命周期结束后,将成为下一个主流稳定版本。

    目前为止,看到该版本并没有特别大的改进。部分改变包括改进了直方图统计信息更新、并行复制、组复制(GR)等,完整的更新可以参考:Changes in MySQL 8.4.0 (2024-04-30, LTS Release)

    MySQL 8.4@OCI性能测试(vs MySQL 8.0)

    Oracle Cloud上也第一时间支持了该版本,于是也通过性能测试的方式,第一时间“尝鲜”了一下该版本。性能测试的趋势图如下:

    注意到,在该Sysbench测试模式下:

    • 当前MySQL 8.4在性能上相对于8.0版本,要低21%(以16并发为参考)
    • 并在超高并发时(并发高于192),性能出现了严重的退化

    作为一个稳定版本,期待官方尽快解决。

    (more…)
  • 在Oracle Cloud Infrastructure(简称OCI,也就是Oracle云)上购买MySQL实例,也会有第三代CPU和第四代CPU规格的选择,分别是:MySQL.VM.Standard.E4.2.32GBMySQL.VM.Standard.E3.2.32GB。本文对比两个版本规格的价格与性能,以供参考。

    结论概述

    E4(AMD EPYC 7J13)、E3(AMD EPYC 7742)同属于AMD系列的CPU,E4似乎主要是在OCI平台,E3较为通用。从性能测试上,可以看到,E4相比于E3有着较为明显的性能优势,以常见的16并发时数据为参考,则E4(MySQL.VM.Standard.E4.2.32GB)相比于E3(MySQL.VM.Standard.E3.2.32GB)性能要高11%。

    这也与之前的,“新一代CPU总是有着更高的性能”的结论一致。

    (more…)
  • 个人的一些脚本和代码,经常会分散在不同的地方,管理起来并不方便,例如给WordPress编写的Plugin、测试MySQL时使用的一些脚本等,所以打算全部使用GitHub管理起来。对于个人使用,GitHub提供了私人仓库以存储代码,可以较为方便的管理一些还没有公开的个人代码。

    建立个人Git和GitHub环境

    GitHub CLI是一个具体简单交互式操作的命令行,可以完成与GitHub相关的一些交互与操作。对应的软件包/命令是gh

    安装gh-cli

    参考:Installing gh on Linux and BSD。Amazon Linux 2上安装:

    sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
    sudo yum install gh

    使用gh配置GitHub授权

    接着,就可以使用gh auth login命令来进行GitHub的认证了(gh cli manual)。这是一个简单的交互式命令,这里使用https+token的方式完成认证(也可以使用浏览器的方式辅助完成命令行认证):

    gh auth login
    ? What account do you want to log into? GitHub.com
    ? What is your preferred protocol for Git operations on this host? HTTPS
    ? Authenticate Git with your GitHub credentials? Yes
    ? How would you like to authenticate GitHub CLI? Paste an authentication token
    Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
    The minimum required scopes are 'repo', 'read:org', 'workflow'.
    ? Paste your authentication token: *********************************************************************************************
    - gh config set -h github.com git_protocol https
    ✓ Configured git protocol
    ! Authentication credentials saved in plain text
    ✓ Logged in as orczhou

    关于Token的配置与获取,可以参考:GitHub->Settings->Developer Settings ,这里不再详述。注意,Token意味着分配的所有的仓库权限,必须妥善保管,否则可能会带来巨大的安全隐患。

    如果要登出的话,则可以简单的使用如下命令:

    gh auth logout

    在本地pull与push仓库

    • 首先,在git中配置本地身份(用户名与)
    git config --global user.name "orczhou"
    git config --global user.email "orczhou@orczhou"
    • 首先,新建一个本地模板,并使用git命令初始化
    mkdir  terraform && cd terraform
    git init
    • 配置远端(remote)分支;并拉取远端代码
    git remote add origin https://github.com/orczhou/cloud-mysql-benchmark.git
    git pull origin main

    向远端push代码

    这时,如果修改了仓库中的代码,则可以使用push命令向远端发起提交请求。

    修改、测试并本地提交代码:

    vi gcp_rds_ins/all_in_one/README.md
    git add gcp_rds_ins/all_in_one/README.md
    git commit -m "gcp readme updated"

    向远端push修改:

    git push -u origin main

    该操作会向远端仓库的main分支,提交代码。

    向main分之合并代码

    可以在GitHub仓库页面,对比并创建一个pull request。

    发起pr之后,代码仓库则可以进行merge操作,将代码合并到main分之。

    在新增远程代码库(origin)

    git remote add origin https://github.com/orczhou/testing-delete-repo-if-u-like.git

    将本地代码,提交到远程代码库(origin)的main分支:

    git push -u origin main

    上面的,-u origin main ,其中-u参数表示push的目标代码库-u | --set-upstream

    在现有仓库的main分之上开发

    经常需要做这个动作,常用的命令比较简单,这里记录如下:

    mkdir repo_bench && cd repo_bench
    git init
    git branch -M main
    git remote add origin https://...
    git pull origin main
    
    

    直接修改本地main中的代码并提交到源端:

    cat "..." > README.md
    git add README.md
    git commit -m "first commit" --dry-run
    git commit -m "first commit"
    git push -u origin main

    使用gitignore忽略文件

    在代码开发过程中,由于编译、运行等原因会产生很多的中间文件,而这些中间文件时无需提交到代码仓库的。这时候,需要使用gitignore来忽略这部分文件。详细完整的gitignore的使用可以参考man gitignore

    常用的gitignore是可以通过.gitignore文件来实现,即在代码的根目录中新建该文件,那么在代码处理时,就会根据根据该文件的规则进行忽略。例如Terraform脚本常用的gitignore文件可以参考:

    所以,一个Terraform脚本的.gitignore可以依次作参考:

    # Compiled files
    *.tfstate
    *.tfstate.backup
    *.tfstate.lock.info
    
    # Directories
    .terraform/
    .vagrant/
    
    # SSH Keys
    *.pem
    
    # Ignored Terraform files
    *gitignore*.tf

    master分支与main分支

    在搜索git/github的相关资料的时候,经常还会搜索到master分支作为主分支的资料或者仓库。在2020年的George Floyd的案件发生后,美国的Black_Lives_Matter运动达到了前所未有的高度,最终也影响到在计算机领域的master/slave 一词的使用。更多的参考:Renaming the default branch from master@GitHubWhy GitHub renamed its master branch to main@theserverside

    不过,git在本地默认还是使用默认的master分支,所以如果没有手动切换分支,则还是会经常“默认的”创建master分支。

    查看未提交的修改

    git面向的场景就是分布式、多任务的开发代码管理,其独特的”three tree“模型可以很巧妙的实现这些能力。这也给初学者带来了很多理解上的障碍。

    git diffgit diff HEAD

    如果,想要查看自上次commit以来的所有变更,则需要试用git diff HEAD命令,通常HEAD指向的是,最后一次commit时的位置。

    # diff between "working" and "staging"
    git diff
    # diff between "working" and "repository"
    git diff HEAD
    # diff between "staging" and "repository"
    git diff --cached

    同步远程更新

    个人代码仓库管理中,有时候会有这样的情况:直接在远程仓库中修改了一些文件,然后如何让本地和远程保持同步。考虑这样的场景:直接在GitHub上对README.md文件进行了编辑,那么本地代码仓库如何保持这个更新。

    当然,这样做,通常可能会很危险:可能会覆盖掉你本地所做的更改,但是基于上面的场景,所以,有时候会需要这么做。Stackoverflow上有几个相关的问题,非常详细的介绍了做法:

    这里的推荐做法是这样,如果本地仓库的修改确定不要了(通常这是很危险的):

    git pull

    如果本地仓库修改都还需要:

    git stash
    git pull 
    git stash pop

    还可以:

    • 先使用 git fetch更新origin/main
    • 然后使用git diff main origin/main查看本地与远程的差异
    • 最后使用git mergeorigin/main与本地合并,并保持在本地

    这样origin/main是最新的,且本地分支也是最新的了

    git fetch
    git diff main origin/main
    git merge

    参考链接