尝试把 WordPress 从 5.2 版本 升级到 6.6 版本，把 PHP 从 7.4 版本升级到 8.3 版本。

任务艰巨得完成不了。

非常的崩溃。

前提

我现在的线上的博客，以及线下的开发环境，以及（如果还在不为我知的某个角落存在的话）商用用环境，都是 PHP 7.4 的。

最早些时候，应该算是2015年，正式入坑 PHP ，那时候基本是公司用啥，我用啥。PHP 5.2 5.4 5.6 都用过了，尤其是 5.2 大坑一大堆，摔过很多次。然后到 2016 年的时候终于用上了革新的版本 PHP 7.0。真爽。再后来开始自己独立开发环境，直接开了 DAMP 的坑，最初也是用的 7.0 版本，然后就很随意的升到 7.3 版本，主要是当时开发负担少。然后博客站也都升级到了 PHP 7.3。

再后来 2021 年接了一个外包项目。虽然当时 PHP 8.0 已经发布了，但是貌似周边支持都不怎么地。为了保证开发速度，直接用了 PHP 7.4 版本。当时还涉及到前端开发，Node环境也是大更新，很早之前一直用的各种热门前端库基本都死绝了。博客和本地开发环境也都升级到了 PHP 7.4，博客的 WordPress 程序倒是没变，还是 5.2 版本（这里埋了个大坑），只是偶尔会从官网下载代码包然后手动更新对应的文件，以修复些潜在的安全问题。

现在是2024年年末，就连PHP 8.0 都已经停止维护快满一年了，最新版本 PHP 8.3 也已经发布快满一年了。WordPress 都到了 6.6 版本了，一堆 WordPress 插件都已经停止 5.2 版本的支持了。

想趁着有时间有机会，把 PHP 和 WordPress 都升级了。

天真了。

第一天

首先是把线上的代码全备份一遍。这个毫无工作量，我之前写了个备份代码，直接就把自己的整站扒下来。然后把备份的站再部署到本地的开发环境上，再改几个数据库字段，就完事了。打开后台，先禁用所有插件，以便升级之需。

Apache2 和 MySQL 不用动，因为用的一直都是 Docker 的最新版本，这几年也没什么巨大的兼容性变化。

PHP 这块我不知道算不算麻烦。我把 PHP 从 7.4 到 8.3 的所有 不向后兼容变更 和 废弃功能 全都看了一遍。没多少，就几页，几分钟就看完了。个人感觉这么多变更，只有一条能实际影响到我日常开发工作，就是自 8.0 起不再支持 带有默认值的参数后面跟着一个必要的参数 。

其实个人工作中也很少这么用，因为易读性有点烂。论性能来讲的话这么写性能也很差，只不过以前工作过的公司里就有很多人这么写，主要是为了防止其他同事调用函数忘记传参（空参也是参）。

其余的改动基本影响不到我。我使用的基本都是 PHP 的官方建议用法，最多也就是会遇到某些外部库被遗弃然后有个平替的情况，比如数据库接口啥的，即使出错了立刻就能发现。

于是很自信的先把 PHP 环境升级到了 8.3 。因为是基于 Docker 的所以也完全不用担心环境污染的问题。

然后就崩了，WordPress 就打不开了。

这倒是意料之中，毕竟当年 WordPress 4.3 版本当年连 PHP 7.0 都不支持。我现在用的是 5.2 版本，最高能支持的 PHP 版本也才 7.3 ……

什么？7.3？但我已经用 PHP 7.4 跑了 WordPress 满 3 年了啊？？？

什么兼容性测试……

下载了个 wordpress-6.6.2 的包，按官方文档手动安装。 崩得一塌糊涂

全部删除了重新来，这回用官方的自动升级功能，直接从 5.2 升级 6.6。真神奇，WordPress 官网被墙了这么久了竟然能秒下 WordPress 的安装包，我也不知道他是走的什么渠道。PHP 就这点恶心，前台所有操作你都看不到任何细节，就像是在用 Windows 一样。

成功安装。然后 崩得一塌糊涂 。这回不仅崩得稀烂，而且由于没手工删除后台的旧文件，新旧文件混在一起，更是手足无措。

就这么搞了超过6个小时，一直干到后半夜三点多，搞不定。

放弃，睡觉。

然后严重失眠，抽搐。

第二天 白天

首先考虑下到底是 PHP 的问题还是 WordPress 的问题。

按理来讲我已经把 PHP 的升级文档都看完了，并没有什么会天塌一般的变更，但是 WordPress 这边的确天塌了。

先在 PHP 8.3 环境下运行一下我的其他项目看看，结果我的个人主页就崩了。

我用的是 2023 年 3.1.48 版本 的 Smarty，其基础版本是给 PHP 7.0 做的，可能旧了吧。

下载了最新版本的 smarty-5.4.1 ，然后

什么玩意？ implode is Deprecated ，我怎么不知道？

又去重新看了一遍 PHP.net 官网的 implode 文档和 PHP 升级文档。根本没有 Deprecated 。

然后在网上搜了一下，发现是 Smarty 的锅。而且 Smarty 还在 join 和 implode 之间反复横跳。更恶心的是，implode 和 join 在 PHP 7.4/8.0 中已经声明并废弃了 先数组后分隔符 的用法，但是在 Smarty 中却是强制要求 先数组后分隔符 ？甚至官方在 issue 里来来了句 Smarty is Smarty and PHP is PHP. 有病吧。而且你就算有病，你特么连个文档都没有，谁知道你有这种抽风的设计啊。

你要知道之所以我还用 Smarty 这种超级古董，就是因为这是一种 靠谱的、前后端分离、完全后端渲染、仅需要 HTTP 和 PHP 环境、不需要臃肿框架和特定语法，的网页渲染模式，是提供给搜索引擎最靠谱的传统模式。没有网页模板系统的话，想写这种纯后端渲染前端显示的页面，就只能 php 和 html 代码混写，非常的恶心。

现在 Smarty 抽风了，真就不知道以后还怎么不依赖框架写这种页面。我搜了下，Laravel 的 Blade ，和 Symfony 框架下的 Twig，貌似也可以独立使用，但是我对 Laravel 和 Symfony 基本一无所知，作为一个 PHP 开发者真是有点丢人。

话题扯远了，回到刚才。

