Vm

一、前言在 LXD 虚拟化平台（1）：简介 初步介绍了 LXD 虚拟化平台的基本概念与初始化装置，接下来的会具体解说 LXD 平台的各项性能。 本文聚焦在 LXD 镜像治理治理性能上。 二、镜像治理和容器镜像相似，LXD 也有镜像治理的性能。但 LXD 自身没有镜像仓库的机制，每一个 LXD Server 自身就提供镜像仓库的性能，能够通过拜访 LXD 服务端的 HTTPS 端口（上一章提到的 lxd init 时是否容许 LXD 通过 HTTPS 提供 API 接口）来查问和上传、下载镜像。 2.1 镜像源在 LXD 平台中，镜像源就是远端服务器，治理远端服务器的命令是 remote 指令，remote 指令的阐明如下： 参数应用阐明案例阐明add增加远端的 LXD 服务器（如果 LXD 服务器设置验证，须要提供验证信息才容许拜访）lxc remote add remote_server https://192.168.1.1:8443get-default以后默认应用的远端服务器，默认是 local（本地）lxc remote get-defaultlist查问以后远端服务器列表lxc remote listremove移除远端服务器lxc remote remove remote_serverrename批改远端服务器的名称lxc remote rename remote_server remote_server_new_nameset-url批改远端服务器的地址lxc remote set-url remote_server https://192.168.1.1:8443switch切换默认的远端服务器lxc remote switch remote_serverLXD 初始化结束后，曾经内置好了一些官网镜像源，能笼罩大部分的 Linux 发行版本，内置的远端服务器列表信息如下： ...

秘猿科技使命是用技术创造信任，为价值网络提供基础设施和服务。为了实现这个使命，我们三年来坚持初心，步步为营打造加密经济网络。我们想要让互联网回归到本源，用区块链技术，去构造更美好的社会，因此我们设计了 CKB 底层公链。我们自己造轮子，开创性设计了独一无二的 CKB 模型，以及用 RISC-V 打造的 CKB-VM 虚拟机。本文就将谈谈 CKB-VM 虚拟机的诞生。秘猿科技区块链小课堂第 22 期 区块链的出现使得智能合约得到了更好的实现和发展，而区块链和智能合约之间，还存在着一个重要的角色： 虚拟机（Virtual Machine） 。 虚拟机的概念在上个世纪六十年代就被提出来，而到九十年代才开始流行。当时的网络跨越了众多不同的操作系统、浏览器，如果开发者想要制作一个应用，就需要去适配所有不同的操作系统。大家知道现在 App 开发就分为安卓和苹果系统，而当时局面更加复杂。恰好 Java 程序语言开始流行，Java 构建的虚拟机能够让程序只需要写一次，依托 Java 虚拟机就能够在多个平台上运行，所以当时提出的口号就是： 一处编译、到处运行 。 我们知道比特币是没有虚拟机的，因为比特币就是把一段数字（也就是「比特币」）从地址 A 转移到地址 B，而以太坊则提出，区块链上执行的为什么不能是一套代码，能够实现更多复杂多样的东西？这就是我们所说的智能合约平台，所有节点运行一样的合约代码得到完全一样的结果。 在区块链上，虚拟机就是智能合约的运行环境，是一个可以完全对外隔离的完整计算机体系。区块链通过虚拟机来调用和执行智能合约，并要求所有节点都达成一致。而节点用的是不同的系统，有些机器是 64 位的，有些是 32 位的，传统的 Java 虚拟机容忍计算结果有少量的差异，但是在区块链上所有结果必须一样，因此，一个新的、适用于区块链的虚拟机是必不可少的。 理想中的区块链虚拟机每个区块链项目的虚拟机设计，都会有自身的艺术追求，在追求众多的特性同时做不同层次上的取舍。在做了大量的研究之后，我们认为理想中的区块链虚拟机应该是这样的： 运行时有足够的 确定性 ，在调用同样的智能合约输入时，应该返回相同的输出结果，输出结果不依赖于时间、运行环境等外部的条件；运行时有足够的 安全性 ，虚拟机的执行不会对平台本身带来负面影响；对更新足够的 灵活 ，让区块链不用通过硬分叉，就可以实现加密算法的升级或新增（回想一下以太坊硬分叉升级的痛苦）；信息足够的透明，可以让虚拟机上运行的智能合约充分发挥虚拟机的潜力；费用机制足够的 合理 ，能够确保虚拟机运行时资源消耗的计算方式更加合理准确；可以 支持不同的语言编译 ，让开发者能够自由地开发，将最新的科技运用其中。在设计 Nervos CKB 虚拟机之前，我们发现很多区块链项目都不是用真实的 CPU 指令集来构造自己的虚拟机的，他们更多的是选择了 WASM 来构造自己的虚拟机。 而我们更倾向于采用真实的 CPU 指令集来构造自己的虚拟机，因为在任何精巧复杂的虚拟机的最底层，都需要将操作转变为原始的汇编指令来执行对 CPU 的操作。另外，采用真实 CPU 指令集就不会在设计层面引入一些语义约束，束缚虚拟机的灵活性。 做一个不恰当的比喻，操作 CPU 需要有一套语言体系，使用真实的 CPU 指令集就如同能直接用这套语言体系和 CPU「说话」，那就非常方便。否则，就好像先说中文，再转换为英文，不论多完美的翻译水平，都会有一定的偏差和束缚。 ...

