观察内存使用方法：    top -c     按住shift+m会根据进程的内存使用情况排序；    若观察到cepd、pms、高斯DB占用了节点大部分内存，其他业务进程没占多少，内存又不够，可以选择进行调整。调整方法修改 cepd 和 pms 的启动和占用内存，并重启       1.1. pmsd 用于集群监控，可使用jps查看对应的进程名为  PMSMain，可根据VM的内存情况修改文件中 pms.mem 的值来合理调整。 /opt/Bigdata/OMSV100R001C00x8664/workspace/conf/pms/application.properties                pmsMemXmx="-Xmx3096m"pmsMemXms="-Xms3096m"重启pmsd生效，命令为：/opt/Bigdata/OMSV100R001C00x8664/workspace/bin/omm_s_pm_ctl.sh restart        1.2. cepd 可使用jps查看对应的进程名为  EsperMain，可根据VM的内存情况修改文件中cep.Xmx 的值来合理调整。/opt/Bigdata/OMSV100R001C00x8664/workspace/conf/cep/application.properties重启命cepd生效，命令为：/opt/Bigdata/OMSV100R001C00x8664/workspace/bin/omm_s_cep_ctl.sh restart    2. 高斯DB连接数修改：        修改主备节点/opt/Bigdata/OMSV100R001C00x8664/workspace0/conf/pms/DBConfig.xml中的配置，将pool-maxsize的值修改为20.        <item name="pool-maxsize" value="20" />                重启命令：/opt/Bigdata/om-0.0.1/sbin/restart-oms.sh