我目前是不太想动我的个人主页的，这 WordPress 是大头，是主要内容。主页只是个入口。虽然主页改动起来并不困难，代码量少，Smarty 抽风的部分比较好找。但主页这一块我其实并不满意，主要是多语言这块用的传参而不是独立页面，很受搜索引擎嫌弃，基本上没收录，收录的也搜不到。但我的确没有精力和欲望去重做。

另一方面，WordPress这边，崩溃得最多的部分其实是插件。WordPress的代码质量本来就很堪忧了，第三方插件更是三脚猫，各种天花乱坠的不规范语法，可以说基本上都不能在 PHP 8.3 上运行。

另外我虽然看了 不向后兼容变更 和 废弃功能 ，但是 PHP 新版新增的语法糖也有点天花乱坠。我用的是最新版的 php-cs-fixer_v3.64.0 ，没配置好的话就会把那些插件的奇葩写法转写成 8.3 的语法糖，有时结果更是瞎眼，基本没有易读性。

综上考虑，先放弃 PHP 8.3 的升级。先把能通的条通。PHP 的升级难度应该不是最高的，但是底下这些撇不掉的小垃圾目前是必须要保且支持不到 PHP 8.3，没精力做修改。

放弃 PHP 8.3 继续用 PHP 7.4 。

第二天 晚上

看兼容性列表，WordPress 6.6 也是支持 PHP 7.4 的。

但是实际上 API 改动实在太大了，而 PHP 前端应用最恶心的一点，就是 出错了，不报错 。

即使开启了 define('WP_DEBUG', true); define( 'WP_DEBUG_LOG', true ); define( 'SAVEQUERIES', true ); ，也经常是

• 功能好像开了但是没开
• 功能好像崩了但是啥日志都没有
• 功能正常使用但是页面上打了一堆不知道哪里来的错误日志

面对如此大的一个工程而大部分代码逻辑都是不可靠的。升级到 6.6 实在是消受不起。

放弃 WordPress 6.6 ，只升级到比较近的版本。

要不然试试 5.5 吧，毕竟我在用的一款插件，作者自评最高支持到 5.5。

下了个 WordPress 5.5 的安装包，装完了。崩，但是崩得没有 6.6 多。

主题 graphene

不开插件，只看主题，首先就是文章的评论显示不出来。检查后发现是评论的API变了，而我的主题 graphene 是 1.9.4.3 版本的，不支持 5.5 。

有时候看其他人的代码就是折磨，代码里写法五花八门，空格TAB混着，一会拼接字符串，一会替换字符串。单引号双引号混着用，左边括号有空格，右边括号换行了。

说实话我都不知道这算不算改好了，反正现在是能显示出来。我更担心的是其实还有哪个不知道的角落还有错，但是看不到，毕竟 PHP 前端 出错了 不报错 。

官方倒是有个新版的 graphene，但是我现在用的这个主题就是我大量改动过的，因为 graphene 原版的代码实在是， 太错了 。好多代码完全不符合前端的理念。然后是颜色和界面也是要一点一点从设置里调，那复杂和麻烦程度，说真的我更乐意重写 HTML 和 CSS 。

我真的想过很多次自己做一个 WordPress 主题，这个想法可是足够老了。但是当时 WordPress 3 版本的主题文档就恶心到我了，真的超级麻烦。而到如今就 WordPress 现在的代码质量，我估计开发主题会更困难更恶心。

也是怪不得其他更轻量的博客程序能后追直上。

插件 Disable WordPress Core Updates

接下来是 Disable WordPress Core Updates 这个插件。

这个插件是为了禁用 WordPress 的界面更新的。但是其实只有一行有意义的代码：

add_filter( 'pre_site_transient_update_core', create_function( '$a', "return null;" ) );

首先 create_function 这个函数在 PHP 7.2 废弃，在 8.0 中删除，所以我改写成了。

add_filter('pre_site_transient_update_core', function ($a) { return null; });

然后就见证奇迹了。能用是能用，但是 pre_site_transient_update_core 这个字段我在整个 WordPress 代码中都没找到。为什么做一个 pre_site_transient_update_core add_filter 就能抑制 WordPress 界面提示升级？ 魔法啊？

然后开启这个插件的时候，更新页面是崩的。

魔法。

插件 NIX Gravatar Cache

接下来是 NIX Gravatar Cache 插件。

这是个把 Gravatar 头像缓存到本地服务器的插件，只不过早就死透了。我当时随便改了点代码对付着用，大部分时间没出错也就那样了。

首先是这段代码。（红色部分是我添加的改动）

不能直接执行 wp_enqueue_script 和 wp_enqueue_style ，要先执行个 add_action('wp_enqueue_scripts', 引用能调用那俩玩意的函数); 。外国人看这种超长的单词时不会眼花吗？

然后是这么一段代码。

WordPress 的 register_啥啥啥_hook(__FILE__, array($this, '函数名')); 写法全都作废了，要改成 register_啥啥啥_hook(__FILE__, array($this, '函数名'));

接下来底下那一节：

• 假如 路径不可写 且 路径为目录，报错

否则

• 假如 创建目录（权限777）失败 且 路径不为目录，报错

就这烂判断条件看得我脑子都快炸了也没弄明白为什么这破玩意能在我线上服务器上跑几年没报错，而我本地开发环境却根本跑不通。

而且这玩意讨厌就讨厌在于，确在我的测试环境下报错了，但是 WordPress 只是多了个 .php-error 的样式并且高出来 2em 的一节，但是一点错误日志都没有！！！ 出错了 不报错 。

最后还是靠自己写 debug 代码定位的问题。

这 TM 都是些不该是问题的问题，竟然多得到处都是。

2天，一点有效进展都没有。唯一有效收获就是这些屎山不碰就没事，一碰能崩得全身是屎。

反而自己写的没有引用那些垃圾玩意的插件和程序，没发现啥大毛病。

第三天

2天没啥进展，给我干懵了。

俗话说没事别升级，升级必出事。

