分类目录归档:技术笔记

常见 S3 存储服务多维度横评(附1TB存储传输成本)

之前看到猫猫大佬的 对象存储服务商价格对比:1TB存储与1TB流量基准分析 这篇文章很有启发。正好最近在探索物美价廉、稳定可靠的 S3 数据存储方案,将自己熟悉的、网上常见的一些提供 S3 的厂商服务做个整理,按照 1TB 数据存储和传输成本为指标做一个横评表格。希望给选购 S3 服务需求的人们有一些启发。

本文默认忽略了几大云厂商,如 AWS/Azure/GCP/Aliyun/Tencent,一方面几大巨头的成本较高,常人难以承受,故暂时排除。国内几大云厂商的 S3 计费规则相对复杂,出站流量普遍偏高,故暂时排除。

除了使用现成的 S3 服务,找一些稳定的 NVMe VPS 自建 Minio 也是不错的选择,可以做到超低价,但风险相对较高,大家自行探索,不在本文探讨范围内。

下面首先分标题整理各大厂商的存储和传输成本计费规则,最后整理一份汇总表格供大家参考。

各大厂商价格政策

Cloudflare R2

价格:

Standard storage Infrequent Access storage Free
Storage  存储 $0.015 / GB-month $0.01 / GB-month 10 GB-month / month
Class A Operations $4.50 / million requests $9.00 / million requests 1 million requests / month
Class B Operations $0.36 / million requests $0.90 / million requests 10 million requests / month
Data Retrieval (processing) None $0.01 / GB
Egress (data transfer to Internet) Free 1 Free 1 Free 1

区域:

Hint Hint description
wnam Western North America
enam Eastern North America
weur Western Europe
eeur Eastern Europe
apac Asia-Pacific
oc Oceania

References: https://developers.cloudflare.com/r2/pricing/ https://developers.cloudflare.com/r2/reference/data-location/

Cloudflare R2 不愧赛博大善人,提供 10GB 的免费存储空间,出站流量免费。区域主要有美国、欧洲和亚洲。

Backblaze B2

计费方式有两种:

  • 按量计费云存储(Pay-As-You-Go Cloud Storage):$6/TB/month 起。
  • B2 保留容量捆绑包(B2 Reserve Capacity Bundles):$1,560/20TB/year 起。 流量费用: 每月提供 3 倍的平均每月存储数据量免费传输,额外流出数据按每 GB 0.01 美元。

区域方面:

Backblaze currently has data centers in Sacramento, California; Stockton, California; Phoenix, Arizona; Reston, Virginia; Amsterdam, Netherlands; and Toronto, Ontario.

创建账号时就需要选择存储区域,可选 US East region, the US West region, the EU Central region, or the Canada East region

References: https://www.backblaze.com/cloud-storage/pricing https://www.backblaze.com/docs/cloud-storage-data-regions

根据官网价格工具计算,每存储 1TB 数据,每年需耗费 72 usd(6usd/m),提供 3TB 免费数据传输。若存储 2TB 数据,每年需耗费 144 usd,以此类推。

Wasabi

计费方式同样有两种:

  • 按量计费(Pay-As-You-Go):$6.99/TB/month 起。
  • 预留容量存储(Reserved Capacity Storage):针对超大规模存储,暂时忽略。
North America EMEA APAC
Wasabi Object Storage $6.99 TB/mo
($.0068 GB/mo)
Ingress Data Transfer = Free
Egress Data Transfer = Free

API Requests = Free*
$6.99 TB/mo
($.0068 GB/mo)
Ingress Data Transfer = Free
Egress Data Transfer = Free

API Requests = Free*
$6.99 TB/mo
($.0068 GB/mo)
Ingress Data Transfer = Free
Egress Data Transfer = Free

API Requests = Free*
Wasabi Cloud NAS $8.99 TB/mo
($.0088 GB/mo)
Ingress Data Transfer = Free
Egress Data Transfer = Free

API Requests = Free*
$8.99 TB/mo
($.0088 GB/mo)
Ingress Data Transfer = Free
Egress Data Transfer = Free

API Requests = Free*
$8.99 TB/mo
($.0088 GB/mo)
Ingress Data Transfer = Free
Egress Data Transfer = Free

API Requests = Free*

可知 Wasbi 在 North America, EMEA, APAC 几个区域提供服务,上下行流量免费,存储费用按量计费。即存储 1TB 数据每月需耗费 6.99USD,但是按照官网计算器,每年的费用是 83 USD。

根据官网可知, Wasbi 为用户免费提供为期 30天的 1 TB 存储空间,无需绑定信用卡。

References: https://wasabi.com/pricing https://wasabi.com/pricing/faq https://docs.wasabi.com/v1/docs/signing-up-for-wasabi

DigitalOcean Spaces

