关闭独显以省电

这篇文分享给台式机很少关机, 经常远程回家中的台式机上工作的朋友.

我的主力工作机和游戏机是同一台机器, 显示屏是 4K 144Hz, 日常都是开着独显, 普通操作显示都会更顺滑一些, 但是功耗也是明显更大.

以下截图里的功率同时带着一个 J4125 小主机, 日常功耗在 18w 上下, 因此结论可能有不准确的地方

不开游戏, 在桌面快速滑动鼠标的峰值功率可以到192w

关闭独显后, 刷新率降到 60Hz, 峰值功率降到120w上下.

在外隧道回家工作是使用的腾讯的一个入门主机, 带宽较小, 远端刷新率只有 30hz, 这种情况用独显是没有意义, 可以考虑切换到集显.

多数时候, 我不直接使用远程桌面, 而是使用 vscode 的远程开发, 优势是隐蔽, 占用带宽小, 几乎是本地开发的体验.

普通代码编辑时, 约 72w, 与关闭独显前的 120w 相比, 有一定的节能效果.

使用remote ssh进行远程开发时, 可以用使用脚本关闭独显.

脚本保存为switch_dedicate_graphic_cards.ps1, 使用方法为switch_dedicate_graphic_cards.ps1 off

# Usage: switch_dedicate_graphic_cards.ps1 on|off

# Get parameters
$switch = $args[0]

# exit if no parameter is passed
if ($switch -eq $null) {
    Write-Host "Usage: switch_dedicate_graphic_cards.ps1 on|off" -ForegroundColor Yellow
    exit
}

# Get display devices
$displayDevices =  Get-CimInstance -Namespace root\cimv2 -ClassName Win32_VideoController

# If there is no display device or only one display device, exit
if ($displayDevices.Count -le 1) {
    Write-Host "No display device found."
    exit
}

# Get dedicated graphic cards
$dedicatedGraphicCards = $displayDevices | Where-Object { $_.Description -like "*NVIDIA*" }

# If there is no dedicated graphic card, exit
if ($dedicatedGraphicCards.Count -eq 0) {
    Write-Host "No dedicated graphic card found."
    exit
}

# turn dedicated graphic cards on or off
if ($switch -eq "on") {
    $dedicatedGraphicCards | ForEach-Object { pnputil /enable-device $_.PNPDeviceID }
    Write-Host "Dedicated graphic cards are turned on."
} elseif ($switch -eq "off") {
    $dedicatedGraphicCards | ForEach-Object { pnputil /disable-device $_.PNPDeviceID }
    Write-Host "Dedicated graphic cards are turned off."
} else {
    Write-Host "Invalid parameter."
    Write-Host "Usage: switch_dedicate_graphic_cards.ps1 on|off" -ForegroundColor Yellow
}

docker

k8s 和 docker

docker介绍

  • docker介绍

docker 介绍

  • docker 是一个应用容器引擎, 可以打包应用及其依赖包到一个可移植的容器中, 然后发布到任何流行的 Linux 或 Windows 机器上, 也可以实现虚拟化.
  • 为什么会有 docker, 因为开发和运维经常遇到一类问题, 那就是应用在开发人员的环境上运行没有任何问题, 但在实际生产环境中却 bug 百出.
    • 程序的运行从硬件架构到操作系统, 再到应用程序, 这些都是不同的层次, 但是开发人员往往只关注应用程序的开发, 而忽略了其他层次的问题.
    • docker 的出现就是为了解决这个问题, 它将应用程序及其依赖, 打包在一个容器中, 这样就不用担心环境的问题了.
  • 同步开发和生产环境, 使开发人员可以在本地开发, 测试, 部署应用程序, 而不用担心环境的问题. 显著提升了开发和运维的效率, 代价是一点点资源的浪费.

我极力建议所有开发者都学会使用容器进行开发和部署, 它以相对很低的代价, 为你的应用程序提供一个稳定的运行环境, 从而提高开发和运维的效率.

使用一些通俗的语言来描述使用 docker 的一种工作流:

  1. 从零创建一个开发的环境, 包含了操作系统, 应用程序, 依赖包, 配置文件等等.
    • 环境可以在任何地方运行, 也可以在任何地方创建.
    • 环境对源码编译的结果稳定且可预测, 行为完全一致.
    • 环境中程序的运行不会产生任何歧义.
    • 最好是可以使用声明式的方式来创建环境(docker-compose), 进一步减少环境的隐藏差异, 环境的一切都已在声明里展示.
  2. 创建一个 commit, 创建镜像, 这相当于一个快照, 保存当前的环境, 以便以后使用.
  3. 分享镜像给其它开发和运维, 大家基于相同语境同步展开工作.
  4. 随着业务的发展需求, 修改镜像, 重新创建 commit, 重新创建镜像, 重新分发.

docker 的基本架构

adguard

利用DNS服务平滑切换网络服务

假设服务域名为example.domain, 原服务器 IP 地址为A, 由于服务器迁移或 IP 更换, 新服务器 IP 地址为B, 为了保证用户无感知, 可以通过 DNS 服务平滑切换网络服务.

  1. 原服务状态, example.domain 解析到 IP 地址A
  2. 过渡状态, example.domain 解析到 IP 地址AB
  3. 新服务状态, example.domain 解析到 IP 地址B, 移除 IP 地址A

说明: 当用户获得两个解析地址时, 客户端会选择其中一个地址进行连接, 当连接失败时, 会尝试其它地址, 以此保证服务的可用性.

由于 DNS 解析存在缓存, 为了保证平滑切换, 需要在过渡状态保持一段时间, 以确保所有缓存失效.

我这里需要迁移的是 dns 服务, 可以在过渡状态中设置DNS重写, 加快迁移过程.

A 服务重写规则:

A服务重写

B 服务重写规则:

B服务重写

原迁移过程拓展为:

  1. 原服务状态, example.domain 解析到 IP 地址A
  2. 过渡状态, example.domaindns A服务中重写到AB, 在dns B服务中重写到B
  3. 新服务状态, example.domain 解析到 IP 地址B, 移除 IP 地址A

当用户仍在使用dns A服务时, 可以获得两个地址, 有一半的概率会选择dns A服务.
另外一半的概率会切换到dns B服务, dns B服务故障时切换回dns A. dns B服务未故障时, 将只会获得一个地址, 因而用户会停留在dns B服务中.
这样我们可以逐步的减少dns A服务的资源消耗, 而不是直接停止, 实现更平滑的迁移.

测试工具

  • 测试工具

测试工具

简易server-client代码

  • 简易server-client代码

简易 server-client 代码 windows

Windows

Complete Winsock Client Code Complete Winsock Server Code

Linux

Linux Socket Programming Simple client/server application in C

AI

Copilot系列

  • Copilot系列