原本的想法是先试着升级，如果不能平滑升级的话，大不了全摧毁了，然后把整个博客文章用导入的方法塞回去重建。如果插件出问题了，大不了找找看是否有新的替代品。结果搜了一下，靠谱的插件基本没有，一大堆商业推广的插件，和一大堆复合性插件，而且这些插件无论对 5.x 版本 还是 6.x 版本的兼容性都乱七八糟，问题解决不了，还有可能引入更多的问题。主题这边则是更不想换，一方面本身现在用的主题就是我大量修改过的，因为网上的各种主题，仅安全性就一塌糊涂，更别说 HTML 标准了。我这主题还是专门针对 1366×768 分辨率优化过的，能在 小屏幕 150% 比例正常显示。让我再去改个新的，工作量也是太大。

现在基本上没辙了。

PHP 这边其实还行，而且版本活跃度比较稳定。

在 https://packagist.org/php-statistics 能看出各版本使用占比都跟维护相关。但 7.4 版本 比 8.0 版本还受欢迎 属实乐了。

但是周边应用真的是质量山体滑坡。WordPress自 3.0 版本就开始崩，后面很多发展都很魔幻，就连编辑器都是靠社区兜底，到现在已经想不清楚这玩意的产品路线是啥了。

其他生态我也不清楚，毕竟作为一个 PHP 开发，我连 Laravel 和 Symfony 都没用过，商用产品都是用 ThinkPHP 应付的，当然最爽不过不依赖框架没有条条框框自己从头写。

但是像 Smarty 这种原行业标志都走奇葩路线了。可以说整个IT行业，基本上，正常的元老人物都退出舞台了，剩下的这些，刨去臭鱼烂虾，就只有偏执而扭曲了，假若走向歪路，那就没得旧，而这一点在开源社区上也极为明显（因为闭源商业的死不死没人关心），Godot 基金会开搞政治正确炮轰特朗普和动画头像用户，Linux 基金会直接开踢俄罗斯的代码贡献者。IT 行业现在就像是一个患了早期癌症的癌细胞轻微扩散病人，看似有救但却是谁都不想救。

结论

给我干哑火了，懵逼了，现在不知道咋整了。

　　Vaulwarden 是一个开源自托管的密码管理工具，这个项目使用 Rust 实现了一套 Bitwarden Server API， 很多小伙伴都用它来管理密钥与凭证。 本文将利用 fail2ban 来实现在 CDN 场景下的防暴力破解。

　　我们的部分后端服务正在经历容器化的改造， 由于历史包袱，现网的网关等设施无法一次性迁移到 k8s 集群中， 因此使用 Nginx proxy_pass 转发到 AWS ALB 这样一个曲线救国的临时方案。
　　但是在使用时，我们发现一段时间后 Nginx 出现了 504 的错误，检查后端服务均是正常的，而单独访问 ALB 也是正常响应的，因此便有了此文。

　　我们在远程办公时通常需要通过内部 OpenV** 来访问公司内部的敏感系统， 默认情况下， OpenV** 会临时修改本地路由表，将所有流量都指向了 v**_gateway，导致一些本地规则被覆盖，甚至无法打开部分国内的网站，带来了很多不便。这里记录一下手动指定路由规则的配置，仅让指定的网段或域名走 gateway。

　　众所周知，我们可以通过修改本地 hosts 文件来定义一个域名的指向，这个过程我们可以简单的理解为在本机创建了一个优先级很高的 DNS A 记录，实现了某种程度上的域名劫持， 利用这种特性我们可以实现诸如广告屏蔽、本地测试、别名等需求，但 hosts 机制仅仅能定义域名与 IP 对应关系， 并不能模拟其他的 Record 类型， 比如 CNAME 记录。

　　迫于无法忍受现成的 NAS 系统的限制，Alliot 正在着手将最常用的一些服务剥离出来，方便迁移与定制， WebDAV 首当其冲， Alliot 在许多场景下的同步与备份都依赖它。
　　WebDAV 作为一种基于HTTP/HTTPS协议的网络通信协议，预想是非常简单的，然而在具体动手的过程中还是遇到了挺多坑，Obsidian 的 Remotely-save 便是其中一个。
　　本文将基于 Nginx/Tengine 手把手构建一个 WebDAV 服务。

　　在工作中，常常会容易遇到一台电脑用多个 Git 账号的场景，比如账号 company 账号是工作用的，而账号 personal 是自己个人用的。 由于 Git 本身并没有多账号的机制，导致我们在默认设置下无法很好的区分哪个仓库使用哪个账号。 同时，在某些众所周知的场景下，我们无法直接访问到 Github 仓库，需要走一层 proxy 来加速我们的代码拉取与推送速度， 本文将使用 SSH config 相对优雅的解决这些问题。

　　一台服务器配置了 logrotate 来对 tomcat 日志进行切割，手动执行 logrotate /etc/logrotate.conf 的时候是正常,但是systemd timer 触发的 logrotate.service 状态为 failure， 手动执行 systemctl status logrotate.service 可以看到报错信息：logrotate[2870734]: error: error opening /usr/local/tomcat/logs/catalina.out: Read-only file system

为啥要停止 SSH 服务器监听 IPv6 地址？

　　许多同学家里都有软路由或者小型服务器，用来跑一些个人的小程序，或者跑 TeamTalk 等。现在 IPv6 已经基本普及，好处是每个设备甚至每个容器都能分配到一个公网 IP 地址，坏处也显而易见，那就是，之前靠路由器来充当防火墙的搞法已经不奏效了。为啥捏？因为之前基本都是在路由器上做端口映射，可以有选择地开放端口到互联网上，现在则是整个系统暴露到了互联网。

　　看到这里，聪明的同学应该都已经知道俺想表达的意思啦。没错，咱们都是通过 SSH 来控制服务器的，一旦它被入侵，后果是很严重滴！删库跑路还不是最大的问题，最大的问题是骇客潜伏在服务器里，三天两头搞些事情，如果你有很多的虚拟机，仅凭一己之力，是很难彻底跟踪入侵踪迹的。

怎么停止 SSH 服务器监听 IPv6 地址？

　　首先，通过终端/SSH 之类的方法登录你的服务器，并进入 /etc/ssh 目录，用 cp 命令备份一下 sshd_config 文件，具体命令俺就不多费口水了。备份好之后，用你习惯的编辑器打开 sshd_config 文件，比如俺喜欢用 nano 编辑器，命令是 nano sshd_config。

　　找到 #AddressFamily any 这一行，把前面的“#（警号）”删除，改成 AddressFamily inet。往下找到 #ListenAddress 0.0.0.0，再把前面的“#”删除。最后，保存 sshd_config 文件。