简单且可扩展的与 S3 兼容的对象存储,内置内容分发网络(CDN),用于存储、分发、备份和归档任意数量的网页内容、图片、媒体和静态文件,以支持您的 web 应用。

DigitalOcean 提供的 Spaces S3 服务,计费从 $5 每月开始,包含 250 GiB 存储,1 TiB 出站流量,额外的空间按照 $0.02/GiB 收取,额外的出站则按照 $0.01/GiB 收取。

因此,以 1TiB 的存储容量为例,每个月用户需要额外购买(1024 GiB – 250 GiB)= 774 GiB 的存储空间。这部分额外存储的费用为 774 GiB * $0.02/GiB = $15.48 每月 ,存储 1TiB 数据的总开销为 $5.00 + $15.48 = $20.48 每月。

在区域方面,根据官网信息,可提供 NYC3 AMS3 SFO2 SFO3 SGP1 LON1 FRA1 TOR1 BLR1 SYD1 这些区域的 Space S3 存储服务。

References: https://www.digitalocean.com/pricing/spaces-object-storage https://docs.digitalocean.com/products/spaces/details/availability/

Hetzner

直接提供 $5.99/monthly 的基础价格,包含 1TB 的数据存储和 1TB 的数据传输,额外的数据传输按照 $ 1.20 /TB 收取。额外的数据存储方面,似乎都是整数倍的递增。如存储 2TB 的数据则需收取 $11.98/monthly

区域方面,在 Falkenstein, DE (FSN1), Helsinki, FI (HEL1), and Nuremberg, DE (NBG1) 这些区域可用。

References: https://www.hetzner.com/storage/object-storage/

Scaleway Object Storage

Type of consumption Price Approx. per month
Multi-AZ Standard Object Storage €0.00002/GB /hour ~€0.0146/GB/month
One Zone – IA Object Storage €0,0000165/GB/hour ~€0.012/GB/month
Requests Included
Ingress Included
Bucket websites feature Free
Egress fees* – inter regional or to Internet 75 GB free every month,
then €0.01/GB
Archiving objects: Object Storage (Standard) → Cold Storage (Glacier) Free

根据官方的这份计费表格,可以看出,Scaleway 采用弹性计费,提供多区域和单区域两种。分别计算存储并出站 1TB 数据的费用为:

Type 1 TB 存储费用 1TB 传输费用
多区域 1000 * 0.0146 = €14.6/TB/M (1000-75) * 0.01 = €9.25/TB/M
单区域 1000 * 0.012 = €12/TB/M

注:GB 默认按照 1000 进制,GiB 默认按照 1024 进制,若无明确标出则默认按 GB 计算。

区域方面,支持这些:

  • Amsterdam, The Netherlands:
    • Region: nl-ams
  • Paris, France:
    • Region: fr-par
  • Warsaw, Poland:
    • Region: pl-waw

References: https://www.scaleway.com/en/pricing/storage/ https://www.scaleway.com/en/docs/object-storage/quickstart/

Vultr

提供四种对象存储规格:Standard、Premium、Performance 和 Accelerated,存储价格各不相同。整理表格如下:

Standard Premium Performance Accelerated
1TB Prices $18.00/month $36.00/month $50.00/month $100.00/month
additional $0.018/GB $0.036/GB $0.05/GB $0.1/GB

传输费用方面,套餐默认带有 1TB,额外的费用为 $10 per additional TB transferred

区域方面,登录后台查看,可以选择这些区域:US New York, US Chicago, US Los Angeles, NL Amsterdam, AU Sydney,GB London,SG Singapore, JP Tokyo, IN Bangalore

References: https://www.vultr.com/pricing/#object-storage

Linode Object Storage

Storage $/Mo Outbound Transfer Objects / Cluster*
250 GB $5 1 TB 1 Billion
500 GB $10 1 TB 1 Billion
1 TB $20 1 TB 1 Billion
5 TB $100 1 TB 1 Billion
10 TB $200 1 TB 1 Billion
50 TB $1,000 1 TB 1 Billion
100 TB $2,000 1 TB 1 Billion
500 TB $10,000 1 TB 1 Billion
1 PB $20,000 1 TB 1 Billion

$0.02 / GB Additional Storage,  $0.005 / GB Additional Outbound Transferred

官网提供了以上这份表格,可以看出存储并传输 1Tb 数据对应套餐为 $20/M.

区域方面,登录后在开通界面可以看到,North America, Europe Asia, South America, Oceania 这些区域均提供。

References: https://www.linode.com/products/object-storage/ https://www.linode.com/pricing/#object-storage

OVH Object Storage

OVH 在 12 个 US 区域提供 S3 存储,价格区别主要在 Local Zone 还是其他区域,两种类型分别以一个机房为例摘取官网价格:

United States (Vint Hill)

