C0reFast记事本

to inspire confidence in somebody.

发表于 分类于

最近在测试我们的VM时，发现了一个比较奇怪的现象：对于同样的一个IO压力，当IO设备是NVMe或者virtio-blk时，行为有一些不太一样，具体表现在IOPS上，而且差距非常大，同样是1GB/s左右的IO，两个不同设备的IOPS差了接近4倍：

更多的测试

一般来说，NVMe设备，单个IO的最大大小是128KB，那对于1GB/s的吞吐来说，当前的IOPS是一个合理的值，那问题很显然出在了virtio-blk设备上，可以确定地是，在virtio-blk设备上的IO被切分了。简单除一下，可以大致得到设备层的IO大小大致在30KB附近，按照常理，virtio-blk设备的最大IO大小可不止这点。

阅读全文 »

发表于 分类于

本文是Use One Big Server的翻译，前两天在HackerNews上看到这篇文章，虽然是2022年的（文章刚出时，也引起了不少的讨论，不知道怎么现在又被挖了出来），但是也引发了很多热议。

行业内一直有不少关于“单体与微服务”架构的争论，但这场争论背后的真正问题是分布式系统架构是否值得花费开发者时间和成本开销。通过对系统的实际运行情况进行分析，可以深入了解大多数情况下我们是否真的需要分布式系统。

我们已经对虚拟化以及软件和运行软件的服务器之间的抽象变得如此熟悉。如今，“Serverless”计算风靡一时，甚至“裸金属”也成为了一种虚拟机。然而，每一段软件都运行在一台服务器上。由于我们现在生活在一个虚拟化的世界里，大多数这些服务器比我们实际认为的要大得多、便宜得多。

阅读全文 »

发表于 分类于

现在用的笔记本电脑是公司去年发的HP EliteBook 640 G10，机器自带了一块Solidigm的SSD，从型号上应该就是P41 Plus的OEM版本，最近使用中发现机器越来越慢了，一开始以为是内存用的多，直到有一次重启发现了一些异常，这机器重启竟然需要20分钟的时间！重启进入桌面之后，系统也非常卡顿，完全没办法使用，好不容易打开任务管理器，发现磁盘一直100%占用，响应时间已经飙上了天。很显然，磁盘遇到问题了。

阅读全文 »

发表于 分类于

在上一篇Blog里说了一下关于ARP/ND双发的实现，但是还遗留了一个小问题，就是如何测试最终的效果，毕竟正常情况下，ARP还有ND相关的报文，都是由内核协议栈根据需要发出的，不太稳定，总不能一直抓包等着内核发包吧？所以还是需要借助一些工具来实现。

阅读全文 »

发表于 分类于

大约在2019年的时候，公司的服务器接入网络架构开始向双上联去堆叠方向迁移，相比于之前老的接入网络而言，新的网络架构在各方面的提升都非常明显，尤其是在带宽利用率和冗余性方面，关于网络架构的部分，这里暂时就不多做介绍了，具体的可以参考京东以及H3C的相关分享和文档：异构去堆叠 | 一种完美提升网络高可用SLA的方案 ，H3C数据中心交换机S-MLAG最佳实践。

在新的网络架构中，我们的方案是通过ARP转主机路由方式来实现网络层面的负载均衡和高可用的，这个方案有个依赖，需要主机实现ARP/ND相关协议包的双发。

阅读全文 »

发表于 分类于

前几天偶然发现，Windows 11的WSL2可以通过WSLg来无缝使用GUI应用。类似推理/训练等任务，都不在话下，这瞬间勾起了我的好奇心，决定试试微软提供的这个神奇功能。其实微软在2021年就发布了WSLg，现在已经是2025年了，刚刚开始折腾也算是后知后觉了。

WSL支持GUI应用只能算是WSLg的一个最简单的功能了，当涉及模型训练或者GPU加速时，GPU驱动还有CUDA等等相关的配置就会变得复杂起来。我并不希望因为“折腾”这么一下，就把我的WSL环境搞得一团糟，这时候，Docker的价值就体现出来了。利用Docker，可以在不修改现有WSL环境的情况下，快速搭建一个隔离的环境来做些简单的测试。我决定使用YOLO作为测试对象，看看在WSL+WSLg+Docker的场景下，YOLO还能不能很好的工作，正确使用我的GPU进行加速。

阅读全文 »

发表于 分类于

本文是A leap year check in three instructions的翻译，前两天在HackerNews上看到这篇文章，闰年的判断方法，从一开始学编程就是一个经典的练习题，但是深挖下去，作者只用了三条指令就能实现闰年的判断，感觉还挺有意思的，所以就翻译分享一下。

省流不看版（基于DeepSeek总结）：
文章介绍了一种使用大约3个CPU指令实现快速闰年检查的方法。这种方法不同于标准算法（涉及模运算和分支），而是利用位操作和魔法数字，将闰年规则（能被4整除，但不能被100整除，除非能被400整除）巧妙地映射到对年份乘以一个常数后的结果进行位范围检查。这种位操作方法对于随机年份输入表现出显著的速度提升，并且针对特定范围已证明是最优解。这项优化技术涉及复杂的位运算细节。

以下是原文的翻译：

阅读全文 »