　　这还没完！要想让修改生效，必须重启 SSH 服务端软件，在 CentOS/Debian/Ubuntu 系统上，命令是 systemctl restart sshd，在 Alpine Linux 系统上，命令是 service sshd restart。

　　切记！先别断开 SSH 连接，一定要看刚才执行命令后是否有报错信息，如果有，赶紧恢复之前的备份，然后重新修改配置文件并再次尝试重启。

检查 SSH 服务器是否停止监听 IPv6 地址

　　当修改完成后，一定要有复查的习惯。咋复查捏？在有 IPv6 连接的内网电脑上，通过 SSH 连接服务器的 IPv6 地址，如果连接不上就表示修改成功了。为了避免误判，俺建议通过 ping 以及连接这台服务器的其他端口（例如 Web 端口）来再次确认。

本文整理了一些 Linux 时钟源 tsc 相关的软硬件知识，在一些故障排查场景可能会用到。

Fig. Scaling up crystal frequency for different components of a computer. Image source Youtube

水平及维护精力所限，文中不免存在错误或过时之处，请酌情参考。 传播知识，尊重劳动，年满十八周岁，转载请注明出处。

• 1 计算机组件的运行频率
  • 1.1 时钟源：~20MHz 的石英晶体谐振器（quartz crystal resonator）
  • 1.2 Clock generator：针对不同部分（内存、PCIe、CPU 等）倍频
  • 1.3 CPU 频率是如何从 ~20MHz 提升到 ~3GHz 的
    • 1.3.1 传递路径：最终连接到 CPU CLK 引脚
    • 1.3.2 CPU 内部：还有一个 clock generator
• 2 x86 架构的寄存器
  • 2.1 通用目的寄存器
  • 2.2 特殊目的寄存器
    • 2.2.1 model-specific register (MSR)
    • 2.2.2 MSR 之一：TSC
• 3 TSC（时间戳计数器）
  • 3.1 本质：X86 处理器中的一个 特殊寄存器
  • 3.2 作用：记录 cpu 启动以来累计的 cycles 数量
  • 3.3 实际：经常被当做（高精度）时钟用
    • 3.3.1 使用代码
    • 3.3.1 潜在问题
  • 3.4 挑战：TSC 的准确性越来越难以保证
  • 3.5 改进：引入 constant/invariant TSC
  • 3.5 小结：计数器（counter），而非时钟（clock）
• 4 查看和监控 TSC 相关信息
  • 4.1 Linux 系统时钟源（clocksource）配置
    • 4.1.1 tsc：优先
    • 4.1.2 hpet：性能开销太大
  • 4.2 turbostat 查看实际 TSC 计数（可能不准）
  • 4.3 rdtsc/rdtscp 指令采集 TSC 计数
    • 4.3.1 C 代码
    • 4.3.2 执行效果
  • 4.4 监控
    • 4.4.1 基于 turbostat（不推荐）
    • 4.4.2 基于 rdtscp
    • 4.4.3 基于 rdtscp + 内核模块
• 5 TSC 若干坑
  • 5.1 constant_tsc: a feature, not a runtime guarantee
    • 5.1.1 Lenovo SR645 (AMD EPYC 7543 CPU) TSC 不稳定
    • 5.1.2 原因及解决方式
  • 5.2 BIOS 设置致使 TSC 不恒定
    • 5.2.1 TSC 寄存器是可写的！
    • 5.2.2 BIOS SMI handler 通过修改 TSC 隐藏它们的执行
    • 5.2.3 服务器厂商出于功耗控制等原因在 BIOS 修改 TSC 同步逻辑
  • 5.3 SMI 中断风暴导致 TSC 不稳
  • 5.4 VM TSC 不稳
• 6 总结
• 参考资料

1 计算机组件的运行频率

1.1 时钟源：~20MHz 的石英晶体谐振器（quartz crystal resonator）

石英晶体谐振器是利用石英晶体（又称水晶）的压电效应 来产生高精度振荡频率的一种电子器件。

• 1880 年由雅克·居里与皮埃尔·居里发现压电效应。
• 一战期间 保罗·朗之万首先探讨了石英谐振器在声纳上的应用。
• 1917 第一个由晶体控制的电子式振荡器。
• 1918 年贝尔实验室的 Alexander M. Nicholson 取得专利，虽然与同时申请专利的 Walter Guyton Cady 曾有争议。
• 1921 年 Cady 制作了第一个石英晶体振荡器。

Wikipedia 石英晶体谐振器

现在一般长这样，焊在计算机主板上，

Fig. A miniature 16 MHz quartz crystal enclosed in a hermetically sealed HC-49/S package, used as the resonator in a crystal oscillator. Image source wikipedia

受物理特性的限制，只有几十 MHz。

1.2 Clock generator：针对不同部分（内存、PCIe、CPU 等）倍频

计算机的内存、PCIe 设备、CPU 等等组件需要的工作频率不一样（主要原因之一是其他组件跟不上 CPU 的频率）， 而且都远大于几十 MHz，因此需要对频率做提升。工作原理：

1. What is a CPU clock physically?
2. Wikipedia: Phase-locked_loop (PLL)

有个视频解释地很形象，

Fig. Scaling up crystal frequency for different components of a computer. Image source Youtube

图中的 clock generator 是个专用芯片，也是焊在主板上，一般跟晶振挨着。

1.3 CPU 频率是如何从 ~20MHz 提升到 ~3GHz 的

本节稍微再开展一下，看看 CPU 频率是如何提升到我们常见的 ~3GHz 这么高的。

1.3.1 传递路径：最终连接到 CPU CLK 引脚

结合上面的图，时钟信号的传递/提升路径：

1. 晶振（~20MHz）
2. 主板上的 clock generator 芯片
3. 北桥芯片
4. CPU

时钟信号连接到 CPU 的一个名为 CLK 的引脚。 两个具体的 CLK 引脚实物图：

• Intel 486 处理器（1989）

  

  Fig. Intel 486 pin mapImage Source

  这种 CPU 引脚今天看来还是很简单的，CLK 在第三行倒数第三列。

• AMD SP3 CPU Socket (2017)

  EPYC 7001/7002/7003 系列用的这种。图太大了就不放了，见 SP3 Pin Map。

1.3.2 CPU 内部：还有一个 clock generator

