C0reFast记事本

最近线上出现一些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有关。

上一篇x86平台的TSC（TIME-STAMP COUNTER）中大概分析了一下TSC的一些相关的特性，以及TSC作为系统时钟源的一些基础条件。那么，在虚拟化的场景下，如何让Guest也用上TSC呢？这篇文章就来讨论一下TSC在KVM虚拟化中的使用。

基础分析

默认情况下，KVM虚拟机首选的时钟源是kvm-clock，即使将VM的CPU Model设置为host-passthrough，也不会使用TSC作为时钟源。

# lscpu|grep Flags
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq dtes64 vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves wbnoinvd arat vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid fsrm md_clear flush_l1d arch_capabilities
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock acpi_pm
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock

今天跟着Intel的开发手册，看看如何随着Intel对TSC不断的修改和增加新特性，让TSC从一个简单的性能计数器发展成当前Linux上x86平台最重要的时钟源之一。本文基本上可以看作是Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2中17.15 TIME-STAMP COUNTER这章的翻译和总结。

在x86平台上，Linux系统里最常用的一个时钟源就是tsc，具体的，可以通过命令查看当前的时钟源和系统里可用的时钟源：

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

那么TSC是个什么东西呢？我们可以跟着手册看一看。

首先需要解释一下标题，原谅我当了一回标题党，此UFO不是Unidentified flying object，而是在网络中的一个Oflload卸载技术UDP fragmentation offload。事情的起因是这样的，我们最近尝试将线上的虚拟机，从基于网卡SR-IOV+直通的方案，切换到基于DPDK+vhost-user的方案，以换取热迁移的效率提升。

从之前的模拟压测和线上灰度效果来看，新的DPDK方案的性能和稳定性都处于很好的水平，在我们的场景下可以很好地满足需求。
直到灰度到某个业务的时候，发生了一些问题，导致了虚拟机的网络中断。

在之前的好几篇Blog里，都使用了火焰图来对业务进行性能优化，之前为了抓取火焰图，需要用到好几个工具进行组合，流程还是比较麻烦的。随着RHEL的版本更新，Redhat提供了一个更简单快速的方法实现了一键抓取火焰图的功能。

对于比较了解云计算的人来说，一定接触过AWS、阿里云的API接口，这两者的API调用方式很相似，当然具体谁参考谁这里就不深究了。以给EC2/ECS添加Tag这个接口为例：

AWS:

https://ec2.amazonaws.com/?Action=CreateTags
&ResourceId.1=ami-1a2b3c4d
&ResourceId.2=i-1234567890abcdef0
&Tag.1.Key=webserver
&Tag.1.Value=
&Tag.2.Key=stack
&Tag.2.Value=Production
&AUTHPARAMS

阿里云：

https://ecs.aliyuncs.com/?Action=TagResources
&RegionId=cn-hangzhou
&ResourceId.1=i-bp1j6qtvdm8w0z1o0****
&ResourceId.2=i-bp1j6qtvdm8w0z1oP****
&ResourceType=instance
&Tag.1.Key=TestKey
&Tag.1.Value=TestKey
&<公共请求参数>

接上篇LSI RAID卡芯片和各个OEM对应卡型号列表里说的后续DIY NAS的想法，经过快3个月的时间，终于来更新整个DIY过程了，总结起来在整个过程中，收获的主要还是折腾的乐趣，要说折腾的尽头是白群晖，随着时间的推移，个人还是比较认同的，不过不得不说白群晖确实太贵了，都说群晖是买软件送硬件，但是这软件也太贵了点。

最近想买一张拆机的HBA卡组一个NAS玩玩，目前用SAS 2308的拆机OEM HBA卡（IT Mode，也可以刷固件刷成IR Mode从而直接变成RAID卡，但是只支持RAID 0, 1, 1E和10）只需要不到100块钱，非常划算，除了功耗高点（差不多10W）比较热之外，感觉没啥缺点。

于是就被各种原厂的或者OEM厂的各种型号搞晕了，因为基于这个芯片的各种OEM马甲卡实在太多了。于是乎就找到了一篇神贴，帖子里覆盖了几乎所有的LSI的RAID卡芯片以及大部分国外厂商对应的OEM卡型号，而且一直在更新，最新的一些SAS芯片也有记录，比较可惜的是国内的一些OEM厂商，特别是在淘宝保有量相当大的浪潮的OEM卡型号没有记录。

帖子的地址在：LSI RAID Controller and HBA Complete Listing Plus OEM Models。有需要的可以参考一下。

后续组NAS的经历我也会持续分享，敬请关注~

最近折腾了一小段时间的PCDN，家里刚好有一个闲置的JetsonNano和一块闲置的SSD，刚好可以跑跑PCDN，每天挣个宽带钱。具体跑的哪家，就不说了，说说在这过程中遇到的一个小问题：一般来说，PCDN或者类似的业务，对磁盘的写入压力还是比较大的，虽然可能平均的写入带宽并不高，但是也架不住每天读写的时间相当长，虽然我这块SSD是闲置的，但好歹是个传家宝，不管怎么说，还是有那么点点心疼的，肯定是不太希望哪天这SSD被写坏了。

在这种场景下，尽可能延长SSD的写入寿命就很重要了，而方法之一呢，就是想办法把SSD的Trim命令给用上。

用上Trim命令之前，可以先简单了解一下背后的逻辑，具体的可以参考Wiki，简单来说呢，因为SSD依赖垃圾回收机制来平衡NAND的磨损，但是呢具体到一整个LBA空间，只有文件系统知道哪些数据块是有效数据，所以就需要通过Trim命令，建立文件系统空闲空间和SSD底层数据块的关联，从而让SSD的主控更好的进行垃圾回收操作，一般来说，合理的使用Trim，可以有效的提高SSD的性能和寿命。当然了，Trim命令是ATA指令集里的，也就是SATA接口SSD才会有，对于SCSI以及SAS接口SSD，还有NVMe SSD来说，也有相应的UNMAP和Deallocate指令，作用都是一样的。

一般来说，在Linux下，一个设备是否支持Trim操作，可以通过lsblk --discard进行查看，当输出中的DISC-GRAN和DISC-MAX列不为0时，说明这个设备是支持Trim操作的：

本文是SPDK文档SPDK “Reduce” Block Compression Algorithm的翻译，在读SPDK的文档过程中，刚好看到了SPDK里bdev reduce模块实现背后的算法描述，于是就想着翻译一下，正好也借翻译的同时仔细理解一下背后算法的原理，当然本人的水平有限，如果译文有任何歧义，还请参考原文并以实际原文为准。

概述

SPDK的“reduce”块压缩方案使用SSD存储压缩后的块数据，同时将元数据存放到持久内存中。此元数据包含用户数据的逻辑块到压缩后的物理块的对应关系。本文档中描述的方案是通用的，不依赖于包括SPDK在内任何特定的块设备框架。该算法会在一个叫做libreduce的库中实现。更高层次的软件可以基于该模块创建和呈现特定的块设备。对于SPDK来说，bdev_reduce模块封装了libreduce库，从而在SPDK中提供一个bdev以实现压缩功能。

本方案仅仅解释压缩后的数据块和用于跟踪这些数据块的元数据的管理。它依赖于高层软件模块来执行压缩操作。对于SPDK，bdev_reduce模块利用DPDK compressdev框架执行压缩和解压缩。

（需要注意的是，在某些情况下，数据块可能是不可压缩的，或者无法压缩到足以实现空间节省的程度。在这些情况下，数据可能不经过压缩，直接存储在磁盘上。“压缩的存储块”包括这些不经压缩的块。）