作者|Costinel Madularea摘要：我是一个罗马尼亚人，我想，我的祖国的文化似乎正好处于两者的中间位置。就我自己而言，我似乎可以完全理解两边的团队到底是怎么想的，为什么这么想。所以很多时候，我在两家公司之间进行协调、传达和解释两边认知上的差异，我想我是客户和华为之间的一座“桥梁”。华为，我又来了！2018年的11月，我十分荣幸地参加了在意大利罗马举行的西欧服务十年颁奖晚会“10 Years Achieving Together”，当我和其他获奖同事并肩站在舞台上，感受这舞台上炫目的灯光，手里捧着纪念奖牌，心里十分满满感动和骄傲。但其实，我和华为缘分可远远不止十年。这是一个复杂而有趣的故事。我来自罗马尼亚，2004年入职罗马尼亚华为公司，成为一名工程师。当时华为在罗马尼亚的业务量并不大，工作了三年，我突然想去追寻生活的更多可能，于是我便离职开始旅行。而当我结束旅行，重新回归职场的时候，我毫不犹豫地再次选择了华为，这一次我来到华为荷兰代表处。我在罗马尼亚出生长大，当我成为荷兰代表处的一名员工的时候，我需要搬家来到荷兰。因此，也可以这么说，我再次成为华为人的第一天，也是我在荷兰这个新国家的第一天。这个有着特殊意义的一天的确非同凡响，我直接从罗马尼亚来到了荷兰，直接在客户的办公室里见到了我的主管和我的同事们。至于原因，我想大家也应该知道，因为当时海牙办事处刚成立不久，所以还没有办公室呢!那时候我们整个团队总共有十几个人，大部分都是中国人，因为我之前在罗马尼亚工作的时候，曾经来荷兰出差过，对这边的项目和同事们也比较熟悉，现在又加入了荷兰代表处，大家工作在一起，吃饭也在一起，每天朝夕相处，关系特别好。对于我来说，中国同事不仅仅只是工作上的同伴，同时也是我生活上的好朋友，我刚到荷兰的时候，是他们帮我找公寓，陪我去家具店买家具，帮我组装家具。我十分喜欢我的中国小伙伴，喜欢中国！联接两边刚开始的时候，我们在客户的公司租了一个办公室办公，离客户距离这么近的好处也显而易见：可以第一时间响应客户的需求。经过几个月和客户肩并肩的工作，我们逐渐和他们建立了良好的合作关系，开始得到他们的信任。我的大多数工作都是和K客户的核心网相关，该项目是华为在西欧一个重大的突破，是欧洲最早的核心网络项目之一，随着合作的深入，我们团队与客户之间的不同点逐渐显露出来。造成差异的原因主要在于华为与荷兰公司的工作文化是非常不同的。我们的工作文化，或者说中国的工作文化，是“垂直”的，这体现在，你的部门做了一个决策，主管传达了之后，大家就分头领任务，开始执行。但是荷兰的公司则完全不是这样的，他们的决策链是分散的，因而更加“水平”，当需要做决定的时候，每个人都会有自己的想法和意见，无论这个人的职位高或者低，都愿意表达出来自己的观点，最后大家再形成统一的意见。这种“垂直”和“水平”的差异，造成的结果就是华为这边经常无法理解——为什么客户做一个决定需要这么长时间？我们有时候和坂田总部这边反馈“项目决定时间需要2年”，总部的同事们百思不得其解。这背后，就映射着荷兰工作的文化，他们非常注重决定的过程，每个人都需要被确信，每个人都要为这个决定而努力。最值得注意的是，由于这个决定是经过每一个人赞成的，后续推进起来也相对会顺利很多。但这样形式对于我们华为是比较陌生的，在大家的认知里，只要和客户主管达成一致了，这个事情应该就没有问题了，大家难以想到这个主管回去之后，还需要得到每一个人的支持才可以进行这个项目。我是一个罗马尼亚人，我想，我的祖国的文化似乎正好处于两者的中间位置。就我自己而言，我似乎可以完全理解两边的团队到底是怎么想的，为什么这么想。所以很多时候，我在两家公司之间进行协调、传达和解释两边认知上的差异，我想我是客户和华为之间的一座“桥梁”。过程与结果的平衡作为“桥梁”，我的任务不仅仅是沟通。一方面我要向自己内部解释为什么K公司那边做出决定需要这么长时间，一边还需要推动组织分享有关进展和计划的信息，并让K公司参与任何升级的故障排除进程，而不仅仅是提供最后结果给到他们。因为，在与客户合作的这段时间，如何做到过程与结果的平衡也是我最大的收获。有这样的收获是因为，我们和客户看问题的角度不一样。华为更注重在结果，但客户对过程的关注程度更高。遇到问题的时候，我们这边集中力量快速解决问题，排除故障，恢复通讯设备的正常运营。但是客户这边十分看重在解决问题的过程中，双方的交流情况，到底是怎么解决了，我们的进程到了哪一步了，更关注如何解决这个问题的具体细节方面。我还记得，2010年K公司的内部话费体系出现了问题，项目组这边集中全部精力，想要尽快恢复计费系统的正常运营。大家一直闷头干活，觉得把问题解决了才是当务之急，忽视了和客户的及时沟通，对齐进度。但是客户和我们想的不一样，他们认为首先应该找到Root Case，然后再解决其他的问题。客户认为，这样才能更好地确定后续不会再发生这样的问题。但是，如果要找到最最底层的原因，为此需要多一两天的工期，这样客户的业务恢复就会被延期，出乎我们的意料，对于这样的结果，客户表示愿意等，并且在我们寻找Root Case的过程中，客户明确提出希望我们可以时时沟通，无论我们这边有什么想法，取得了什么进展，都第一时间让他们知道。他们希望华为提供的不仅仅是一个解决方案，而是能让他们也参与到整个问题解决过程中，了解问题解决的进度。我们常说“以客户为中心”，此刻我也理解到，尊重理解客户的所想，就是“以客户为中心”。我们虽然追求最后结果，但是过程也是不容忽视的，两者需要做到平衡。收获满满的十年成为一名华为人十年有余，常有人问我最大的成就是什么？这个问题可难倒了我，因为我认为任何成就，无论大小，对于我来说，都是一个个令我印象深刻的时刻。就拿数据迁移来说，我就有上千个印象深刻的时候，有的非常顺利，一切都按照计划圆满完成，我们内心喜悦，这样的高兴时刻在脑海里是抹不去的；有的在迁移的过程中出了问题，没有按照既定的计划顺利进展，但是我们克服了所有的困难，找到了解决的方法，避免了数据的倒回，这样柳暗花明的故事也让我铭记于心。这些大大小小的故事，都是我们津津乐道的成就。这十年里，我还有一个重要的收获，那就是改变了思维方式：我不再关注问题是怎么发生的，我更愿意去思考，这个问题应该怎么解决。每当出现问题时，我都会先寻找可能的解决方案，而不是考虑引发特定问题的潜在原因。我确信，只要你坚持不懈，你就一定会找到最好的解决方案，一切皆有可能。在华为工作的日子里，我也离不开家人的支持。忙碌工作之余，我十分珍惜和家人在一起的温馨时刻。平日里，我会尽量抽出时间来陪家人和孩子。为此我还有个小窍门，每天早上早起几个小时，把这段时间用来工作，我很享受这段安静没有人打扰的时刻，这段清晨的时间里，我的工作效率也非常的高。我的幸福家庭当然，与其他公司一样，华为并非一切都是完美的，但如果我用一个词来形容华为，那就是：激情。有人曾经说过，为我们不关心的事努力，这就是所谓的压力，但是为我们喜欢的事情而努力，这就是所谓的激情！我认为用这个词形容我的华为旅程，真的再适合不过了！西欧十年颁奖典礼（左一为作者）本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com

