您正在查看: 闲谈 分类下的文章

用DISM/DISM++备份系统时遇到的坑

近日购入一块512GB的NMVE SSD,打算替换笔记本上内置的128GB NVME SSD,不过由于笔记本上只有一个M2插槽,并且系统装在这个盘上,无法对拷,想要保留原系统,在不借助其他转接装置的情况下,只能给原系统做个镜像保存到笔记本原来的机械盘上,换好SSD后恢复。
听闻GHOST对NVME设备兼容性不佳,加上想尝试新工具,最后选择了DISM++作为备份工具。
然后问题就出现了。在我的系统上,DISM++备份极慢,2个小时还没备份好100GB数据的一半,最后甚至直接报错退出了。中途用任务管理器查看资源占用,发现DISM++写入磁盘的速度不超过1MB/s。
我以为是压缩的问题,于是禁用压缩,重新创建了一个镜像,可惜速度还是没有改善。于是我开始在互联网上以"DISM++ 备份速度慢"为关键词进行搜索,然而大多数人都说这是压缩的问题。
黔驴技穷之际,我想到DISM++也算是DISM的变种,于是开始搜索DISM相关的资料。
一位博主的教程引起了我的注意。
该文中提到:

注意:如果是在 Win8 系统中进行操作,备份时注意暂时关闭 Windows Defender,它要对整个备份文件进行扫描,其中 MsMpEng.exe 对 CPU 的占用有时高达 90% 以上,严重拖慢备份速度,有时甚至使备份时间延长十倍以上。

我使用的是Windows10系统,开启了Windows Defender。打开任务管理器一看,果然,MsMpEng.exe占用了10%的CPU,并且在不停读取机械盘。一边是DISM++在不停写入,一边是Windows Defender在不停读取,速度快才是见了鬼吧!
在设置中暂时禁用了Windows Defender的实时保护,速度果然快了起来,达到了100MB/s左右。没用1个小时,备份就结束了。
最后的问题:为什么DISM++这样使用广泛的软件,没有人真正发现问题所在呢?
可能是用DISM++这类“高级系统工具”的人,早就把Windows Defender彻底干掉了吧。

解决Windows10和Linux双系统时间错误

近日在自己的电脑上成功安装了ArchLinux,与原来的Windows10组成了双系统。但是两个系统的时间却不是统一的,如果在ArchLinux上设定了正确的时间,Windows上就是错误的,在Windows上设定了正确的时间,Linux上就是错误的,正好相差8小时。查阅资料后得知这是因为Windows与 Mac/Linux对系统硬件时间的处理方式不一样导致的。
Windows默认把系统硬件时间当作本地时间处理(就是UTC+8之类的已经加上时差的时间),即操作系统中显示的时间跟BIOS中显示的时间是一样的。但Linux会把系统硬件时间作为UTC时间处理,在这个时间的基础上根据你选择的时区显示时间。
问题就在这里。两个系统都优先读取了硬件时间,之后从授时服务器获取了正确的时间,发现不对,就用各自的方法修改了硬件时间。于是我们重启更换系统时看到的时间就不同了。
这个问题有两种解决办法,第一种是让Linux系统不把读取到的硬件时间当作UTC处理,另一种是让Windows系统把读取到的硬件时间当UTC处理。我使用的是第二种。
首先进入Windows系统,之后以管理员身份运行一个CMD,输入以下内容:

Reg add HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1

Enter执行。这个语句的作用是修改注册表,让Windows系统把读取到的硬件时间当UTC处理。
重启电脑,以后你在Linux和Windows下看到的时间应该就一致了,除非你在两个系统设定了不同的时区。

CentOS7更新内核使用BBR拥塞控制算法

TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)是由Google设计,于2016年发布的拥塞算法。以往大部分拥塞算法是基于丢包来作为降低传输速率的信号,而BBR则基于模型主动探测。该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。该算法认为随着网络接口控制器逐渐进入千兆速度时,分组丢失不应该被认为是识别拥塞的主要决定因素,所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟,可以用BBR来替代其他流行的拥塞算法,例如CUBIC。Google在YouTube上应用该算法,将全球平均的YouTube网络吞吐量提高了4%,在一些国家超过了14%。

总而言之,TCP BBR是谷歌出品的TCP拥塞控制算法,可以起到单边网络加速的作用,特别是对于延迟较高,有丢包的链路。从Linux Kernel 4.9起,就加入了该算法,但是CentOS7默认的内核还停留在3.10.0,想要享受BBR带来的加成,必须更新内核才可以。

升级内核

查看当前内核版本:uname -r
如果大于4.9可以直接进行下一步,不过你想要更新版本的内核可以继续。
为了更新内核,我们需要增加一个 ELRepo 源。
添加 ELRepo GPG key:
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
添加 ELRepo 源:
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
为了获取最快镜像,可以安装fastestmirror插件:
yum install yum-plugin-fastestmirror
现在就可以安装安装最新Kernel了:
yum --enablerepo=elrepo-kernel install kernel-ml
等待安装完成后,切换至刚安装好的新版内核:
grub2-set-default 0
重启之后,可以通过uname -r查看当前内核版本,应该是高于4.9的。

切换为BBR算法

/etc/sysctl.conf加入以下内容:

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

使设置生效:sysctl -p
查看是否成功设置:

sysctl net.ipv4.tcp_available_congestion_control #查看可以用的拥塞控制算法
sysctl net.ipv.tcp_congestion_control #查看现在使用的拥塞控制算法

两个返回值都应包含bbr
检查BBR是否运行:lsmod | grep tcp_bbr
返回值有tcp_bbr即可

现在,BBR算法就生效了,享受它带来的提升吧。

注意事项

值得注意的是,OpenVZ架构的VPS无法直接使用BBR算法。但办法还是有的,只要善用搜索引擎。
还有,BBR不是魔法,无法突破物理带宽限制。

博客更新记录

这里将会记录博客的更新:

  • 2018.3.31:准备就绪
  • 2018.4.6:配置了香港缓存,加速大陆访问
  • 2018.12.22:试图迁移至更好的服务器,其间出现问题,数据丢失,手动恢复

博客准备就绪

tian051011的博客已经配置完毕。老博客数据已经完全丢失,所以这个博客将会是个新的开始。新博客使用Typecho作为主程序,来降低资源消耗与提高性能。主题使用YTheme,并根据自己的需求做了一些修改。欢迎访问。