现代 CPU 内部一般还有一个 clock generator，可以继续提升频率， 最终达到厂商宣传里的基频（base frequency）或标称频率（nominal frequency），例如 EPYC 6543 的 2795MHz。 这跟原始晶振频率比，已经提升了上百倍。

2 x86 架构的寄存器

介绍点必要的背景知识，有基础的可跳过。

2.1 通用目的寄存器

Fig. 32-bit x86 general purpose registers [1]

计算机执行的所有代码，几乎都是经由通用寄存器完成的。 进一步了解：简明 x86 汇编指南（2017）。

2.2 特殊目的寄存器

如名字所示，用于特殊目的，一般也需要配套的特殊指令读写。大致分为几类：

• control registers
• debug registers
• mode-specific registers (MSR)

接下来我们主要看下 MSR 类型。

2.2.1 model-specific register (MSR)

MSR 是 x86 架构中的一组控制寄存器（control registers）， 设计用于 debugging/tracing/monitoring 等等目的，以下是 AMD 的一些系统寄存器， 其中就包括了 MSR 寄存器们，来自 AMD64 Architecture Programmer’s Manual, Volume 3 (PDF)，

Fig. AMD system registers, which include some MSR registers

几个相关的指令：

• RDMSR/WRMSR 指令：读写 MSR registers；
• CPUID 指令：检查 CPU 是否支持某些特性。

RDMSR/WRMSR 指令使用方式：

• 需要 priviledged 权限。
• Linux msr 内核模块创建了一个伪文件 /dev/cpu/{id}/msr，用户可以读写这个文件。还有一个 msr-tools 工具包。

2.2.2 MSR 之一：TSC

今天我们要讨论的是 MSR 中与时间有关的一个寄存器，叫 TSC (Time Stamp Counter)。

3 TSC（时间戳计数器）

3.1 本质：X86 处理器中的一个 特殊寄存器

Time Stamp Counter (TSC) 是 X86 处理器 （Intel/AMD/…）中的一个 64-bit 特殊目的 寄存器，属于 MRS 的一种。 还是 AMD 编程手册中的图，可以看到 MSR 和 TSC 的关系：

Fig. AMD system registers, which include some MSR registers

注意：在多核情况下（如今几乎都是多核了），每个物理核（processor）都有一个 TSC register， 或者说这是一个 per-processor register。

3.2 作用：记录 cpu 启动以来累计的 cycles 数量

前面已经介绍过，时钟信号经过层层提升之后，最终达到 CPU 期望的高运行频率，然后就会在这个频率上工作。

这里有个 CPU cycles（指令周期）的概念： 频率没经过一个周期（1Hz），CPU cycles 就增加 1 —— TSC 记录的就是从 CPU 启动（或重置）以来的累计 cycles。 这也呼应了它的名字：时间戳计数器。

3.3 实际：经常被当做（高精度）时钟用

根据以上原理，如果 CPU 频率恒定且不存在 CPU 重置的话，

• TSC 记录的就是系统启动以来的 cycles 数量；
• cycles 可以精确换算成时间；
• 这个时间的精度还非常高！；
• 使用开销还很低（这涉及到操作系统和内核实现了）。

所以无怪乎 TSC 被大量用户空间程序当做开销地高精度的时钟。

3.3.1 使用代码

本质上用户空间程序只需要一条指令（RDTSC），就能读取这个值。非常简单的几行代码：

unsigned long long rdtsc() {
    unsigned int lo, hi;
    __asm__ volatile ("rdtsc" : "=a" (lo), "=d" (hi));
    return ((unsigned long long)hi << 32) | lo;
}

就能拿到当前时刻的 cpu cycles。所以统计耗时就很直接：

    start = rdtsc();

    // business logic here

    end = rdtsc();
    elapsed_seconds = (end-start) / cycles_per_sec;

3.3.1 潜在问题

以上的假设是 TSC 恒定，随着 wall time 均匀增加。

如果 CPU 频率恒定的话（也就是没有超频、节能之类的特殊配置），cycles 就是以恒定速率增加的， 这时 TSC 确实能跟时钟保持同步，所以可以作为一种获取时间或计时的方式。 但接下来会看到，cycles 恒定这个前提条件如今已经很难满足了，内核也不推荐用 tsc 作为时间度量。

乱序执行会导致 RDTSC 的执行顺序与期望的顺序发生偏差，导致计时不准，两种解决方式：

• 插入一个同步指令（a serializing instruction），例如 CPUID，强制前面的指令必现执行完，才能才执行 RDTSC；
• 使用一个变种指令 RDTSCP，但这个指令只是对指令流做了部分顺序化（partial serialization of the instruction stream），并不完全可靠。

3.4 挑战：TSC 的准确性越来越难以保证

如果一台机器只有一个处理器，并且工作频率也一直是稳定的，那拿 TSC 作为计时方式倒也没什么问题。 但随着下面这些技术的引入，TSC 作为时钟就不准了：

• 多核处理器：意味着每个核上都有一个 TSC，如何保持这些 TSC 寄存器值的严格同步；
• 不同处理器的温度差异也会导致 TSC 偏差；
• 超线程：一个处理器上两个硬件线程（Linux 中看就是两个 CPU）；
• 超频、降频等等功耗管理功能：导致时钟不再是稳定的；
• CPU 指令乱序执行功能：获取 TSC 的指令的执行顺序和预期的可能不一致，导致计时不准；
• 休眠状态：恢复到运行状态时重置 TSC；

还有其他一些方面的挑战，都会导致无法保证一台机器多个 CPU 的 TSC 严格同步。

3.5 改进：引入 constant/invariant TSC

解决方式之一，是一种称为恒定速率（constant rate） TSC 的技术，

• 在 Linux 中，可以通过 cat /proc/cpuinfo | grep constant_tsc 来判断；
• 有这个 flag 的 CPU，TSC 以 CPU 的标称频率（nominal frequency）累积；超频或功耗控制等等导致的实际 CPU 时钟频率变化，不会影响到 TSC。

较新的 Intel、AMD 处理器都支持这个特性。

但是，constant_tsc 只是表明 CPU 有提供恒定 TSC 的能力， 并不表示实际工作 TSC 就是恒定的。后面会详细介绍。

3.5 小结：计数器（counter），而非时钟（clock）