Custom IntelliJ IDEA VM options##################JVM模式############################# IDEA的JVM以Server模式启动（新生代默认使用ParNew）-server##################内存分配############################ 堆初始值占用3G，意味着IDEA启动即分配3G内存-Xms3g# 堆最大值占用3G-Xmx3g# 强制JVM在启动时申请到足够的堆内存（否则IDEA启动时堆初始大小不足3g）-XX:+AlwaysPreTouch# 年轻代与老年代比例为1:3（默认值是1:4），降低年轻代的回收频率-XX:NewRatio=3# 栈帧大小为16m-Xss16m##################老年代回收器######################### 使用CMS老年代回收器-XX:+UseConcMarkSweepGC# CMS的重新标记步骤：多线程一起执行-XX:+CMSParallelRemarkEnabled# CMS的并发标记步骤：启用4个线程并发标记（理论上越多越好，前提是CPU核心足够多）-XX:ConcGCThreads=8##################JIT编译器############################ 代码缓存，用于存放Just In Time编译后的本地代码，如果塞满，JVM将只解释执行，不再编译native代码。-XX:ReservedCodeCacheSize=512m# 分层编译，JIT编译优化越来越好，IDEA运行时间越久越快-XX:+TieredCompilation# 节省64位指针占用的空间，代价是JVM额外开销#-XX:+UseCompressedOops# 增大软引用在JVM中的存活时长（堆空闲空间越大越久）-XX:SoftRefLRUPolicyMSPerMB=50# 设为false Idea会提示无法利用Https更新-Djsse.enableSNIExtension=true-ea-Dsun.io.useCanonCaches=false-Djava.net.preferIPv4Stack=true-Djdk.http.auth.tunneling.disabledSchemes=""-XX:+HeapDumpOnOutOfMemoryError-XX:-OmitStackTraceInFastThrow-XX:MaxJavaStackTraceDepth=10000-Dide.no.platform.update=true

vmvm是node的一个核心模块，核心功能官方文档介绍是：The vm module provides APIs for compiling and running code within V8 Virtual Machine contexts. The vm module is not a security mechanism. Do not use it to run untrusted code. The term “sandbox” is used throughout these docs simply to refer to a separate context, and does not confer any security guarantees.意思就是：vm可以使用v8的Virtual Machine contexts动态地编译和执行代码，而代码的执行上下文是与当前进程隔离的，但是这里的隔离并不是绝对的安全，不完全等同浏览器的沙箱环境。例子vm的使用很简单，下面是几个例子：vm.runInNewContextconst vm = require(‘vm’);const sandbox = { a: 1 };// 在新的上下文运行const result = vm.runInNewContext(‘a += 1’, sandbox);console.log(result);// 2console.log(sandbox);// { a: 2 }vm.runInContextconst vm = require(‘vm’);const sandbox = { a: 1 };// https://nodejs.org/api/vm.html#vm_what_does_it_mean_to_contextify_an_objectvm.createContext(sandbox);// 在执行上下文运行const result = vm.runInContext(‘a += 1’, sandbox);console.log(result);// 2console.log(sandbox);// { a: 2 }vm.runInThisContextconst vm = require(‘vm’); global.a = 1;// 在当前上下文运行vm.runInThisContext(‘a += 1’);console.log(global.a);// 2使用场景我个人理解vm的使用场景有2个：环境隔离：因为node的js代码是单线程，在并发的场景下，需要考虑上下文的竞争和互相影响，直接使用vm，可以最小成本的解决这个问题。vue ssr在2.3.0以前，就是用vm来做隔离的渲染的，但是也带来了性能的问题，具体可以查看文档的介绍。动态执行字符串代码：这在某些需求场景下只能使用vm。劣势vm也有明显的劣势：耗费资源：这里有文章比较eval和vm的性能：https://odino.org/eval-no-more-understanding-vm-vm2-nodejs/。（当然eval的安全问题更大，这是另外的话题）。maybe attackedvm也存在安全问题，对于执行外部的代码，可能引发安全问题。所以有个开源库专门解决了这个问题，https://github.com/patriksimek/vm2，声明已经过滤了所有已知攻击。 ...