Name Price
Data storage $0.00001111 /GB/hour
Incoming internal traffic Included
Incoming public traffic Included
Outgoing internal traffic Included
Outgoing public traffic $0.011 /GB

Outgoing public traffic is offered free until February 28, 2025, in all our Local Zones.

United States (Los Angeles) Local Zone

Name Price
Data storage $0.00003042 /GB/hour
Outgoing public traffic $0.0122 /GB

Outgoing public traffic is offered free until February 28, 2025, in all our Local Zones.
出站公共流量在所有本地区域将免费提供至 2025 年 2 月 28 日。

针对单区域和多区域存储和传输 1TB 数据价格整理如下(仅供参考):

类型 1TB 存储价格 1TB 传输价格
Other Zone 0.00001111 * 1000 * 24 * 31 = $8.27/TB/M 0.011 * 1000 = $11.0/TB
Local Zone 0.00003042 * 1000 * 24 * 31 = $22.63/TB/M 0.0122 * 1000 = $12.2/TB

References: https://us.ovhcloud.com/public-cloud/object-storage/ https://us.ovhcloud.com/public-cloud/prices/

汇总表格

厂商 免费额度 区域 存储费用政策 流量费用政策 1TB 存储成本 1TB 流量成本 1TB 合计费用
Cloudflare R2 10GB 存储/月
100万 Class A 操作/月
1000万 Class B 操作/月
北美东西部
欧洲东西部
亚太
大洋洲
Standard: $0.015/GB/月
IA: $0.01/GB/月
出站流量免费 约 $15/月 $0 约 $15/月
Backblaze B2 美国东西部
欧洲中部
加拿大东部
$6/TB/月
($0.006/GB/月)
提供3倍存储量的免费流量
超出部分 $0.01/GB
$6/月 $0
(3TB免费额度足够)
$6/月
($72/年)
Wasabi 30天1TB试用
(不需信用卡)
北美
欧洲中东非洲
亚太
$6.99/TB/月
($0.0068/GB/月)
入站和出站免费 $6.99/月 $0 $6.99/月
($83/年)
DigitalOcean Spaces 250GB存储
1TB出站流量
(基础套餐内)
美国(NYC3,SFO2,SFO3)
欧洲(AMS3,LON1,FRA1)
亚太(SGP1,BLR1,SYD1)
加拿大(TOR1)
基础套餐$5/月
额外存储$0.02/GB
基础套餐包含1TB流量
额外流量$0.01/GB
$20.48/月 已包含在基础套餐中 $20.48/月
Hetzner 德国(Falkenstein,Nuremberg)
芬兰(Helsinki)
$5.99/TB/月 包含1TB流量
额外流量$1.20/TB
$5.99/月 已包含在基本套餐中 $5.99/月
Scaleway 75GB出站流量/月 荷兰(Amsterdam)
法国(Paris)
波兰(Warsaw)
多区域:€0.0146/GB/月
单区域:€0.012/GB/月
75GB/月免费
额外€0.01/GB
多区域:€14.6/月
单区域:€12/月
€9.25/月
(除了免费的75GB)
多区域:约€23.85/月
单区域:约€21.25/月
Vultr 美国(纽约,芝加哥,洛杉矶)
荷兰(阿姆斯特丹)
澳大利亚(悉尼)
英国(伦敦)
新加坡
日本(东京)
印度(班加罗尔)
Standard:$18/TB/月
Premium:$36/TB/月
Performance:$50/TB/月
Accelerated:$100/TB/月
包含1TB流量
额外$10/TB
Standard:$18/月 已包含在基本套餐中 Standard:$18/月
Linode Object Storage 北美
欧洲
亚洲
南美
大洋洲
$20/TB/月
额外存储$0.02/GB
包含1TB流量
额外流量$0.005/GB
$20/月 已包含在基本套餐中 $20/月
OVH Object Storage
(2025年2月28日前出站公共流量免费)
美国(多区域) 普通区域:约$8/TB/月
($0.00001111/GB/小时)
本地区域:约$22/TB/月
($0.00003042/GB/小时)
普通区域:$0.011/GB
本地区域:$0.0122/GB
(目前均免费到2025年2月)
普通区域:约$8/月
本地区域:约$22/月
$0
(限时免费)
普通区域:约$8/月
本地区域:约$22/月
(限时优惠中)

其他流行的S3兼容存储服务

By Claude 3.7 sonnet