从上面的内容已经可以看出， TSC 如其名字“时间戳计数器”所说，确实本质上只是一个计数器， 记录的是 CPU 启动以来的 cpu cycles 次数。

虽然在很多情况下把它当时钟用，结果也是正确的，但这个是没有保证的，因为影响它稳定性的因素太多了 —— 不稳拿它计时也就不准了。

另外，它是一个 x86 架构的特殊寄存器，换了其他 cpu 架构可能就不支持，所以依赖 TSC 的代码可移植性会变差。

4 查看和监控 TSC 相关信息

以上几节介绍的基本都是硬件问题，很好理解。接下来设计到软件部分就复杂了，一部分原因是命名导致的。

4.1 Linux 系统时钟源（clocksource）配置

我们前面提到不要把 tsc 作为时钟来看待，它只是一个计数器。但另一方面，内核确实需要一个时钟，

• 内核自己的定时器、调度、网络收发包等等需要时钟；
• 用户程序也需要时间功能，例如 gettimeofday() / clock_gettime()。

在底层，内核肯定是要基于启动以来的计数器，这时 tsc 就成为它的备选之一（而且优先级很高）。

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

4.1.1 tsc：优先

• 高精度：基于 cycles，所以精度是几个 GHz，对应 ns 级别；
• 低开销：跟内核实现有关。

4.1.2 hpet：性能开销太大

原理暂不展开，只说结论：相比 tsc，hpet 在很多场景会明显导致系统负载升高。所以能用 tsc 就不要用 hpet。

4.2 turbostat 查看实际 TSC 计数（可能不准）

前面提到用户空间程序写几行代码就能方便地获取 TSC 计数。所以对监控采集来说，还是很方便的。 我们甚至不需要自己写代码获取 TSC，一些内核的内置工具已经实现了这个功能，简单地执行一条 shell 命令就行了。

turbostat 是 Linux 内核自带的一个工具，可以查看包括 TSC 在内的很多信息。

turbostat 源码在内核源码树中：tools/power/x86/turbostat/turbostat.c。

不加任何参数时，turbostat 会 5s 打印一次统计信息，内容非常丰富。 我们这里用精简模式，只打印每个 CPU 在过去 1s 的 TSC 频率和所有 CPU 的平均 TSC：

# sample 1s and only one time, print only per-CPU & average TSCs
$ turbostat --quiet --show CPU,TSC_MHz --interval 1 --num_iterations 1
CPU     TSC_MHz
-       2441
0       2445
64      2445
1       2445

但 turbostat 如果执行的时间非常短，比如 1s，统计到数据就不太准，偏差比较大； 持续运行一段时间后，得到的数据才比较准。

4.3 rdtsc/rdtscp 指令采集 TSC 计数

4.3.1 C 代码

完整代码：

#include <stdio.h>
#include <time.h>
#include <unistd.h>

// https://stackoverflow.com/questions/16862620/numa-get-current-node-core
unsigned long rdtscp(int *chip, int *core) {
    unsigned a, d, c;
    __asm__ volatile("rdtscp" : "=a" (a), "=d" (d), "=c" (c));

    *chip = (c & 0xFFF000)>>12;
    *core = c & 0xFFF;
    return ((unsigned long)a) | (((unsigned long)d) << 32);;
}

int main() {
    int sleep_us = 100000;
    unsigned long tsc_nominal_hz = 2795000000;
    unsigned long expected_inc = (unsigned long)(1.0 * sleep_us / 1000000 * tsc_nominal_hz);
    unsigned long low = (unsigned long)(expected_inc * 0.95);
    unsigned long high = (unsigned long)(expected_inc * 1.05);
    printf("Sleep interval: %d us, expected tsc increase range [%lu,%lu]\n", sleep_us, low, high);

    unsigned long start, delta;
    int start_chip=0, start_core=0, end_chip=0, end_core=0;

    while (1) {
        start = rdtscp(&start_chip, &start_core);
        usleep(sleep_us);
        delta = rdtscp(&end_chip, &end_core) - start;

        if (delta > high || delta < low) {
            time_t seconds = time(NULL); // seconds since Unix epoch (1970.1.1)
            struct tm t = *localtime(&seconds);
            printf("%02d-%02d %02d:%02d:%02d TSC jitter: %lu\n",
                    t.tm_mon + 1, t.tm_mday, t.tm_hour, t.tm_min, t.tm_sec, delta);
            fflush(stdout);
        }
    }

    return 0;
}

几点说明：

1. 程序 hardcode 了预期的 TSC 频率是 2795MHz；
2. 每 100ms 采集一次 TSC 计数，如果 TSC 计数的偏差超过 +/- 5%，就将这个异常值打印出来；
3. 在哪个 chip/cpu 上执行的，这里没打印出来，有需要可以打印；
4. 这个程序虽然采集很频繁，但开销很小，主要是因为 rdtscp 指令的开销很小。

4.3.2 执行效果

编译运行，

$ gcc tsc-checker.c -o tsc-checker

# print to stdout and copy to a log file, using stream buffer instead of line buffers
$ stdbuf --output=L ./tsc-checker | tee tsc.log
Sleep interval: 100000 us, expected tsc increase range [265525000,293475000]
08-05 19:46:31 303640792
08-05 20:13:06 301869652
08-05 20:38:27 300751948
08-05 22:40:39 324424884
...

可以看到这台机器（真实服务器）有偶发 TSC 抖动， 能偏离正常范围 324424884/2795000000 - 1 = 16%， 也就是说 100ms 的时间它能偏离 16ms，非常离谱。TSC 短时间连续抖动时， 机器就会出现各种奇怪现象，比如 load 升高、网络超时、活跃线程数增加等等，因为内核系统因为时钟抖动乱了。

4.4 监控

用合适的采集工具把以上数据送到监控平台（例如 Prometheus/VictoriaMetrics），就能很直观地看到 TSC 的状态。

4.4.1 基于 turbostat（不推荐）

例如下面是 1 分钟采集一次，每次采集过去 1s 内的平均 TSC，得到的结果：

Fig. TSC runnning average of an AMD EPYC 7543 node

但前面提到， turbostat 如果执行的时间非常短，统计到数据就不太准，偏差比较大； 持续运行一段时间后，得到的数据才比较准。但作为采集程序，可能不方便执行太长时间。