1. 功能概述Envoy启动时，会启动一个进程，并在这个进程中启动很多线程，这样，可以启动很多worker线程，一般worker线程数与核心数相同，每个worker线程处理所有已配置的listener上的请求，管理连接并处理filterchain，非阻塞；同时，在这个进程中会启动一个主线程，它负责启动和停止envoy，也是通过API提供配置管理的线程，同时它收集不同的指标，管理其它线程，也是非阻塞的。2. 重要数据结构定义2.1 Filter过滤器，包括listener filter、network filter和http filter。Listener filter可以用于操作连接元数据，在新接收的套接字上进行操作，例如获取原始目的地址，重定向连接等；network filter主要负责数据读写；http filter主要负责数据处理。2.2 Listener监听器，envoy中支持在每个线程中配置任意数量的监听器，每个监听器独立配置一定数量的network filter，也可以选择性的配置listener filter，listener filter在连接建立之前处理，network filter在连接建立之后处理。2.3 Worker一个worker对应一个envoy的执行线程，将listener绑定在worker上，worker负责监听、过滤和转发，每个连接的生命周期会绑定在一个单独的worker上，通常情况下，envoy实现了100%的非阻塞。3. 代码流程3.1 流程概述Envoy启动时，首先启动主线程，在主线程中对listener和filter进行初始化操作，然后将listener绑定到worker上，并由主线程拉起worker线程，由worker线程负责监听新连接。3.2 初始化3.2.1 main入口main函数是envoy启动的总入口，首先生成main_common，用于后面的初始化。3.2.2 初始化main_common在main_common里面会生成maincommonbase，它会做server instance的初始化，一个instance是一个服务的实例.3.2.3 Instance初始化在maincommonbase里调用InstanceImpl函数后，首先对启动携带的配置信息进行注册，然后执行instance的初始化。Instance的初始化包括两部分：① 将当前instance注册到ListenerManager，来管理更新；② 创建并初始化MainImpl，MainImpl用来初始化监听listener；MainImpl根据配置文件获取静态监听listener列表，将它们实例化并注册到ListenerManager。3.2.4 初始化listener对于每个静态listener，根据配置文件为它创建ListenerFilterFactoryList，并根据配置为它添加ListenerFilterFactory。listener filter有三个：original dst filter，proxy protocol filter, TLS inspector filter，一一按照配置判断是否加入ListenerFilterFactoryList。配置ListenerFilterFactoryList的同时，也会根据配置为这个listener创建NetworkerFilterFactoryList，供后续建立在这个listener上的连接使用。3.3 启动3.3.1 启动入口在main_common初始化正常完成后，执行main_common→run()启动，从而后续执行instance的run()方法，在instance的run()方法，会执行网络级别上的listener初始化。3.3.2 启动worker，将listener绑定到worker上此处，会将从配置文件读取的所有listener绑定到所有的worker上，worker是服务的并发线程，数目一般和核心数相同，将listener绑定到worker上后会通过connectionhandler模块将其初始化。3.3.3 Listener初始化Listener的初始化过程首先生成ActiveListener，通过ActiveListener调用network包内的创建函数来对listener进行网络级别的初始化。3.3.5 启动worker线程，进入监听Listener绑定在worker上，当listener初始化完成后，需要启动worker服务才能真正进入监听流程。此处，为每个worker启动新线程，并调用libevent的event_base_loop进入监听，等待连接事件到达触发后，回调onAccept进入处理流程。4. 总结本文从程序入口main函数开始，分析了envoy如何启动，以及如何对listener、worker这些核心数据结构进行初始化，并详细阐述了从envoy主线程启动到worker线程进入监听行为的全过程。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