除了提到的这些服务商外,还有以下几家值得考虑的S3兼容存储提供商:

  1. Amazon S3 – 作为对象存储的鼻祖,仍然是最流行的选择之一

    • 存储费用: 标准存储约$0.023/GB/月(美国区域)
    • 流量费用: 入站免费,出站第一个1GB免费,之后按阶梯定价
    • 免费额度: 免费套餐提供5GB存储和20,000个GET请求
  2. Google Cloud Storage – 谷歌的对象存储解决方案

    • 存储费用: 标准存储约$0.02/GB/月
    • 流量费用: 入站免费,站内免费,出站按区域定价
    • 免费额度: 5GB存储和5GB出站流量
  3. Microsoft Azure Blob Storage – 微软的对象存储服务

    • 存储费用: 标准存储约$0.018/GB/月(热访问层)
    • 流量费用: 入站免费,站内免费,出站按区域定价
    • 免费额度: 5GB存储和免费入站数据传输
  4. Alibaba Cloud OSS (Object Storage Service) – 阿里云的对象存储服务

    • 存储费用: 标准存储约$0.018/GB/月
    • 流量费用: 入站免费,出站按区域计费
    • 全球多区域覆盖,包括中国大陆
  5. IBM Cloud Object Storage

    • 存储费用: 标准存储约$0.02/GB/月
    • 流量费用: 入站免费,出站按区域定价
    • 全球多区域覆盖
  6. OVH Object Storage

    • 存储费用: €0.01/GB/月起
    • 流量费用: 入站免费,出站按区域定价
    • 区域: 欧洲,北美,亚太

这些服务在性能、价格和地区覆盖方面各有优势,适合不同的使用场景。选择时应考虑存储需求、访问模式、地理位置和预算等因素。

总结

按需选择,也可考虑自建方案,实际费用以出账站单为准。

References

k8s 触发 pod 重新拉取镜像平滑升级的方法

下面介绍更新 Deployment 以重新拉取相同标签镜像的方法,不要只会杀 pod 触发了,个人最喜欢方法二

当镜像名称和标签都没有变化,但需要重新拉取镜像时(比如镜像内容已更新但标签保持不变),可以采用以下方法:

方法一:修改 Pod 模板以触发重新部署

为 Deployment 的 Pod 模板添加或更新一个注释(annotation)来触发滚动更新:

kubectl patch deployment [deployment-name] -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"kubectl.kubernetes.io/restartedAt\":\"$(date +%s)\"}}}}}"

这会添加或更新一个时间戳注释,使 Kubernetes 认为 Pod 模板已更改,从而触发重新部署。

方法二:强制重启 Deployment

kubectl rollout restart deployment/[deployment-name]

这是 Kubernetes 1.15 及更高版本提供的便捷命令,效果与方法一类似。

方法三:修改 imagePullPolicy

确保容器的 imagePullPolicy 设置为 Always,这样每次 Pod 重启都会重新拉取镜像:

kubectl patch deployment [deployment-name] -p '{"spec":{"template":{"spec":{"containers":[{"name":"[container-name]","imagePullPolicy":"Always"}]}}}}'

设置后,可以使用方法一或方法二触发重新部署。

方法四:删除 Pod(不推荐)

手动删除 Pod,让 Deployment 控制器创建新的 Pod:

kubectl delete pod -l app=[your-app-label]

注意: 此方法不推荐用于生产环境,因为它可能导致服务中断。

最佳实践建议

  1. 始终使用唯一标签:最好的做法是为每个新版本的镜像使用唯一标签,如使用 Git commit SHA 或时间戳。

  2. 设置 Always 拉取策略:在 Deployment 中设置:

    spec:
      template:
        spec:
          containers:
          - name: your-container
            image: your-image:tag
            imagePullPolicy: Always
  3. 对于生产环境:推荐使用前两种方法(添加注释或使用 rollout restart),它们符合 Kubernetes 的声明式设计理念,并且会进行受控的滚动更新。

使用 kubectl rollout restart deployment/[deployment-name] 是最简单且符合 Kubernetes 最佳实践的方式。

Linux CPU 运行模式及功耗分析

本文第一章节主要内容转载自:linux cpu 运行模式

CPU动态节能技术用于降低服务器功耗,通过选择系统空闲状态不同的电源管理策略,可以实现不同程度降低服务器功耗,更低的功耗策略意味着CPU唤醒更慢对性能 影响更大。

对于对时延和性能要求高的应用,建议关闭CPU的动态调节功能,禁止 CPU休眠,并把CPU频率固定到最高。

类型

通常建议在服务器BIOS中修改电源管理为Performance,如果发现CPU模式为conservative或者powersave,可以使用cpupower设置CPU Performance模式,效果也是相当显著的。