4.4.2 基于 rdtscp

基于上面的 rdtscp 自己写代码采集，就非常准确了，例如，下面是 1 分钟采集一次得到的结果展示：

Fig. TSC jitter of an AMD EPYC 7543 node

不过，要抓一些偶发抖动导致的问题，1 分钟采集一次粒度太粗了。比如我们上一小节的 C 程序是 100ms 采集一次， 相当于 1 分钟采集 600 次，一小时采集 3.6w 次。我们 3 个小时总共 10 万多次跑下来，也才能抓到几次抖动，这已经算很幸运了。

4.4.3 基于 rdtscp + 内核模块

还是 rdtscp，但作为内核模块 + 定时器运行，应该会比用户空间程序更准，可以避免 Linux 内核调度器的调度偏差。

5 TSC 若干坑

5.1 constant_tsc: a feature, not a runtime guarantee

5.1.1 Lenovo SR645 (AMD EPYC 7543 CPU) TSC 不稳定

CPU 信息：

$ cat /proc/cpuinfo
...
processor       : 127
vendor_id       : AuthenticAMD
model name      : AMD EPYC 7543 32-Core Processor
cpu MHz         : 3717.449
flags           : fpu ... tsc msr rdtscp constant_tsc nonstop_tsc cpuid tsc_scale ...

flags 里面显式支持 constant_tsc 和 nonstop_tsc，所以按照文档的描述 TSC 应该是恒定的。

但是，看一下下面的监控，都是这款 CPU，机器来自两个不同的服务器厂商，

Fig. TSC fluctuations (delta of running average) of AMD EPYC 7543 nodes, from two server vendors

可以看到，

• 联想和浪潮的 TSC 都有波动，
• 联想的偶尔波动非常剧烈（相对 base 2795MHz 偏离 16% 甚至更高）；
• 浪潮的相对较小（base 2445 MHz）。

这个波动可能有几方面原因，比如各厂商的 BIOS 逻辑，或者 SMI 中断风暴。

5.1.2 原因及解决方式

最后定位到是厂商 BIOS (UEFI) 设置导致的，做如下修改之后稳定多了，

Note:

• Processors.BoostFmaxManual option only exists when BoostFmax=Manual;
• See Tuning UEFI Settings for Performance and Energy Efficiency on 4th Gen AMD EPYC Processor-Based ThinkSystem Servers for more details of each option.

5.2 BIOS 设置致使 TSC 不恒定

除了以上具体配置，还有一些可能会导致 TSC 不稳的场景。

5.2.1 TSC 寄存器是可写的！

TSC 可写，所以某些 BIOS 固件代码会修改 TSC 值，导致操作系统时序不同步（或者说不符合预期）。

5.2.2 BIOS SMI handler 通过修改 TSC 隐藏它们的执行

例如，2010 年内核社区的一个讨论 x86: Export tsc related information in sysfs 就提到，某些 BIOS SMI handler 会通过修改 TSC value 的方式来隐藏它们的执行。

为什么要隐藏？

5.2.3 服务器厂商出于功耗控制等原因在 BIOS 修改 TSC 同步逻辑

前面提到，恒定 TSC 特性只是说处理器提供了恒定的能力，但用不用这个能力，服务器厂商有非常大的决定权。

某些厂商的固件代码会在 TSC sync 逻辑中中修改 TSC 的值。 这种修改在固件这边没什么问题，但会破坏内核层面的时序视角，例如内核调度器工作会出问题。 因此，内核最后引入了一个 patch 来处理 ACPI suspend/resume，以保证 TSC sync 机制在操作系统层面还是正常的，

x86, tsc, sched: Recompute cyc2ns_offset's during resume from sleep states

TSC's get reset after suspend/resume (even on cpu's with invariant TSC
which runs at a constant rate across ACPI P-, C- and T-states). And in
some systems BIOS seem to reinit TSC to arbitrary large value (still
sync'd across cpu's) during resume.

This leads to a scenario of scheduler rq->clock (sched_clock_cpu()) less
than rq->age_stamp (introduced in 2.6.32). This leads to a big value
returned by scale_rt_power() and the resulting big group power set by the
update_group_power() is causing improper load balancing between busy and
idle cpu's after suspend/resume.

This resulted in multi-threaded workloads (like kernel-compilation) go
slower after suspend/resume cycle on core i5 laptops.

Fix this by recomputing cyc2ns_offset's during resume, so that
sched_clock() continues from the point where it was left off during
suspend.

5.3 SMI 中断风暴导致 TSC 不稳

上一节提到，BIOS SMI handler 通过修改 TSC 隐藏它们的执行。如果有大量这种中断（可能是有 bug）， 就会导致大量时间花在中断处理时，但又不会计入 TSC，最终导致系统出现卡顿等问题。

AMD 的机器比较尴尬，看不到 SMI 统计（试了几台 Intel 机器是能看到的），

$ turbostat --quiet --show CPU,TSC_MHz,SMI --interval 1 --num_iterations 1
CPU     TSC_MHz
-       2441
0       2445
64      2445
1       2445
...

5.4 VM TSC 不稳

例如

1. https://www.phoronix.com/news/AMD-Secure-TSC-Linux-Patches
2. http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/

6 总结

本文整理了一些 TSC 相关的软硬件知识，在一些故障排查场景可能会用到。

参考资料

1. 简明 x86 汇编指南（2017）
2. AMD64 Architecture Programmer’s Manual, Volume 3 (PDF)
3. Linux 服务器功耗与性能管理（一）：CPU 硬件基础（2024）
4. Pitfalls of TSC usage, 2015
5. Wikipedia MSR
6. Wikipedia TSC
7. Wikipedia Clock Generator

　　Vaulwarden 是一个开源自托管的密码管理工具，这个项目使用 Rust 实现了一套 Bitwarden Server API， 很多小伙伴都用它来管理密钥与凭证。 本文将利用 fail2ban 来实现在 CDN 场景下的防暴力破解。

步骤1：准备工作

1. 下载所有必要的包：
   • 你需要在一个可以访问互联网的机器上下载Smartmontools及其依赖项。通常可以使用包管理工具（如yum或dnf）在在线机器上下载这些包。
2. 检查Smartmontools的依赖项：
   • 确保下载所有依赖Smartmontools安装所需的包。你可以使用以下命令查看依赖项：

     sudo yum deplist smartmontools