代码最后https://github.com/apache/servicecomb-java-chassis/blob/master/core/src/main/java/org/apache/servicecomb/core/executor/GroupExecutor.java为什么只是shutdown了，而没有awaitTermination，这样不就无法保证线程池里面的任务一定能执行完成了吗？@Override     public void close() {        for (ExecutorService executorService : executorList) {           executorService.shutdown();        }        executorList.clear();     }

华为开源镜像站产品体验官评测        测试环境网络：WiFi（峰值1.7M/s，平均峰值1.5M/s）系统：Centos 7测试地点：深圳隔壁前言       最近了解华为在公测镜像站，我抱着试试的态度报名了评测，下面是我的一些测试数据和体验。首先，进入华为官方镜像站，映入眼帘的是50+的镜像，系统镜像，系统源和软件源，范围之广令人惊喜，最令我意外的是华为镜像有一些开源的软件镜像和EPEL；网站提供了快捷方便的系统下载，也提供了一些脚本方便用户替换。       速度测试（按首字母排序）        结果令人惊喜，不知道是不是开了个物理外挂，ε=ε=ε=┏(゜ロ゜;)┛        在接下来的使用中，我尝试下载一些大包（准确的来说是一堆包），速度可以到达平均峰值（1.5M/s），但是也会出现掉速(700K/s+)，我很满意这个速度，某些源能掉到200K+，更有的掉到20K+，慢到怀疑人生。槽点        1.刚开始登陆这个网站，试了试华为的账号以及相关账号，到后面才发现，要重新注册。。。。。。          2.换软件源代码：刚开始我用网站上提供的命令去替换我的源，结果失败，后来检查发现我用的不是官方的源，我之前换过，后来换回官方的源再次敲命令才成功生效。建议        1.建议打通账号信息，方便用户上手。         2.换关键字可能会出现错误，建议官方提供源文件直接让用户下载替换文件，或提供一键替换的脚本降低上手难度和出错概率。         3.既然来了镜像站，又了解了相关操作方式，买台服务器玩玩？总结        通过这次的评测，我挺惊喜的，这个速度就不用让我们浪费更多的时间在下载安装包上面，也让我看到了华为云的应用与实力，这个源我也会推荐给我的同学以及考了华为认证的小伙伴，希望华为能给我们带来更多的惊喜，也祝华为云越来越好。

很对开发者测试的时候，发现CSE SDK的CPU占用率很多时候只能够到1CPU，这是因为servicecomb.rest.server.thread-count默认值为1。 官网文档将这个配置项含义解释为“服务端线程数”（参考： https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/protocol/rest-over-vertx.html），这个解释其实不怎么准确，容易和event-loop线程数混淆，开发者理解不了，而且提升这个值，CPU的利用率确实会增加，但是通过jstack查看线程数，却不会增加。 servicecomb.rest.server.thread-count实际上的含义是Vertical的一个概念： vertical instances count。 他是一个非常抽象的概念， 涉及到资源分配和线程绑定关系。比如当值为1的时候，服务端每收到一个请求，就会将请求丢到一个event-loop线程去执行，然后这个绑定关系就确定下来了，不会发生改变。 单纯的从服务端来看，缺省值为1，而event-loop线程是2 * CPU个，无法修改，那么实际上被使用的event-loop线程只有1个，其他线程都是永远空缺着的。 vertical instances count和操作系统资源是紧密绑定的，对于服务端而言，CPU核数就是资源，因此servicecomb.rest.server.thread-count大于CPU核数就显得毫无意义了。但是操作系统还有其他的资源和处理，一个进程里面还会处理客户端网络调用， servicecomb.rest.client.thread-count增加，会分配更多的连接资源（句柄）。客户端的一个vertical instance和服务端一样，绑定到一个event-loop线程执行，不会改变。 Vertx就是利用了极小的线程池（2 * CPU），处理大量的并发请求（网络适配器、CPU、磁盘等）。着也就理解了为什么通常event-loop线程数固定不变，但是单纯看一个点，存在线程池冗余的情况。 总体来看，线程池是被合理的利用到其他地方了。 

使用Mind Studio自带的脚本卸载，存在一堆残留进程