几种模式如下:

  • performance: 顾名思义只注重效率,将CPU频率固定工作在其支持的最高运行频率上,而不动态调节。
  • userspace:最早的cpufreq子系统通过userspace governor为用户提供了这种灵活性。系统将变频策略的决策权交给了用户态应用程序,并提供了相应的接口供用户态应用程序调节CPU 运行频率使用。也就是长期以来都在用的那个模式。可以通过手动编辑配置文件进行配置
  • powersave: 将CPU频率设置为最低的所谓“省电”模式,CPU会固定工作在其支持的最低运行频率上。因此这两种governors 都属于静态governor,即在使用它们时CPU 的运行频率不会根据系统运行时负载的变化动态作出调整。这两种governors 对应的是两种极端的应用场景,使用performance governor 是对系统高性能的最大追求,而使用powersave governor 则是对系统低功耗的最大追求。
  • ondemand: 按需快速动态调整CPU频率, 一有cpu计算量的任务,就会立即达到最大频率运行,等执行完毕就立即回到最低频率;ondemand:userspace是内核态的检测,用户态调整,效率低。而ondemand正是人们长期以来希望看到的一个完全在内核态下工作并且能够以更加细粒度的时间间隔对系统负载情况进行采样分析的governor。 在 ondemand governor 监测到系统负载超过 up_threshold 所设定的百分比时,说明用户当前需要 CPU 提供更强大的处理能力,因此 ondemand governor 会将CPU设置在最高频率上运行。但是当 ondemand governor 监测到系统负载下降,可以降低 CPU 的运行频率时,到底应该降低到哪个频率呢? ondemand governor 的最初实现是在可选的频率范围内调低至下一个可用频率,例如 CPU 支持三个可选频率,分别为 1.67GHz、1.33GHz 和 1GHz ,如果 CPU 运行在 1.67GHz 时 ondemand governor 发现可以降低运行频率,那么 1.33GHz 将被选作降频的目标频率。
  • conservative: 与ondemand不同,平滑地调整CPU频率,频率的升降是渐变式的,会自动在频率上下限调整,和ondemand的区别在于它会按需分配频率,而不是一味追求最高频率;

图片

常用命令

查看当前的模式

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

查看所有逻辑CPU

watch -n -1 "cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor" 

查看所有逻辑CPU当前运行的频率

watch -n -1 "cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq"

查看频率信息

cpupower frequency-info

调整频率

cpupower frequency-set -g performance

分析样例

上文给出的内容可能部分已经过时,下面给一个在我的 ArchLinux + Asus Zenbook UX3450x 上的实际运行结果,并附上 Claude 给出的分析报告:

输出

$ sudo cpupower monitor
[sudo] songtianlun 的密码:
intel-rapl/intel-rapl:0
0
intel-rapl/intel-rapl:0/intel-rapl:0:0
0
intel-rapl/intel-rapl:0/intel-rapl:0:1
0
    | Nehalem                   || Mperf              || RAPL               || Idle_Stats                
 CPU| C3   | C6   | PC3  | PC6   || C0   | Cx   | Freq  || pack | core | unco  || POLL | C1E  | C6   | C10   
  12|  0.00| 47.66|  0.00|  0.00||  7.20| 92.80|  2194||23628906|15290855|1354305||  0.07|  7.80|  9.83| 75.30
  13|  0.00|  0.00|  0.00|  0.00|| 33.04| 66.96|  2775||23628906|15290855|1354305||  0.01| 14.97| 52.19|  0.00
  14|  0.00| 33.27|  0.00|  0.00||  5.01| 94.99|  2344||23628906|15290855|1354305||  0.01|  8.17| 34.95| 52.03
  15|  0.00| 47.03|  0.00|  0.00||  4.06| 95.94|  2371||23628906|15290855|1354305||  0.00|  5.45| 24.07| 66.59
  16|  0.00| 16.66|  0.00|  0.00||  4.80| 95.20|  2046||23628906|15290855|1354305||  0.00| 11.45| 41.66| 42.28
  17|  0.00| 52.60|  0.00|  0.00||  3.45| 96.55|  1971||23628906|15290855|1354305||  0.01|  6.34|  8.76| 81.57
  18|  0.00|  0.00|  0.00|  0.00||  7.24| 92.76|  2042||23628906|15290855|1354305||  0.01| 14.95| 78.06|  0.00
  19|  0.00|  1.14|  0.00|  0.00||  5.56| 94.44|  2274||23628906|15290855|1354305||  0.00|  9.09| 70.10| 15.47
   1|  0.00|  1.03|  0.00|  0.00|| 23.08| 76.92|  3295||23628906|15290855|1354305||  0.02| 18.70|  8.31| 50.08
   2|  0.00|  1.03|  0.00|  0.00||  2.40| 97.60|  3081||23628906|15290855|1354305||  0.01|  0.21|  2.09| 95.32
   3|  0.00|  1.65|  0.00|  0.00|| 32.88| 67.12|  3675||23628906|15290855|1354305||  0.02| 17.54|  8.86| 40.85
   4|  0.00|  1.65|  0.00|  0.00||  4.20| 95.80|  2809||23628906|15290855|1354305||  0.00| 11.68|  1.47| 82.74
   0|  0.00|  0.00|  0.00|  0.00||  7.20| 92.80|  2894||23628906|15290855|1354305||  0.01|  5.83| 13.04| 74.08
   5|  0.00|  0.00|  0.00|  0.00|| 20.27| 79.73|  3067||23628906|15290855|1354305||  0.05| 22.37| 21.72| 35.85
   6|  0.00|  0.09|  0.00|  0.00|| 19.44| 80.56|  2724||23628906|15290855|1354305||  0.01| 21.37| 30.71| 28.68
   7|  0.00|  0.09|  0.00|  0.00||  4.29| 95.71|  2592||23628906|15290855|1354305||  0.01|  0.76|  0.95| 94.03
   8|  0.00|  0.18|  0.00|  0.00|| 15.50| 84.50|  2535||23628906|15290855|1354305||  0.02| 11.31| 22.62| 50.75
   9|  0.00|  0.18|  0.00|  0.00||  1.68| 98.32|  2181||23628906|15290855|1354305||  0.00|  0.46|  5.16| 92.74
  10|  0.00|  1.09|  0.00|  0.00|| 20.15| 79.85|  2530||23628906|15290855|1354305||  0.02| 16.76|  9.28| 54.03
  11|  0.00|  1.09|  0.00|  0.00||  0.03| 99.97|  2482||23628906|15290855|1354305||  0.00|  0.04|  0.00| 99.92
  20|  0.00|  0.02|  0.00|  0.00||  1.53| 98.47|   956||23628906|15290855|1354305||  0.00|  0.20|  0.48| 97.99
  21|  0.00| 99.51|  0.00|  0.00||  0.11| 99.89|   589||23628906|15290855|1354305||  0.00|  0.05|  0.10| 99.74

