This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.Table of Contents
FastComet（webhosting，不是VPS）
本站第一个部署的服务商是FastComet，但我买的是webhosting，不是VPS：
🔗 [对FastComet的印象 - Truxton's blog] https://truxton2blog.com/personal-fastcomet-review/
“胖子老板”（11个月）
从fastcomet迁移出来后的第一家。（🔗 [本站从FastComet迁移到了VPS主机 - Truxton's blog] https://truxton2blog.com/migrate-my-site-from-fastcomet-to-vps/）
充满了各种争议、站在风口浪尖上的服务商（尤其是2022年以后）。
面板什么的就不评价了，因为VPS太便宜，面板当然不可能好到哪里去...能重装系统开VNC这些基本的就行。提供5~10年前（甚至更老）的Debian/Fedora/CentOS/...等镜像。我不期望能重装什么最新的linux发行版，只需要安装的系统能登录进去DD一个新系统就可以。
事实上（相对于价格而言）系统性能真的挺不错的，但...如果一个VPS性能高但不稳定，那还不如不用。
稳定用了9个月以后被AMD的系统迁移大饼气得头晕。提前了6个月提醒说要迁移系统，让你提前转移资料应对服务器迁移，结果到头来无事发生。我被吊了好几个月的临时服务器，气得我直接趁着CloudCone打折活动跑了。
事实证明CloudCone虽然服务可靠，但万年HDD钻石盘-抽风网-奇葩邻居-不给升级，和胖子老板堪称一对卧龙凤雏。
Vultr（临时使用）
偶尔因为各种原因（系统炸了，重装系统，和胖子老板的系统迁移计划周旋）我也会用Vultr救急。
稳定可靠，没什么可说的。就是流量有点少（当时vultr还没宣布流量升级）
IO很强，但不知道为什么，相同价位（都是6刀/月的NVME）开出的VPS对应的yabs硬盘跑分差异很大（虽然对本站而言都足够足够用了）
CloudCone
和胖子老板一样，自带的Linux发行版很老很不全，只能DD新的，而且（因为奇葩的引导问题）只有极少数系统能顺利DD.
刚买回来装完系统以后yabs速度还行，一旦装了环境并把本站迁移过来，yabs的硬盘跑分极速下降
iowait是最大的问题，其他的东西都可以勉强用一些方法解决，但iowait真的很头疼。
一片蓝海！
硬盘：随机4k读写尤其慢，这应该是HDD的特性导致的（磁头寻道延迟过长），所以剩余的那些512k/1m读写的跑分基本上没什么用（本站不是高流量视频站，所以要尤其关注4k随机读写的性能）
硬盘：“一片蓝海”导致我的preload.py所用时间及其不稳定，现在是60s，下一次preload就是85s，再下一次preload就是70s。就算我加了足量query cache，preload.py也大概率是一片蓝海。（我可以保证运行preload.py的时候其他无关进程几乎没有消耗系统资源。）
或者另一个例子：你会发现你的监控板上全是类似这样的iowait，但看似这么高的iowait，对应的硬盘读取速度很有可能只有 0.5MB/s ~ 1MB/s ，非常气人。
随机读写的“随机”就体现在”一些命中率不高的操作“上面，比如：偶尔登录一次ssh，访问一篇非常冷门的文章里面的一些图片，突然登录服务器要操作一下npm install
ssh登陆都要花1～3秒才能提示我输入私钥密码，输入私钥密码以后有的时候要等待4～10秒才能加载出zsh prompt的那个符号，输入第一个命令的时候往往还要给你再卡一下让你怀疑是不是网络有问题，如果你登陆以后马上control+R呼出fzf，卡的时间还会更长。我没有做什么zsh优化，就当是我的问题吧。
现在加入了crontab cat .zsh_history > /dev/null，用一段时间看看效果
还好我有preload.py和mariadb query cache，不然死得更惨。新的一天在登陆状态下打开一篇普通文章可能要被卡10秒甚至更长，如果没有加缓存，访客遇到这种情况早就关闭页面了。问题在于本博客的目的是给我自己提供一个写笔记的便利环境，所以我的体验也是很重要的。
P.S. 为什么要强调新的一天：因为新的一天innodb buffer pool里面基本不存在wp_posts表的缓存数据，所以一般都要从硬盘里重新读数据，这个时候就很考验硬盘的性能了。
当然，这可能还和1GB内存+我没有分配足够innodb buffer pool size有关。事实上innodb buffer pool永远不够用，因为本站除了一个巨大的、从不清理revision的wp_posts表，还有几个体积更大的表，全都在挤占innodb buffer pool的位置。
所以我一直非常担心“随机读取avif/webp图片“的速度。
网络：到cloudflare的路线炸过几次（基本上就是完全连不上cloudflare edge server），没有任何通知，过一两天又好了。（我只开了ipv4，不知道ipv6的路线有没有炸）
vm环境：应该是母鸡或者邻居的问题，出现过好几次“wordpress几乎不能动了”（wp-admin页面直接timeout），我把wordpress相关的程序都关了，还是有持续超高iowait负荷。
Hetzner（目前正在使用）
随着CloudCone不断降低服务器的IO性能，在2023年的3月底，我终于忍不住并下决心离开了，换到了Hetzner.
这才是正常的服务器！再见吧CloudCone的钻石盘！
preload.py运行用时非常稳定！从开服务器到现在运行了几百次preload.py，用时永远在34~36秒之间（排除了那些和mysqldump/wordfence扫描等cpu密集进程冲突的特殊情况）。