CSE JAVA SDK的线程池模型比较复杂，对于tomcat场景，以及Edge Service的vert.x场景，都有一个业务处理线程池(Edge Service的场景默认在reactive模式，是没有业务线程池的)。CSE设置的默认线程池的线程个数为2 * CPU个数。如果部分服务处理比较慢（比如评价时延>50ms），那么建议要设置一个较大的业务线程池，以提升吞吐量。如果所有接口都处理的很快，则不需要设置非常大的业务线程池，过多线程反而会因为线程调度，增加处理时延。如果一个微服务，有少量的几个接口处理非常耗时，需要考虑将这些接口放到独立的线程池执行（线程池隔离），防止访问慢的接口，影响访问快的接口。     线程池配置 （可以适当的抽时间学习下线程模型： https://bbs.huaweicloud.com/blogs/0a1a862f412611e89fc57ca23e93a89f）        通过配置项servicecomb.executors.default给业务接口制定执行线程池。配置项的的缺省值为servicecomb.executor.groupThreadPool，这个值是Bean的ID，CSE缺省的几个Bean ID如下：  <bean id="cse.executor.groupThreadPool" class="org.apache.servicecomb.core.executor.FixedThreadExecutor"/>   <alias name="cse.executor.groupThreadPool" alias="cse.executor.default"/>   <alias name="cse.executor.groupThreadPool" alias="servicecomb.executor.groupThreadPool"/>   <bean id="cse.executor.reactive" class="org.apache.servicecomb.core.executor.ReactiveExecutor"/>   <alias name="cse.executor.reactive" alias="servicecomb.executor.reactive"/>  2.       通过servicecomb.executors.Provider.[servicename.schemaid.operationId]给某个具体的接口指定不同的线程池。