分析报告

概述

该报告基于 cpupower monitor 命令的输出,显示了系统 CPU 的电源管理和性能状态。数据显示一个拥有多核 CPU(22个核心,编号从0到21)的系统,监控了 C-states(CPU 电源状态)、性能指标、功耗数据和空闲统计信息。

主要发现

CPU 利用率

  • 整体系统 CPU 大部分处于空闲状态,多数核心的 C0(活跃状态)时间比例较低
  • 核心 3 和 13 的活跃度最高,分别为 32.88% 和 33.04% 的 C0 时间
  • 核心 11 几乎完全空闲,C0 时间仅为 0.03%

C-states(CPU 电源状态)分布

  • 多数核心大量时间处于深度睡眠状态(C6 或 C10)
  • 核心 21 在 C6 状态的时间最高,达到 99.51%
  • 许多核心在 C10(最深睡眠状态)的时间比例很高,如核心 11 的 C10 时间为 99.92%

CPU 频率

  • 平均 CPU 频率在 956MHz 到 3675MHz 之间变化
  • 核心 3 运行频率最高,达到 3675MHz
  • 核心 20 和 21 频率最低,分别为 956MHz 和 589MHz

详细分析

性能活跃度(C0 状态)

CPU 活跃度(C0 状态)从高到低排序的前五名:

  1. 核心 13: 33.04%
  2. 核心 3: 32.88%
  3. 核心 1: 23.08%
  4. 核心 5: 20.27%
  5. 核心 10: 20.15%

电源状态分布

大多数核心在多种空闲状态之间分布:

  • C1E 状态:轻度睡眠,节电较少但唤醒快
  • C6 状态:深度睡眠,关闭核心电源,节电显著
  • C10 状态:最深度睡眠,最大化省电

核心 21 处于 C6 状态的时间高达 99.51%,表明这个核心几乎完全处于深度睡眠状态。

功耗数据

RAPL(运行平均功率限制)数据显示:

  • 处理器包(package)功耗:23628906 (单位可能是微瓦)
  • 核心功耗:15290855
  • 非核心功耗:1354305

核心频率分布

频率最高的核心:

  1. 核心 3: 3675MHz
  2. 核心 1: 3295MHz
  3. 核心 2: 3081MHz

频率最低的核心:

  1. 核心 21: 589MHz
  2. 核心 20: 956MHz

结论

这个系统显示典型的现代处理器电源管理行为,大部分核心大多数时间处于低功耗状态。系统工作负载主要集中在少数几个核心上(如核心 3、13),而其他核心则保持在各种节能状态。这种行为对于优化功耗和热量管理非常有利,特别是在轻负载情况下。

核心 21 的极低频率(589MHz)和极高的 C6 占用率(99.51%)可能表明该核心被操作系统识别为效率较低的核心,因此优先使用其他核心进行任务分配,或者系统正在积极管理功耗限制。

References

Linux vim vi 翻页跳转命令快捷键

以下组合若没有特殊说明,基本都是键位组合。

vim翻页

