总结出来四件事:平台、数据库、网站文件、修改域名解析。 Step 1. 搭建平台 平台即web服务器、php和mysql服务器,比如只要将nginx、mysql-server和php安装好即可。 sudo apt install nginx sudo apt install php sudo apt install mysql-server Step 2. 迁移数据库 数据库即备份原始服务器中用于wordpress文章存储的数据库。命令示例[1]: # 1. 原服务器导出 mysqldump -uusername -ppassword dbname | gzip > /data/wwwroot/www/dbname.sql.gz # 2. 传输 scp /data/wwwroot/www/dbname.sql.gz root@newserverip:/root/dbname.sql.gz # 3. 新服务器导入 gunzip < /root/dbname.sql.gz | mysql -uusernameb -ppasswordb dbnamenew Step 3. 迁移网站目录 然后将原来wordpress的文件传输到新的服务器即可。 scp -R […]

原文为vfio mediated device内核文档[5],我翻译一下。 1. Virtual Function I/O (VFIO) Mediated devices[1] 对没有内置SR-IOV功能的设备进行DMA虚拟化的需求越来越多。以前,为了虚拟化一个这样的设备,开发者需要自己开发管理接口和API,然后把它们集成到用户态应用中。为了简化这种用户空间软件集成,我们找出了这种设备公共需求然后开发了一种统一的接口。 VFIO驱动框架为直接设备访问提供了统一的API。它将设备直接访问安全地(以一种IOMMU保护的环境)暴露给用户,是一种IOMMU/设备无关的框架。此框架用于多种设备,如GPU、网卡和计算加速器等。有了这种直接设备访问,虚拟机或者用户态应用可以直接访问物理设备。Mdeiated devices便是重用了VFIO这种框架。 Mediated core driver为mdiated device提供了一个公共的管理接口,它可以被不同类型的设备驱动所利用。这个模块提供了的通用接口可以进行如下操作: 创建和删除mediated device 把一个mediated deivce加入或移出某个总线驱动 把一个mediated device加入或移出某个IOMMU group Mediated core driver也提供注册总线驱动的接口。比如,一个mediated VFIO mdev驱动就是为mediated devices设计的,并且支持VFIO的API。Mediated bus driver可以将一个mediated device加入或者移出一个VFIO group。 以下的上层图展示了VFIO mediated driver框架的主要组件和接口。这张图展示了NVIDIA、Intel和IBM设备,因为这些设备是首先使用这些模块的。 +—————+ | | | +———–+ | mdev_register_driver() +————–+ | | | +<————————+ | | | mdev | | […]

本文是VFIO内核文档[1]的翻译。 很多现代系统提供DMA和中断重映射工具来帮助保证IO在被指定的界限中进行。包括x86硬件的AMD-Vi和Intel VT-d,POWER系统的Partitionable Endpoints (PEs)和嵌入式的PowerPC系统(如Freescale PAMU)。VFIO driver是IOMMU/设备不可知的一个框架,它只是专门用于将设备在安全的、IOMMU保护的环境下直接暴露给userspace。换句话说,VFIO允许安全且非特权的用户态驱动。 我们为什么需要VFIO?一个原因是虚拟机经常时用直接设备访问(“device assignment”)来获得尽可能高的IO性能。从设备和host的角度,这其实就是把VM变成了一个用户态驱动,VM也因此获得了这个IO设备的低延迟、高带宽和全虚拟化原生(bare-metal)设备驱动的直接应用。 一些应用场景中(特别是这高性能计算领域),也会从低开销的从用户空间的直接设备访问获得好处。例子包括网卡(通常基于非TCP/IP)和计算加速器等IO设备。在VFIO之前,这些驱动必须经过很长的开发周期来成为上游驱动、单独分支维护,或者使用UIO框架(UIO并不支持IOMMU保护,并且对中断支持有限,还需要root权限来访问PCI配置空间等东西)。 VFIO驱动框架用来将所有东西统一起来,代替KVM PCI设备assignment的代码,并提供一个比UIO更安全、功能更丰富的用户态驱动环境。 Groups、Devices和IOMMUs 设备是任何IO驱动的主要目标。设备一般会创建包括IO访问、中断和DMA在内的编程接口。不讨论每个驱动的细节,DMA通常是保证安全环境的最重要的部分,这是由于如果不对设备向物理内存的读写操作不设限制,将会造成对整个系统造成极大威胁。 为了减小这种风险,很多现代IOMMU将隔离特性加入到负责地址转换的接口中,这解决了设备在受限制的地址空间的寻址问题。有了这种介质,设备之间或者设备和某块内存间可以实现有效的隔离,这也允许了设备到虚拟机的安全直接管理。 这种隔离性的粒度并不总是单个设备,即使IOMMU可以做到这点,设备的属性、连接方式和IOMMU拓扑结构都可能会减弱这种隔离性。比如,一个独立的设备可能是一个更大范围设备集合的子集,那么即使IOMMU可以辨识出在这一集合中的不同设备,这个集合中的transactions也不会需要经过IOMMU。例如,从一个functions之间有后门的多function PCI设备,到一个non-PCI-ACS (Access Control Services)bridge的任何东西都允许不经过IOMMU的重定向。拓扑结构也在隐藏设备这件事中扮演着很重要的角色。一个PCIe-to-PCI的bridge隐藏了它之后的所有设备,让transaction看起来就来自bridge本身。显然,IOMMU也承担了主要的任务。 因此,虽然大多数情况下IOMMU可以达到设备级的隔离粒度,系统一般也是容忍这个粒度被放宽的。IOMMU API也因此支持IOMMU group的概念。一个group就是一组设备的集合,这组设备隔离于系统的其他设备。Group因此也是VFIO所用的ownership的单元。 虽然group是保证用户访问安全的最小粒度,它并不一定是最好的粒度。在使用page tables的IOMMU中,多个groups之间共享一组page table是可能的,这减小了硬件平台的开销(减少TLB thrashing、减少重复page table等),也减小了用户的开销(只编写一个set的转换即可)。因此,VFIO使用了一个container的概念,一个class可以包括一个或者多个groups。创建一个container很简单,只要打开/dev/vfio/vfio字符设备即可。 Container自身只提供很少的功能,。。。 用户需要将group加到container中来获得下一级的功能。要这样做,用户首先需要找到所关心设备所属的group,这可以用下边例子中的sysfs链接办到。通过将设备从host驱动解绑并绑定到VFIO驱动上,一个新的VFIO group会出现为/dev/vfio/$GROUP,其中$GROUP是IOMMU的group number,目标的设备是这个group的成员。如果IOMMU group有多个设备,那么这个VFIO group可用前,每个设备都需要绑定到一个VFIO驱动上(只是将所有设备从host驱动解绑也可以,这也会让group可用,但是没有绑定VFIO设备的特定设备不可用)。待定:禁用驱动probing/locking一个设备的接口。 如果group准备好了,可以通过open这个VFIO group字符设备(/dev/vfio/$GROUP)将这个group加入到container中,并用ioctl的VFIO_GROUP_SET_CONTAINER参数将打开的container文件描述符fd传入。如果需要在多个group间分享IOMMU上下文中,过个group可以被设置(set)到一个相同的container。如果一个group无法被set到一个container,那么一个空的container将被使用。 如果一个或多个group被加入到一个container,那么剩下的ioctl参数就可用了,可以访问VFIO IOMMU接口了。而且,现在在VFIO group的fd上用ioctl可以得到每个设备的文件描述符。 VFIO设备的API包括描述设备、描述IO region、描述设备描述符上read/write/mmap偏移量的ioctl参数,也包括描述和注册中断通知的机制。 VFIO使用实例 假如我们想访问PCI设备0000:06:0d.0: $ readlink /sys/bus/pci/devices/0000:06:0d.0/iommu_group ../../../../kernel/iommu_groups/26 因此这个设备在IOMMU group 26。这个设备在pci bus上,所以用户会用vfio-pci管理这个组: # modprobe vfio-pci 绑定这个设备到vfio-pci驱动并为这个group创建VFIO […]