Google Chrome 中目前发现了一个新的 Bug，使用 JavaScript 创建一个循环，最终导致 Google Chrome 耗尽计算机上的所有 CPU 并使浏览器卡死。Google Chrome 错误报告中报告了这个 Bug，该报告指出，一旦用户访问该页面，CPU 利用率很快就会达到100％。这使得无法关闭 Google Chrome 选项卡、浏览器或正在使用计算机，直到 Chrome 进程结束。Google Bug报告访问下列的网址时，您将被带到这个 Bug 的页面，其标题为“Internet Security Alert! Code: 055BCCAC9FEC”。此页伪装成 Windows 错误标题“Internet Security Alert！代码：055BCCAC9FEC”，表明您的计算机已被感染，您应该拨打列出的电话号码以获取帮助。此页面包含的 JavaScript 将导致浏览器重复转到一个网址，然后 Google Chrome 返回按钮转到浏览器历史记录，然后再转到前进按钮返回原始页面。Javascript循环此循环让浏览器使用了计算机的所有 CPU 资源，如下面的 Chrome 任务管理器中所示。** CPU 利用率**这种高 CPU 利用率最终会导致浏览器冻结，计算机几乎无法使用。此时，关闭浏览器的唯一方法是 Windows任务管理器等工具，关闭 Chrome.exe 进程。问题在于，在关闭流程后重新打开 Chrome 后，它会提示你打开之前的页面。这将 Bug 页面重新打开，再次导致浏览器/计算机出现问题。重新打开Chrome因此，当 Bug 影响并终止浏览器进程时，请你不要允许 Chrome 恢复之前打开的页面。在 BleepingComputer 的测试中，同样的技术支持骗局不会影响Firefox。在 Firefox，遇到此 Bug 只需关闭选项卡和浏览器即可。原文链接: 开源中国

       作者叶子是一位90后，天秤座，大数据&人工智能美女讲师。钟情创作，相信一切感受皆是生命的体验，坚持在朴素的文字中寻找生活的出路。是一位集才气于一身的大美女。【技术分享】我学习大数据有这样一个感悟：IT的智慧体现在算法上，而算法的灵感就来源于生活。什么意思，我们一起来看看MapReduce做离线计算到底是怎么一回事儿！要理解这个过程，我们先请出一个秘密武器：大家都玩过扑克牌吧？没有玩过至少见过吧？现在有两幅扑克牌无序的堆成一摞放在桌子上。四个人玩牌，玩牌之前呢，他们要看看每一种花色的牌是否完整？请问大家，用什么方式最快？——正确答案：把牌分成4摞，每个人拿一摞，拿到牌之后每个人把自己手里的牌按照红黑花梅的花色分堆，大家都分好之后再按照花色把四个人手中的牌整合到一起。红桃一摞，黑桃一摞，以此类推。到此为止，我们就已经成功的将两幅混乱的扑克牌按花色分成四摞了。然后呢，每个人去这四摞牌里面拿到一种花色，从最小排到最大，去清点自己手里的花色是否完整！哈哈，其实这就是一个离线计算的过程。离线计算的过程分为两个阶段，首先是Map的阶段，就是我们最开始的时候把混乱的扑克牌分成4摞，每个人去拿一摞将其一张一张的分开的过程就是Map。分开之后，我们检查花色，并且按照花色将其分堆，这就是一个Partition的过程。Partition完成之后呢？我们每个人的手上保存了4摞分好了花色的牌，这时候就进入了我们的Reduce阶段，进入Reduce阶段之后做些什么呢？首先要把每个人手里分好的牌按照花色整合到一起，然后再对整合好的每一摞牌进行检查。最后分别输出检查结果。我们具体拿一些数据来分析一下这个过程。OK，看这里，input是我们要处理的数据，这是一个文本文档。我们需要做什么呢？我们把它送到MapReduce模块里边，需要得到如右边所示的结果。统计出来每个单词出现的词数。MapReduce怎么做呢？既然是集群模式，我肯定要把任务分配给不同的服务器对吧？假设我现在把文件分成3块（文件怎么划分呢？），文件分成几个块，就会在集群当中启动几个Map进程。每个进程拿到一块数据，接下来它会怎么做呢？——正确答案：Map要对拿到的数据做一个处理，然后每个Map把处理结果交给Reduce，让Reduce去做一个统计，对吧？那么，Map先会将一行数据按空格键切分，变成若干个单词，然后单词每出现一次，计数为1，用一个键值对装起来。图片解析奉上~~~计算好之后呢Map还要做一件事情，在数据量很多的情况下，我们一般还会让Map做一个单词的统计。因为如果不做单词统计的话，它就会把这一堆<hello,1>，<world,1>，直接交给Reduce，所有Map的统计结果都要通过网络传输给特定的起Reduce进程的服务器，这样子的话会造成不同服务器之间数据传输的量很大。所以Map会把每一个单词出现了多少次统计出来，比如hello出现了1次，world出现了2次这样子。最后每一个Map都把自己手头的任务计算完毕了，就把结果存储起来，接下来就轮到Reduce上场啦！在Map存储结果的过程当中，Reduce就会被启动，Reduce启动以后会去拿Map处理的结果，当有多个Reduce的时候，Reduce不会把全部的结果都读取回来，而是只读取属于自己的分区，即分区Partition。什么叫做分区呢？分区就是对Map计算的结果做的一个分类，有多少Reduce，我就把结果分成多少类，也就是多少个分区。这是通过一个算法来完成的，这个算法是怎么回事，我们后面会做一个细节补充。我们先以4个Reduce为例（一般情况下Reduce的个数少于Map的个数），假设每一个不同的单词刚刚好对应一个不同的分区。那么Reduce拿到的数据就是我们图中所示的样子。Reduce对多个Map的计算结果做了一个整合，它还是一个一个的键值对，键是我们的单词，但是值呢变成了由每一个Map提交的计算结果组成的集合。Reduce要做的就是把这些集合里面的值加起来，得到最后的结果，也就是在整个文档里面，每个单词出现了多少次。这样说起来是不是很简单呢？因为还有很多的细节我留在了<下集>中跟大家补充哦！大家是否对MapReduce的具体执行流程开始感兴趣啦？个人订阅号“叶子的浅浅时光”，集文学作品和技术文章于一体。读者叹之：才学傲须眉，妙笔若行云。欲知详情如何，请听下回分解！ 

环境：     单板stm32F103VC     keil5问题：现在编译和烧录都是好的，但是进程没有调度到，代码如下，如果正常的话，count的值会不停的累加，但是貌似没有进程没有调度起来。          有大神帮忙看看吗？（头文件不粘贴了）UINT32 g_TestTskHandle;int count = 0;VOID task1(void){     UINT32 uwRet = LOS_OK;      while(1)    {         count++;         uwRet = LOS_TaskDelay(1000);         if(uwRet !=LOS_OK)          return;    }}UINT32 create_task1(void){    UINT32 uwRet = LOS_OK;    TSK_INIT_PARAM_S task_init_param;    task_init_param.usTaskPrio = 1;    task_init_param.pcName = "task1";    task_init_param.pfnTaskEntry = (TSK_ENTRY_FUNC)task1;    task_init_param.uwStackSize = LOSCFG_BASE_CORE_TSK_DEFAULT_STACK_SIZE;    uwRet = LOS_TaskCreate(&g_TestTskHandle,&task_init_param);    if(uwRet !=LOS_OK)  {        return uwRet;   }    return uwRet;}int main(void){    UINT32 uwRet = LOS_OK;    uwRet = LOS_KernelInit();    if (uwRet != LOS_OK)    {        return LOS_NOK;    }    uwRet = create_task1();    if (uwRet != LOS_OK)    {        return LOS_NOK;    }    LOS_Start();}上图中，已经走到了LOS_Strart了，表示create_task1的返回结果是正常的，然后count的值没有变化，跟踪了一下代码，发现los_dispatch_keil.S这个文件里面的两个函数有一个没有走到，如下图，走完了osTaskSchedule之后就跑飞了，（只知道汇编的位置，不知道对应的C代码是哪里见图中汇编部分），然后后面的osPendSV一直没有进来，请问有啥好方法可以快速定位到代码是在哪里卡主了吗？