vim翻半页

  • ctr-d:向后翻半页
  • ctr-u:向前翻半页

vim整整页

  • ctr+f:向后翻整页
  • ctr+b:向前翻整页

vim跳转

vim跳首行

  • g+g
  • :1
    第二种方式需要输入:
    先按shift+:
    再输入1

vim跳尾行

  • shift+g
  • :$
    第二种方式需要输入:
    先按shift+:
    再输入$

References

git 拉取所有 branch 和 tag 到本地并推送到远程

需要一个正常的可工作仓库,而不是裸镜像仓库。以下是在不使用 --mirror 选项的情况下,拉取所有分支和标签并推送到新仓库的步骤:

步骤 1: 克隆源仓库

首先,正常克隆源仓库:

# 克隆源仓库(默认只会检出 main 或 master 分支)
git clone <源仓库URL> repo-copy
cd repo-copy

步骤 2: 获取所有远程分支

默认情况下,git clone 只会创建和检出默认分支。你需要额外步骤来获取和创建所有远程分支的本地跟踪:

# 获取所有远程分支的信息
git fetch --all

# 为每个远程分支创建本地跟踪分支
git branch -r | grep -v '\->' | while read remote; do
    git branch --track "${remote#origin/}" "$remote"
done

# 拉取所有分支的最新更改
git fetch --all
git pull --all

步骤 3: 获取所有标签

确保所有标签也被获取:

# 拉取所有标签
git fetch --tags

步骤 4: 添加目标远程仓库并推送所有内容

# 添加目标远程仓库
git remote add target <目标仓库URL>

# 推送所有分支到目标仓库
git push target --all

# 推送所有标签到目标仓库
git push target --tags

一键完成脚本

下面是一个完整的脚本,可以一键完成整个过程:

# 克隆源仓库
git clone <源仓库URL> repo-copy
cd repo-copy

# 获取所有远程分支信息
git fetch --all

# 为远程分支创建本地跟踪分支
git branch -r | grep -v '\->' | while read remote; do
    git branch --track "${remote#origin/}" "$remote"
done

# 拉取所有分支和标签的最新更改
git fetch --all
git pull --all
git fetch --tags

# 添加目标远程仓库
git remote add target <目标仓库URL>

# 推送所有内容到目标仓库
git push target --all
git push target --tags

echo "所有分支和标签已成功推送到目标仓库"

简化的替代方法(适用于较新版本的 Git)

在较新版本的 Git 中,你可以使用以下简化命令:

# 克隆仓库
git clone <源仓库URL> repo-copy
cd repo-copy

# 获取所有分支并设置本地跟踪
git fetch origin
git checkout -b local_branch origin/remote_branch  # 对需要的每个远程分支重复此命令

# 获取所有标签
git fetch --tags

# 添加新远程仓库并推送
git remote add target <目标仓库URL>
git push target --all
git push target --tags

注意事项

  1. 这些命令会在本地创建所有远程分支的跟踪分支,使你能够在它们之间切换
  2. 如果仓库很大或分支很多,这个过程可能需要一些时间
  3. 确保你有足够的磁盘空间来存储完整的仓库及其历史记录
  4. 默认情况下,这不会推送任何 Git LFS 对象,如果你使用 Git LFS,可能需要额外的步骤

Rails 性能分析工具 rack-mini-profiler 和 bullet

rack-mini-profiler 和 bullet 是ruby 开发中两个广受欢迎的性能分析工具。

Bullet 更加实用,提得建议更加直接有效,rack-mini-profiler 信息丰富,需要更细致的排查时使用。

rack-mini-profiler

rack-mini-profiler 是一个轻量级的性能分析工具,它能够实时显示页面加载时间和数据库查询详情。在页面右上角显示一个小窗口,展示了页面加载的总时间,并可以展开查看详细的性能数据。它的主要特点包括:

  • 显示详细的 SQL 查询时间和调用栈
  • 支持查看内存使用情况
  • 可以分析 AJAX 请求
  • 提供火焰图分析功能
  • 支持对特定请求进行采样分析

使用 rack-mini-profiler 只需要在 Gemfile 中添加 gem 'rack-mini-profiler',并重启服务器即可生效。默认情况下它会在开发环境中自动启用。

Bullet

Bullet 则专注于解决 N+1 查询问题和检测未使用的预加载。N+1 查询是 Rails 应用中常见的性能问题,当获取关联数据时可能导致过多的数据库查询。Bullet 通过以下方式帮助开发者:

  • 实时检测 N+1 查询问题
  • 提示潜在的需要预加载的关联
  • 识别不必要的预加载
  • 支持多种通知方式(控制台、浏览器通知等)

要使用 Bullet,需要在 Gemfile 中添加 gem 'bullet',并在 config/environments/development.rb 中进行配置:

