by ·0 Comments

总结出来四件事：平台、数据库、网站文件、修改域名解析。 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 […]

by ·0 Comments

原文为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 | | […]

by ·0 Comments

本文是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 […]

by ·0 Comments

原文是性能优化大神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 […]

by ·1 Comment

Persistent Memory (pmem, PM) 是很特殊的设备，它既是内存接口，又有非易失的存储特性。因此：作为内存，它即面临内存所特有的cache coherence等问题；作为存储，它也面临外存系统所特有的崩溃一致性、持久化等问题。 因此，构建一个基于PM的存储系统也所要考虑的问题是比较多的。近年来，学术界大量文章都在关注PM存储系统或者PM编程模型，比如PM感知文件系统、PM KV存储、PM事务框架等。 本文分为持久化、原子性和崩溃一致性三小节，讨论了PM系统编程的一些必须注意的点。文章整体基于我之前所写调研综述的相关部分，并进行了精简和修改。本文参考了很多文章并加入了自己的理解，若有问题，恳请指正。 1. 持久化 (Durability) 然而，对PM的store操作后并不能保证数据肯定存储到PM上，这是因为CPU和PM之间还有几层cache，要保证持久化，我们需要用flush / fence相关的指令。 当使用PM时，CPU对内存的store操作可能会暂存在硬件管理的cache或者write buffer中，若用户不强制刷cacheline到内存，无法保证store操作的数据何时写到内存中。在原来的情况下，内存为掉电易失的DRAM，所以刷或者不刷cacheline只可能牵扯到系统的性能，而不会影响系统的正确性；但是在使用PM时，由于持久化的存储是我们的目标之一，我们就要额外注重数据持久化的时机，以进行更精确的控制。 在使用块设备时，类似的问题同样存在。写操作一般会被缓存到系统的page cache中，因此需要用户调用fsync等函数来进行磁盘同步，让数据真正持久化地存储到磁盘上。解决PM cache数据写回的问题和块设备同步磁盘问题的思路是类似的，只不过方法不同。如下图，在x86平台中，当数据离开CPU cache进入PM或者进入电容保护的持久区(虚线框)，便意味着数据已经被持久化，因此只要使用将数据刷出cache并写回PM的指令，就可以保证相应数据持久化存储到PM了。 由于一般在使用PM时，是通过内存映射的方式进行的，所以使用操作系统实现的msync函数是可行的(msync和fsync具有相同的语义)。除此之外，用户也可以直接调用x86平台的cache刷新指令进行数据同步。 指令 说明 CLFLUSH 几乎所有CPU都支持，但没有任何并发性，串行地执行 CLFLUSHOPT + SFENCE 比CLFLUSH新，但是不是串行执行的，因此需要SFENCE CLWB + SFENCE 相对CLFLUSHOPT，可以在刷入PM后仍然让cache保持有效，局部性较好的数据使用此命令可以提升性能 NT stores + SFENCE 即non-temporal store，直接跳过cache的store命令，因此不需要刷新cache WBINVD 只能在内核模式用，将所有CPU的cache 刷入PM，一般不用，太影响性能 上表列出了其他的cache刷新指令，它们的行为各有不同，需要依据场景进行选择。除表中最后一项外，其他指令都是可以在用户空间直接使用的。在用户空间调用cacheline刷新指令的好处是不用切换到内核态，且用户能更清楚地知道哪块数据需要马上写回PM，所以用户的控制更精细，刷新指令的性能也要好于msync。但是，一些PM感知文件系统也需要msync的控制权，因为数据刷入PM若需要造成PM感知文件系统的metadata改变，那么用户空间使用cacheline刷新指令将导致PM感知文件系统metadata的不一致。所以用户程序应该仅在确保文件系统安全的情况下才使用cacheline刷新指令。 2. 原子性 (Atomic Updating) 这里的原子性指的是原子更新粒度(原子操作)或并发时的原子可见性(隔离性)，而非ACID事务的原子性。虽然ACID事务的原子性也是需要借助原子操作实现，这里的原子性更类似与ACID中的I(isolation, 隔离性)。 PM是内存接口，其原子性操作和内存类似，因此其访问原子性也和内存一样，在无锁保护的情况下， x86 平台上支持8、16 或 64 […]