MySQL 5.7 GA（wwwqsfanlicom)已经有很长一段时间了，经过测试评估，在5.7.16版本release之后，我们开始在生产线上规模部署，一个多月相安无事，心中窃喜，在部署了大约200+实例之后，天有不测风云，故障开始接二连三。某日，一个从库报OOM。该实例的innodb_buffer_pool_size = 40G，而系统内存是64G，怎么就能OOM了呢，先下线该实例，再看情况：1、机器内存： 基本快要跪了   total    used    free    shared    buffers    cached Mem:    65808000    65492564    315436    0    1648    247284 -/+ buffers/cache: 65243632    564368 Swap:    2088952    2087852    11002、看谁是元凶：确认是mysqldPID    USER    PR    NI    VIRT    RES    SHR S %CPU %MEM    TIME+  COMMAND     28086 mysql    20    0 87.3g    61g 5192 S 21.2 97.7  28226:23 mysqld3、看MySQL监控：com_delete/innodb_rows_deleted : 29/9340 com_update/innodb_rows_updated : 155/9740 com_select/innodb_rows_selected : 299/39400该业务正常情况下是不可能出现这么大的innodb_rows值的，先stop slave，com_delete/com_update/com_select的值变0，但是innodb_rows值并没有降低，什么！！！现在已经没有任何写入了，怎么可能，诡异了。4、再看看LSN: 还在涨？5、再看看是否有事务在回滚（wwwqsfanlicom）：确实有线程在rollback，但是该实例也没有什么大事务，stop slave都已经好久了，为什么还在回滚呢？6、pstack $mysqldpid看看线程都在干什么：从下图能看出都是在compress_gtid_table()里，难道和gtid compress有关系？**一段关于gtid compress的介绍: MySQL 5.7中新增了一个mysql.gtid_executed表，用于记录当前执行过的gtid，在binlog开启的情况下，当binlog retation的时候会唤醒一个内部线程对这个表的数据进行压缩合并。7、看下mysql.gtid_executed表的情况：果然是没有压缩，看来是在压缩这个表数据的时候出错了，然后产生了回滚操作。8、经过对比，最后确认是这个参数引起的：我们为了防止有DBA不小心在从库上执行SQL，给gtid_mode=on的复制模式留下隐患，将super_read_only设置成了on，为此，还特意修改了MHA的源码，以便检测和支持这个设置，结果人算不如天算，踩上了这个坑。将super_read_only 设置成0，当binlog retation后可以看到mysql.gtid_executed的compress恢复正常了，innodb_rows也正常了：