发表于 分类于

近期线上出现了一个问题，现象是有一台机器，网络出现了不定时的延迟：

# ping -i 0.05 192.168.0.5
#...
64 bytes from 192.168.0.5: icmp_seq=673 ttl=63 time=0.203 ms
64 bytes from 192.168.0.5: icmp_seq=674 ttl=63 time=0.210 ms
64 bytes from 192.168.0.5: icmp_seq=675 ttl=63 time=0.218 ms
64 bytes from 192.168.0.5: icmp_seq=676 ttl=63 time=0.233 ms
64 bytes from 192.168.0.5: icmp_seq=677 ttl=63 time=406 ms
64 bytes from 192.168.0.5: icmp_seq=678 ttl=63 time=354 ms
64 bytes from 192.168.0.5: icmp_seq=679 ttl=63 time=302 ms
64 bytes from 192.168.0.5: icmp_seq=680 ttl=63 time=251 ms
64 bytes from 192.168.0.5: icmp_seq=681 ttl=63 time=199 ms
64 bytes from 192.168.0.5: icmp_seq=682 ttl=63 time=147 ms
64 bytes from 192.168.0.5: icmp_seq=683 ttl=63 time=94.8 ms
64 bytes from 192.168.0.5: icmp_seq=684 ttl=63 time=43.0 ms
64 bytes from 192.168.0.5: icmp_seq=685 ttl=63 time=0.216 ms
64 bytes from 192.168.0.5: icmp_seq=686 ttl=63 time=0.248 ms
#...

以50ms为间隔ping，发现概率性的会出现超过400ms的延迟，但是并没有丢包的现象发生。

阅读全文 »

发表于 分类于

最近接到一个客户反馈，说他们的机器，遇到了top命令中，hardirq的值特别高的问题。

top - 15:27:37 up 43 days,  3:42,  1 user,  load average: 44.75, 53.47, 51.66
Tasks: 244 total,   1 running, 243 sleeping,   0 stopped,   0 zombie
%Cpu0  : 10.3 us, 19.8 sy,  0.0 ni, 39.7 id,  0.4 wa, 28.2 hi,  1.6 si,  0.0 st
%Cpu1  : 10.7 us, 21.3 sy,  0.0 ni, 40.7 id,  0.4 wa, 26.1 hi,  0.8 si,  0.0 st
%Cpu2  : 10.0 us, 19.1 sy,  0.0 ni, 41.4 id,  0.4 wa, 27.9 hi,  1.2 si,  0.0 st
%Cpu3  : 10.4 us, 20.7 sy,  0.0 ni, 40.2 id,  0.4 wa, 26.7 hi,  1.6 si,  0.0 st
%Cpu4  : 10.4 us, 15.5 sy,  0.0 ni, 45.4 id,  0.4 wa, 28.3 hi,  0.0 si,  0.0 st
%Cpu5  : 10.8 us, 21.9 sy,  0.0 ni, 39.4 id,  0.4 wa, 27.1 hi,  0.4 si,  0.0 st
%Cpu6  : 10.1 us, 18.6 sy,  0.0 ni, 41.7 id,  0.4 wa, 28.7 hi,  0.4 si,  0.0 st
%Cpu7  : 10.6 us, 25.2 sy,  0.0 ni, 36.6 id,  0.0 wa, 26.4 hi,  1.2 si,  0.0 st

从top命令输出可以看到，hardirq的值特别高，超过了25%。这导致了idle的下降，触发了监控的频繁报警。

阅读全文 »

发表于 分类于

最近线上出现一些VM网卡收包队列不均匀的问题，即使是将网卡队列中断均匀的绑定到各个CPU上，依然会出现某个核特别高的情况：

%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.9 hi,  0.9 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni, 97.5 id,  0.0 wa,  0.8 hi,  1.7 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni, 99.1 id,  0.0 wa,  0.0 hi,  0.9 si,  0.0 st
%Cpu3  :  0.9 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.9 si,  0.0 st
%Cpu4  :  0.0 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
%Cpu5  :  0.0 us,  0.0 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.9 hi,  1.7 si,  0.0 st
%Cpu6  :  0.0 us,  0.0 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.9 hi,  1.7 si,  0.0 st
%Cpu7  :  0.0 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
%Cpu8  :  0.0 us,  0.0 sy,  0.0 ni, 46.3 id,  0.0 wa,  3.4 hi, 50.3 si,  0.0 st
%Cpu9  :  0.0 us,  0.0 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.9 hi,  1.7 si,  0.0 st
%Cpu10 :  0.0 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
%Cpu11 :  0.0 us,  0.0 sy,  0.0 ni, 99.1 id,  0.0 wa,  0.0 hi,  0.9 si,  0.0 st
%Cpu12 :  0.0 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
%Cpu13 :  0.0 us,  0.0 sy,  0.0 ni, 99.1 id,  0.0 wa,  0.0 hi,  0.9 si,  0.0 st
%Cpu14 :  0.0 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st
%Cpu15 :  0.0 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  1.7 si,  0.0 st

能看到其他核大部分还是比较均匀的，就是cpu8确实比其他核高很多。经过了一些排查，发现和VM使用了IPIP Tunnel有关。

阅读全文 »
0%