• 下载所有这些依赖包。例如使用yumdownloader工具：

     sudo yum install yum-utils
     yumdownloader smartmontools --destdir=/path/to/downloaded-packages
     yumdownloader <dependency-name> --destdir=/path/to/downloaded-packages

步骤2：将包复制到麒麟Linux

步骤3：本地安装所有包

1. 登录到未接入互联网的麒麟Linux系统。
2. 进入包含下载包的目录：

   cd /path/to/downloaded-packages

3. 使用rpm命令安装所有包：
   • 一次性安装所有包，确保先安装依赖项然后安装Smartmontools。

   sudo rpm -ivh *.rpm

如果遇到依赖关系问题

1. 手动解决依赖项：
   • 当遇到某个依赖包缺失时，记录下缺失的包名，再次去有网络的机器上下载这些缺失的包，并重新执行上述步骤。

   sudo rpm -ivh --force --nodeps *.rpm

2. 使用本地仓库：
   • 创建一个本地YUM仓库来管理并解决软件包的依赖关系：

     mkdir -p /path/to/local-repo
     cp /path/to/downloaded-packages/*.rpm /path/to/local-repo/
     cd /path/to/local-repo/
     createrepo .
     sudo vim /etc/yum.repos.d/local.repo

     [localrepo]
     name=Local Repository
     baseurl=file:///path/to/local-repo/
     enabled=1
     gpgcheck=0

     sudo yum clean all
     sudo yum install smartmontools

声明：

资源均源自网络，因使用本页面提供的资源链接产生的版权问题或计算机数据安全问题造成的任何损失，本站概不负责。您应该确保在您使用网络资源时已拥有适当抵御病毒的措施和其他安全措施。

本页面含有通向其他网站和资源的链接，这些链接仅供您参考。本站无法控制这些网站或资源的内容，对这些内容或因使用这些内容导致的任何损失或损害，本站亦概不负责。

• InfiniCLOUD 无墙免注册免登录可以直接下载。
• 腾讯微云 需要使用 QQ/微信 登录后才能下载。

模拟器资源

请根据文件名自行推断其版本号以及使用方式。

链接顺序与版本号无关。

Windows

yuzu-windows-msvc-1361

来源：Github Relese，已和谐，无从考证

• InfiniCLOUD：https://higa.teracloud.jp/share/11e11aa96d2a3573 密码：1361
• 腾讯微云：https://share.weiyun.com/ScTJ9T1G 密码：3rmj7c

2024-02-27-09-02-46-yuzu-mainline-yuzu-windows-msvc-20240226-da3bc8921.zip

来源：已和谐，无从考证

• InfiniCLOUD：https://higa.teracloud.jp/share/11e11b3cec9d6982 密码：24040226
• 腾讯微云：https://share.weiyun.com/RwDvaowl 密码：2gdv5q

yuzu-1730.zip

来源：https://yuzu.cn.uptodown.com/windows/download/126081659

• InfiniCLOUD：https://higa.teracloud.jp/share/11e1a517ca1d5084 密码：126081659
• 腾讯微云：https://share.weiyun.com/xR0XX7AT 密码：fjvh8e

yuzu-1734.zip

来源：https://emuyuzu.com/

• InfiniCLOUD：https://higa.teracloud.jp/share/11e1b398d4cad401 密码：emuyuzu
• 腾讯微云：https://share.weiyun.com/1OmEWRJD 密码：3t78eb

yuzu-windows-msvc-20240303-7ffac53c9

来源：已和谐，无从考证

• InfiniCLOUD：https://higa.teracloud.jp/share/11e159d2b5c07ba9 密码：20240303
• 腾讯微云：https://share.weiyun.com/KKQdbGBP 密码：f6tyft

Linux

yuzu-mainline-20240303-7ffac53c9.AppImage

来源：已和谐，无从考证

• InfiniCLOUD：https://higa.teracloud.jp/share/11e1c4b51b3f1b74 密码：20240303
• 腾讯微云：https://share.weiyun.com/rcl1qmwC 密码：m69h57

yuzu-1708-1-x86_64.pkg.tar.zst

来源：https://archlinux.pkgs.org/rolling/extra-alucryd-x86_64/yuzu-1708-1-x86_64.pkg.tar.zst.html

• InfiniCLOUD：https://higa.teracloud.jp/share/11e1c167fb43cda6 密码：1708
• 腾讯微云：https://share.weiyun.com/Pe6tcbw3 密码：s3irj8

yuzu-mainline-git-1734.r0.g5372960-1-x86_64.pkg.tar

来源：https://archlinux.pkgs.org/rolling/chaotic-aur-x86_64/yuzu-mainline-git-1734.r0.g5372960-1-x86_64.pkg.tar.zst.html

• InfiniCLOUD：https://higa.teracloud.jp/share/11e16c813fd244e6 密码：1734
• 腾讯微云：https://share.weiyun.com/X31bbK2p 密码：dwxfu2

yuzu-mainline-20240304-537296095.AppImage

来源：https://emuyuzu.com/

• InfiniCLOUD：https://higa.teracloud.jp/share/11e14235c998e0b5 密码：20240304
• 腾讯微云：https://share.weiyun.com/JOxiOXw6 密码：5medzm

Firmware 固件

固件资源可以去来源页面下载，会有更新的版本

Firmware 15.0.1.zip

来源：https://prodkeys.net/yuzu-firmware/

• InfiniCLOUD：https://higa.teracloud.jp/share/11e165928322ad76 密码：firmware1501
• 腾讯微云：https://share.weiyun.com/P930fmXG 密码：5jwanr

ProdKeys

ProdKeys资源可以去来源页面下载，会有更新的版本

ProdKeys 15.0.1.zip

来源：https://prodkeys.net/prod-keys/

• InfiniCLOUD：https://higa.teracloud.jp/share/11e136ed1616ae26 密码：prod1501
• 腾讯微云：https://share.weiyun.com/lFDkO9Zp 密码：dwy24j

结尾

不包教包会，yuzu的简易安装说明可以参考我去年的文章：《用我的老电脑玩任天堂Switch模拟器》，只不过 GitHub 的资源已经完全被 DMCA Takedown 了，连 Wayback Machine 的内容都不剩。

百度吃屎去吧。