最近在研究主机安全服务，想做一个微认证宣传一下主机安全服务。想设计一个在ECS启动一个挖矿进程，通过主机安全识别并查杀进程，演示主机安全的恶意进程的查杀能力。但是完全没有效果。在ECS上启动门罗挖矿：[root@ecs-584c build]# ./xmrig  * ABOUT        XMRig/2.8.3 gcc/4.8.5 * LIBS         libuv/1.23.2 microhttpd/0.9.33  * CPU          Intel(R) Xeon(R) Gold 6161 CPU @ 2.20GHz (1) x64 AES * CPU L2/L3    1.0 MB/30.2 MB * THREADS      1, cryptonight, donate=5% * ASSEMBLY     auto:intel * POOL #1      pool.minexmr.cn:8888 variant auto * COMMANDS     hashrate, pause, resume[2018-11-11 22:48:38] READY (CPU) threads 1(1) huge pages 0/1 0% memory 2.0 MB[2018-11-11 22:48:40] use pool pool.minexmr.cn:8888  103.60.164.109 [2018-11-11 22:48:40] new job from pool.minexmr.cn:8888 diff 80000 algo cn/2[2018-11-11 22:48:49] new job from pool.minexmr.cn:8888 diff 123079 algo cn/2[2018-11-11 22:49:19] new job from pool.minexmr.cn:8888 diff 82051 algo cn/2[2018-11-11 22:49:42] speed 10s/60s/15m 42.8 42.8 n/a H/s max 43.0 H/s[2018-11-11 22:49:49] new job from pool.minexmr.cn:8888 diff 54701 algo cn/2[2018-11-11 22:50:19] new job from pool.minexmr.cn:8888 diff 36467 algo cn/2[2018-11-11 22:50:31] new job from pool.minexmr.cn:8888 diff 36467 algo cn/2CPU占用率已经到100%：[root@ecs-584c ~]# toptop - 22:59:21 up  2:20,  2 users,  load average: 1.37, 1.61, 0.98Tasks:  69 total,   1 running,  68 sleeping,   0 stopped,   0 zombie%Cpu(s):100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 stKiB Mem :  1015780 total,   486356 free,   113412 used,   416012 buff/cacheKiB Swap:        0 total,        0 free,        0 used.   738944 avail Mem   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                   4280 root      20   0  222068   4924   2196 S 99.7  0.5  10:36.85 xmrig                     1251 root      20   0  768368  15788  10088 S  0.7  1.6   0:08.52 hostguard                    1 root      20   0  123620   4244   2544 S  0.0  0.4   0:00.98 systemd                      2 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kthreadd                     3 root      20   0       0      0      0 S  0.0  0.0   0:00.02 ksoftirqd/0        已经开启主机安全防护企业版：      

一、概要近期，出现一种新型挖矿病毒（ProtectionX），该病毒利用永恒之蓝安全漏洞，首次发现具备自我保护功能，与普通挖矿病毒有很大差异。感染主机主要是被用于挖矿，多表现为异常卡顿，严重影响主机性能和业务正常运行。该病毒使用了驱动保护，无法通过任务管理器中止病毒进程，查杀难度较高。请涉及威胁的租户根据自身业务情况，采取防护措施。二、威胁级别威胁级别：【严重】（说明：威胁级别共四级：一般、重要、严重、紧急。）三、影响范围开启了445端口SMB网络共享协议，未及时更新系统补丁或未采取终端安全防护措施的Windows系统（包括个人版和服务器版）。四、排查和处置方法排查方法：1.检查系统是否安装了最近系统漏洞补丁包；2.检查系统是否开启了445端口的SMB网络共享协议或者不必要的系统服务端口；3.检查内网是否有主机访问pool.minexmr.com:7777；4.检查系统是否存在异常运行的1sass.exe、wuauc1t.exe和win1ogon.exe进程；5.检查系统是否存在注册表项HKLM\software\microsoft\windows\CurrentVersion\Run\Registered font。处置方案：1.隔离感染主机：已中毒计算机尽快隔离，关闭所有网络连接，禁用网卡;2.切断传播途径：关闭潜在终端的SMB 445等网络共享端口，关闭异常的外联访问；3.查找攻击源：手工抓包分析或借助态势感知类产品分析，确认全网感染数量；4.查杀病毒：可使用以下工具进行查杀（http://edr.sangfor.com.cn/tool/SfabAntiBot.zip），或者可使用华为云防病毒工具进行查杀（推荐使用华为云市场软件）；5.强制删除病毒程序：可以尝试使用PC Hunter强制删除并结束进程1sass.exe、wuauc1t.exe、win1ogon.exe；6.删除注册表项：HKLM\software\microsoft\windows\CurrentVersion\Run\Registered font；7.设置复杂密码：如果主机账号使用简单密码，建议重置为高强度的密码。五、安全建议1. 不从不明网站下载相关的软件，不要点击来源不明的邮件以及附件；2. 及时给电脑打补丁，修复漏洞；3. 修改密码：设置主机账号密码为高强度的密码；4. 对重要的数据文件定期进行非本地备份；5. 安装专业的第三方反病毒软件（推荐使用华为云市场软件）；6. 关闭不必要的文件共享权限以及关闭不必要的端口，如： 135、139、445等。注意：修复漏洞前请将资料备份，并进行充分测试。