config.after_initialize do
  Bullet.enable = true
  Bullet.alert = true
  Bullet.rails_logger = true
end

这两个工具的结合使用能够帮助开发者全面了解应用的性能状况,及时发现和解决性能问题。rack-mini-profiler 提供了整体性能的详细视图,而 Bullet 则专注于数据库查询优化,它们互相补充,是 Rails 开发中不可或缺的性能优化工具。

参考文献

  1. rack-mini-profiler GitHub: https://github.com/MiniProfiler/rack-mini-profiler
  2. Bullet GitHub: https://github.com/flyerhzm/bullet
  3. Ruby on Rails Guides: https://guides.rubyonrails.org/performance_testing.html
  4. “Optimization and Performance Monitoring in Ruby on Rails”, RailsConf 2021

Rails Active Record 常用命令

主要命令

rake db:migrate
rake db:rollback

rake db:migrate:up
rake db:migrate:down

rake db:migrate:redo

指定版本号的回滚

rake db:migrate:down VERSION=20141119130134

回滚最近几个迁移

rake db:rollback STEP=n

n 代表个数。注意:是最近几个,它们会被一起移除。

其它类似命令:

只执行指定版本号的迁移

rake db:migrate VERSION=20141119130134

只执行最近几次迁移

rake db:migrate STEP=n

回滚、然后重新执行最近几次迁移

rake db:migrate:redo STEP=n

References

Rails Rake 简介与编写

来源:Rake 简介与编写

Rake 用法简介

rake 简介

Rake 的意思是 Ruby Make,一个用 ruby 开发的代码构建工具。

1.以任务的方式创建和运行脚本 当然,你可以用脚本来创建每一个你希望自动运行的任务。但是,对于大型的应用来说,你几乎总是需要为数据库迁移 (比如 Rails 中 db:migrate 任务)、清空缓存、或者代码维护等等编写脚本。对于每一项任务,你可能都需要写若干脚本,这会让你的管理变得复杂。那么,把它们用任务的方式整理到一起,会让管理变得轻松很多。

2.追踪和管理任务之间的依赖 Rake 还提供了轻松管理任务之间依赖的方式。比如,”migrate”任务和”schema:dump”任务都依赖于 “connect_to_database”任务,那么在”migrate”任务调用之前,”connect_to_database”任务都会被执行。

rake 的编写

首先 rake 文件的后缀是.rake,存放在 lib/tasks 文件夹下。 可以通过 rake –tasks 来查看当前程序下所已存在的 rake 脚本。 看下面这个例子:

desc "study rake about rails"    #desc 是Rake定义的方法,表示对下面定义任务的描述.这个描述会在使用Rake --tasks(或者Rake -T)命令时输出在屏幕上.
task :study_rake do         #cmd 命令行中执行 rake study_rake 开始执行脚本,task是Rake最重要的方法.它的方法定义是:task(args, &block).任务体是一个block。
  %w(a b c).each do |d|
    puts d   #编写你所需的功能代码。
  end 
end

这就是创建了一个 rake 脚本,这个脚本的作用是循环遍历 [“a”, “b”, “c”] 这个数组。

依赖关系和命名空间

依赖关系

desc "rake1"   
task :rake1 do   
    puts "rake1"   
end   

desc "rake2"   
task ::rake2=> :rake1 do   
    puts "rake2"   
end  

输出结果:

rake1
rake2

命名空间

namespace :today do
desc "rake1"   
task :rake1 do   
    puts "rake1"   
end      
end

那执行命令就是:rake today:rake1

在一个任务中调用另外一个任务

desc "today rake"   
task :today do   
  Rake::Task["rakes:rake1"].invoke
  Rake::Task["rakes:rake2"].invoke
  Rake::Task["rakes:rake3"].invoke
end  
namespace :rakes do
desc "rake1"   
task :rake1 do   
    puts "rake1"   
end  
desc "rake2"   
task :rake2 do   
    puts "rake2"   
end  
desc "rake3"   
task :rake3 do   
    puts "rake3"   
end  
end

默认任务

task :default => [:today]  

Rails 中的 Rake 任务

Rails 预定义了大量的 Rake 任务,在 Rails 应用的开发过程中,你想必已经在大量使用它们了。在 Rails 中,所有的 Rake 任务都放在 rails 目录的 lib/tasks 目录下 (在作者的环境下是 C:\Ruby\lib\ruby\gems\1.8\gems\rails-2.3.5 \lib\tasks),所有的 rake 任务都以.rake 作为后缀名,这些以.rake 结尾的文件会被自动加载到你的环境中。你可以到一个已有的 Rails 工程根目录下键入 rake –tasks,可以看到很多的 rake 任务已经为你整装待发了。

E. 参考资料 http://blog.sina.com.cn/s/blog_4748c4d20100y9iu.html

References