原文是性能优化大神Brendan Gregg的一篇17年的博客”CPU Utilization is Wrong”[1],写的很有参考价值,我翻译一下。Youtube上也有与之对应的一个presentation: 我们大家用的“CPU占用率”这个指标存在很大的误导性,而且这种误导近年来越来越严重。什么是CPU占用率,它是指你的处理器到底多忙吗?不,那并不是它所能反映出的。是的,我正要讨论%CPU这个大家都处都在用的性能指标(包括每一种的性能检测软件,包括top工具)。 你以为90%的CPU占用率是这样时, 其实它有可能是这样的: Stalled指的是处理器不能继续执行指令,这基本是由于CPU在等待内存IO。上边我所画的busy和stalled的比例正是我在真实的生产环境所见的。所以,很有可能你在内存stall时,并没有察觉到。 对我们来说这意味这什么?明白了我们的CPU有多少被stall可以让我们直接将性能优化的努力放到减少不必要的代码和内存IO。能搞清楚CPU占用率中有多少比例的stall成分,任何关注CPU性能的人(尤其当程序运行在是根据CPU来自动扩展的云环境中时)都能获得好处。 到底什么是CPU占用率 CPU占用率这个指标其实就是“非空闲时间”,即CPU没有在跑idle线程。OS内核经常会在上下文切换时进行追踪操作,如果非空闲线程开始跑并在100毫秒后停下来,那么内核认为CPU被全部占用。 这个指标和分时系统一样古老。阿波罗登月舱的指挥计算机(分时系统的先驱)把它的idle线程称为”哑任务(dummy job)”,工程师们通过追踪运行哑任务和其他运行真实任务的cycles来得到这一重要的计算机占用率指标。(就像我以前所写一样。) 那么问题出在哪呢? 当今,CPU比主存更快,因此“等待内存”成为了“CPU占用率”的主要部分。当你在top工具中看到高的%CPU时,你可能会认为处理器(在散热器和风扇下的CPU封装)是瓶颈,不过其实都是那些DRAM内存的问题。 这种情况越来越糟,一直以来,处理器时钟的增速都要大于DRAM访问延迟的增速(“CPU-DRAM鸿沟”,译注:也叫“内存墙”)。这种局面持续到2005年的3 GHz处理器,从那以后,处理器往多核、超线程、多socket发展,这些都提升了对内存子系统的需求。处理器厂商尝试用更智能的CPU cache、更快的内存总线和互联网络来解决这些问题。但是我们仍然经常面临stall问题。 怎么知道CPU正在干什么 通过使用性能监测计数器(Performance Monitoring Counter, PMC) :一种可以用Linux perf或其他工具读取的硬件计数器。比如我们可以这样监测整个系统10秒钟: # perf stat -a — sleep 10 Performance counter stats for ‘system wide’: 641398.723351 task-clock (msec) # 64.116 CPUs utilized (100.00%) 379,651 context-switches # 0.592 K/sec (100.00%) 51,546 cpu-migrations […]