我目前手上有一个棘手的需求，需要在服务器上利用KVM运行32位的Linux操作系统。通过搜索网络我发现许多64位的ARM处理器已经不具备32位的支持，或者仅仅在个别EL下支持32位。我正在寻找具备EL1和EL0下的32位支持、且具备虚拟化扩展的64位ARM处理器。请问有使用过搭载鲲鹏916和鲲鹏920处理器的服务器的同行吗？鲲鹏916和鲲鹏920是否具备EL0和EL1下的32位支持？

Golang 语言开发服务器，为啥能火起来？比起传统的java、c++有啥优势

【问题来源】【必填】湖北农信【问题简要】【必填】ctibill文件清理【问题类别】【必填】cti【AICC解决方案版本】【必填】AICC版本 AICC 8.15.0CTI版本 ICDV300R008C23【期望解决时间】【选填】尽快解决【问题现象描述】【必填】cti下的 /ctibill/ctiserverbill/bak 目录下小文件过多，磁盘占用已达到80%，，请问该目录下的文件是支撑哪些业务的？是否可以手动清除？

我目前正在使用 华为 HNS GE/10GE/25GE RDMA Network Controller，请问华为的rdma如何通信，是否支持标准的 libibverbs 接口进行通信。

提供一种液冷服务器的方案，如果把人看做一台计算机，可以发现人的核心发热部件都处于液体环境，同时内部布满了各种管道，通过液体快速流动将热量传到到全身每个角落，人体表面与内部基本形成等温，最大限度的利用了人这一个整体来散热，即核心部件的热量就是人整体的热量，人整体的散热就是核心部件的散热。在这个思路下，我们可以探索如何利用服务器这个整体来散热，我们分两步，1、将热量快速均匀的分布到整个服务器，形成等温体；2、对等温体进行散热。对步骤1，要形成等温体，需要借助液体，服务器存在很多外接端口，操作界面，热插拔硬盘等不适合液体存在的部位。因此，我们将服务器分成两部分，一部分是包含各核心发热部件（芯片）的主板，可以内置于密闭金属盒子中，内部充满液体，另一部分，包括外接插口，操作界面，热插拔硬盘等集成到端部，端部与金属盒子内部主板通过端口连接，并做好密封处理。单纯的液体导热性并不是很好，需要增加液体流动性，或者增加固体散热通道。本方案采用增加固体散热通道，在芯片等核心发热部件增加部分导热效率高的固体材料（如铜管，石墨烯），形成固体导热通道。这样构成两条散热通道，高速专用的固体材料散热通道，热传递快，但是道路狭窄，可以将芯片处的热量快速导出；另一条低速通用的液体材料散热通道，热传递较慢，但是道路极宽，可以将主板其他位置及高速道路上的热量导出，并扩散。两条散热通道都能传递出大量的热量，两者互相配合，形成一种无死角，热传递效率高的综合路径。如此主板在金属盒子内部可以将热量快速均匀分布，形成近似等温体。再对等温体进行散热，等温体的散热面积为其整个表面积，热的交换面积最大化，散热效率自然高，这样将事半功倍。金属盒子略大于主板，在主板能装进金属盒子的前提下，尽量缩减金属盒子的体积，可最大化缩短热量传递路径，提高散热效率。液体在金属盒子内部形成无尘，无氧，无水空间，温度相对较稳定，相对采用风冷散热的服务器内部大温差，有尘，有氧空间，电子元器件的工作条件大大改善。热量和温度并不是同一个概念，较大的热量仍可以形成一个温度较低的大体积散热体，同样的热量，集中在芯片，芯片温度可能达到100℃，但是热量均布在整个主板，内部液体，金属盒子上时，温度可能只有40℃，所以本方案利用液体，固体将热量快速传导，使金属盒子形成近似等温体，核心部件的热量由等温体共同承担。等温体的散热面积为其整个表面积，散热面积最大化，自然散热效率大大提高。 总结本方案的温度控制手段，1、让核心发热部件的热量由等温体整体承担，同等热量下，核心发热部件的温度大大降低。2、对等温体采取高效的散热方式，减小等温体的热量堆积，从而进一步降低核心部件的温度。对金属盒子等温体，可以采用分布式滴灌装置供水，外置两个风扇，一个主风扇，可通水，借助风扇离心力将水雾化，形成混合水汽的流动空气，一个辅助风扇，可以根据服务器发热情况，决定风扇开启数量，以及是否通水，最大化的节约能量。利用水的气化可以高效的散热。液态水变成气态水，其相变吸收的热量相对液体水升温所吸收的热量几何倍数增加，同时水变成气态，会进入高空，将地面热量带入地球高空释放掉，然后气态水遇冷变成液态水，通过降雨再回到地表，在水循环的过程中将热量从地表带入高空，不会对环境造成影响。现有的服务器埋入海底或湖底冷却，或采用河水冷却，都是将热量堆积在水中，会造成热量在水体，在地表的大量堆积，如果长久这样下去，可能会造成很严重的生态灾难。而采用本方案，大量节水，大量节电，不管是成本，还是生态效益都是可以预见的。采用金属盒子形成等温体，是采用水的相变散热的前提条件，金属盒子形成的密封空间，让主板和外界隔绝，同时又让热量传递到金属盒子表面，混合大量雾化水汽的流动空气接触到金属盒子表面，液态水就会发生气化，高效带走热量。为了更方便集成上述设施，可以将服务器金属盒子置于相对密闭的柜子中，端口，操作面，硬盘外露，这样散热通道集中集成，通过通道引导热空气排入到空中。这样，室内环境可控，适合人的日常维护工作。附图1，服务器外形图附图2，机房布置概图附图3，机房布置详细图附图说明：服务器阵列布置，相互之间留一定间距，外界插口，硬盘等集成端位于空间7内，且端部外露，方便维护操作，空间7内部分布有网线，电线等线缆。等温体外部有外罩子4，两者处于空间5，外罩子采用隔热材料，防止热量散失到空间5，空间5内部布设有水管，冷空气从通风设备进入到空间5。外罩子4内部集成滴灌式供水设备，散热风扇两个，分居与等温体两边，其中一个风扇为主风扇，位于芯片一侧，和供水设施相连，可提供混合大量水汽的流动空气，另一个为辅助风扇，可以根据服务器的发热量控制风扇的运行数量和是否通水，风扇运行时，冷空气从进气口3进入外罩子4内部，对等温体进行降温，形成的热空气从出气口6进入空间2，空间2的热空气向上运动，最后随管道排入到外部环境中，完成散热。现有液冷服务器方案，多是通过专用液体将服务器的热量带走，然后通过专用的热交换机，将加热过后的专用液体冷却，专用液体循环使用，同时交换出来的热量通过自然界中的水体带走，热交换过程较多，路径较长，使用的水的，耗费的电多。对比之下，本方案中，热交换过程只有一个，就是在服务器等温体表面，路径极短，使用的水量少，耗电少，管路也不复杂。综上，本方案有很高的使用价值，经济价值。

提供一种液冷服务器的思路，如果把人看做一台计算机，可以发现人的核心发热部件都处于液体环境，同时内部布满了各种管道，通过液体快速流动将热量传到到全身每个角落，在人体表面与内部基本形成等温，最大限度的利用了人这一个整体来散热，即核心部件的热量就是人整体的热量，人整体的散热就是核心部件的散热。在这个思路下，我们可以探索如何利用服务器这个整体来散热，我们分两步，1，如何将热量快速均匀的分布到整个服务器，形成等温体；2，如何对等温体进行散热。对步骤1，形成等温体，肯定要借助液体，服务器存在很多外界端口，操作界面，热插拔硬盘等不适合液体存在的部位，如此，我们将服务器分成两部分，一部分是以主板为主体的，发热核心部件，可以内置于密闭金属盒子中，内部充满液体，另一部分，为外界插口，操作界面，热插拔硬盘等集成到端部，与金属盒子内部主板通过端口连接，并做好密封处理。单纯的液体导热性并不是很好，可以增加液体流动性，但我感觉增加固体散热通道更好，只需在芯片等核心发热部件增加部分导热效率高的固体材料（如铜管，石墨烯），形成固体导热通道。这样构成两条散热通道，高速专用的固体材料散热通道，热传递快，但是道路狭窄，可以将芯片处的热量快速导出；另一条低速通用的液体材料散热通道，热传递较慢，但是道路极宽，可以主板其他位置及高速道路上的热量导出，并扩散。两条散热通道都能传递出大量的热量，两者互相配合，形成一种无死角，散热效率高的综合路径。如此主板在金属盒子内部可以将热量快速的均匀分布，形成等温体。我们再对等温体进行散热，因为等温体的散热面积为其表面积，热的交换面积最大化，效率最高，这样将事半功倍。金属盒子略大于主板，可尽量缩短热量传递路径。液体在金属盒子内部形成无尘，无氧，无水空间，温度相对较稳定，相对采用风冷散热的服务器内部大温差，有尘，有氧空间，电子元器件的工作条件大大改善。热量和温度并不是同一个概念，较大的热量仍可以形成一个温度较低的大体积散热体，同样的热量，集中在芯片，芯片温度可能达到100℃，但是热量均布在整个主板，内部液体，金属盒子上时，温度可能只有40℃。同时等温体的散热面积增加到最大，散热效率最高，温度可进一步降低。 金属盒子完全密封，外部可以采用水的相变来散热。对金属盒子，可以采用分布式滴灌装置供水，外置风扇，借助风扇的离心力，将水雾化，形成混合大量水汽的流动空气，对着金属盒子吹，可以高效的散热。水的相变吸收的热量相对液体水升温所吸收的热量几何倍数增加，同时水变成气态，会进入高空，将地面热量带入地球高空释放掉，然后气态水遇冷变成液态水，通过降雨再回到地表，在水循环的过程中将热量从地表带入高空，不会对环境造成影响。现有的服务器埋入海底或湖底冷却，或采用河水冷却，都是将热量堆积在水中，会造成热量在水体，在地表的大量堆积，如果长久这样下去，可能会造成很严重的生态灾难。而采用我的方案，大量节水，大量节电，不管是成本，还是生态效益都是可以预见的。可以外置两个风扇，一个主风扇，可通水，一个辅助风扇，可以根据服务器发热情况，决定风扇开启数量，以及是否通水，最大化的节约能量。为了更方便集成上述设施，可以将服务器金属盒子置于相对密闭的柜子中，端口，操作面，硬盘外露，这样散热通道集中集成，通过通道引导热空气排入到空中。这样，室内环境可控，适合人的日常维护工作。附图1，服务器外形图附图2，机房布置概图附图3，机房布置详细图如上图所示，冷空气，热空气分流，散热风扇，水管全部分布式布置，可以根据具体服务器的散热需要调度安排。本方案是否可行，可否用来建设数据中心？

为什么提交的作品一直显示评分中，也没有报错反馈。

安装报错[gauss-51615]欧拉、麒麟、等系统一样的报错。CPU型号FT2000

本地与云服务器互联互通，如何解决？本地与A区云服务通过专线互联，A区云服务器与B区服务器通过云专线互联。B区服务器需要与本地互联（最好直接互联互通，有1000个端口要互通），求问各位专家应该如何操作？

想知道如何在鲲鹏平台上快速上手应用开发吗？鲲鹏DevKit告诉你答案！本期直播将聚焦鲲鹏DevKit，它集成了开发、编译、调试、调优、测试等软件开发的各个环节，帮助开发者完成基于鲲鹏服务器的一站式应用开发，提升应用开发效率，提升应用性能。直播链接：cid:link_0Q：鲲鹏DevKit 应用迁移工具支持哪些系统平台迁移？A:目前主要支持CentOS迁移到麒麟Q：鲲鹏DevKit有哪些行业应用案例？A:医疗、金融、运营商、基础科研、制造、电力、气象、交通、安平、互联网、政府、大企业Q：如何评估使用鲲鹏 DevKit 开发的应用的性能提升效果？A:评估应用性能，可以从以下几个方便入手：1，选取相关的基准测试，测量响应时间、吞吐量等指标；2，使用devkit性能采集工具，可以采集应用的性能指标，分析性能的瓶颈和改进空间；3，评估资源的利用情况，包括CPU、内存、磁盘和网络等，使用合理的分析方法，如TMA、roofline等。Q：对于新手开发者来说，鲲鹏 DevKit 的学习曲线是怎样的？ 7. 它是否提供了丰富的文档和教程资源来帮助开发者快速上手？A:鲲鹏社区具有全套的DevKit学习流程和学习课程，可以根据课程顺序进行学习。地址为：https://www.hikunpeng.com/learn/courses?activeTab=1547169694099677185 文档可以参考鲲鹏社区的DevKit用户手册和最佳实践，地址为https://www.hikunpeng.com/document/detail/zh/kunpengdevps/overview/kunpengdevps.htmlQ：目标VM和Java程序在线分析的精度是如何确定的？ 如何便捷存档数据便于后续相同业务对比分析？A:精度提供采集频率1ms-1000ms动态配置，可以灵活选择。在线分析和采样分析的数据支持导入导出，以方便后续相同业务对比分析。Q：鲲鹏DevKit系统性能分析工具包括哪些功能？A:性能分析工具目前包括：场景化ai调优分析、调优助手、全景分析、HPC分析、微架构分析、访存分析、进线程分析、热点函数、I/O分析、锁与等待分析、Roofline分析、资源调度分析等功能。Q：鲲鹏DevKit 系统性能分析工具中，HPC集群检查能检查哪些内容？A:通过对用户指定的MPI集群进行硬件、软件配置检查，并给出集群中各节点软硬件配置的一致度报告。检查对象支持硬件领域的CPU、GPU、互联、内存、网卡、磁盘，软件领域中的OS、Kernel、环境变量、MPI、OpenMP、HPC常用依赖库等维度。对于不符合鲲鹏平台最佳实践的配置，工具会给出优化建议。Q：鲲鹏DevKit 源码迁移支持哪些开发语言？A:ASM/C/C++/Fortran/Python/Java/Scala/GoQ：鲲鹏DevKit 系统迁移中支持哪些操作系统、中间件、数据库？A:系统：CentOS->麒麟V10中间件：Nginx，Redis，Tomcat，金蝶、东方通数据库：达梦、人大金仓Q：在线分析中如何保证系统额外开销小？采样分析的采样频率如何确定？A:在线分析支持采集频率1ms-1000ms动态配置，以更精确地捕获方法的耗时，这使得对于耗时较小的方法调用也能进行有效统计，从而提高了分析的精度。Q：与其他类似的开发工具相比，鲲鹏 DevKit 的优势在哪里？A:鲲鹏DevKit更加贴合鲲鹏平台底层，由于鲲鹏底层针对软件做了大量优化，DevKit能够更好地利用这些优化措施，完成开发调优。Q：鲲鹏DevKit Java性能分析工具主要用途是什么？A:Java性能分析工具是针对基于鲲鹏的服务器上运行的Java程序的性能分析和优化工具，能图形化显示Java程序的堆、线程、锁、垃圾回收等信息，收集热点函数、定位程序瓶颈点，帮助用户采取针对性优化。Q：鲲鹏DevKit 系统性能分析工具中，全景分析有什么作用？A:通过采集系统软硬件配置信息，以及系统CPU、内存、存储IO、网络IO资源的运行情况，获得对应的使用率、饱和度、错误次数等指标，以此识别系统性能瓶颈。针对部分系统指标项，根据当前已有的基准值和优化经验提供优化建议。Q：鲲鹏DevKit 亲和分析工具对平台有要求吗？A:有的，亲和分析支持鲲鹏平台Q：鲲鹏DevKit 支持哪些工具？A:目前DevKit支持VSCODE和网页端模式，囊括的开发工具包括迁移、开发、调试、亲和、调优、诊断等工具。Q：鲲鹏DevKit 是否有demo环境可以体验？A:可以通过www.hikunpeng.cm官方网站中，开发者选项里的学习选项，体验在线实验功能，提供云实验环境供开发者体验。Q：目标VM和Java程序的在线分析，如何针对不同的VM进行适配？如何提高在线分析对大型Java程序的适用性？A:java性能分析工具支持对jdk8-jdk17程序进行分析，支持的jdk包括Oracle JDK，毕昇Jdk。Q：AITunner调优是自动的吗A:是的。AITuner使用自研高性能AI调优方案，通过用户自主选择测试用例，对数据库和大数据场景进行自动优化，自动调优后给予最优参数配置，提供复杂场景下参数配置的优化建议。Q：全面调优包含哪些层面的优化，是如何协调不同层面的？ 软硬件融合释放最佳性能，硬件和软件之间是如何交互协作的？A:全面调优包括：硬件、os和基础设施、应用层、数据和存储、网络等。一般协调不通层面的性能问题，可以通过分析性能瓶颈、逐层优化改进性能问题，确保每层改进都能带来整体的性能提升，监控系统性能，根据实时数据调整优化，确保各层面优化相互配合。常见的软硬件交互协作包括：硬件加速器、优化指令集、缓存优化、资源调度、反馈优化机制等。Q：是否有成功的应用迁移或开发案例供参考？A:可以参考hikunpeng网站的最佳实践章节：https://www.hikunpeng.com/document/detail/zh/kunpengdevps/handon_tutorials/bestpractice/kunpengDevKitPractice_0062.htmlQ：请问python+c+java可以同时进行性能调优吗？A:明前提供python+c的热点函数分析能力，以及单独的java和c的分析能力，可以灵活使用。Q：进程和线程之间的优先级关系应该如何分析？如何解决死锁和锁竞争问题？A:进线程的优先级需要考虑系统的调度策略、进程和线程的负载以及他们之间的依赖关系。避免死锁可以考虑：避免资源独占；确认线程申请资源时不持有其他资源；设计可抢占系统；减少循环等待链。编码时可以减少锁的粒度，使用读写锁或乐观锁提高锁的效率，设置超时机制等方式。Q：有具体的案例或者视频演示一下吗？关于性能调优方面的A:可以参考hikunpeng网站的最佳实践章节：https://www.hikunpeng.com/document/detail/zh/kunpengdevps/handon_tutorials/bestpractice/kunpengDevKitPractice_0062.htmlQ：鲲鹏DevKit 系统性能分析工具中，Agent管理有什么作用？A:Agent是负责实际运行采集插件的组件。通过将采集组件分离，可以实现分布式采集能力，方便用户部署多机采集能力。Q：调优助手给出的调优建议是基于什么模型或算法？专项分析是针对哪些特殊问题或场景开展的？A:调优助手是根据测试反馈和经验得到的优化建议。专项分析目前是对pc领域提供了独特的采集分析的方法和思路。Q：在调优过程中，如何平衡性能提升与资源消耗（如内存、CPU、网络带宽等）之间的关系？鲲鹏 DevKit 有哪些优化原则和方法？A:性能提升的目标就是提高资源利用的能力，为了平衡资源和性能就是在调优过程中关注资源的利用效率的指标。在资源消耗一定的情况下，需要提高资源利用的效率，将浪费的资源用上，将用上的资源用好。DevKit有很多分析和优化的方法，如cpu分析的TMA分析法、numa内存分析、roofline分析等。Q：那鲲鹏的性能调优可以直接在鲲鹏平台上进行性能调优吗？A:性能调优工具提供强大的采集能力，并基于采集结果和历史经验给出相关的调优建议；并且在一些场景提供了AI自动调优能力。Q：缺乏迁移经验的开发人员，应该关注哪些分析报告？A:如果是Java系统进行迁移，可以关注系统迁移的迁移结果报告；如果是其他语言，可以考虑源码迁移的迁移结果报告。Q：那对于鲲鹏平台来说，迁移什么语言主导的软件更好迁移呢？A:目前迁移Java系统更加方便迁移，因为我们针对Java系统场景做了系统迁移功能，能够端到端的实现鲲鹏迁移。Q：扫描软件安装包时，如何识别so依赖库兼容信息的准确性？有没有误判的可能？A:目前是存在误判的可能，用户可以通过手动拆包验证，或者直接执行验证去判定是否兼容，如果不兼容可以关注报告中是否存在兼容so的下载链接进行替换。Q：对于大型复杂项目的代码扫描，鲲鹏DevKit应用迁移的资源占用情况如何？是否会影响其他系统进程？A:这个取决于具体用户项目，更具用户反馈，暂时没有出现影响其他系统进程的场景。Q：扫描过程中如何确保对所有依赖库文件的扫描无遗漏？有没有特定的检查算法或者机制？A:我们针对依赖库的白名单是有定期更新机制的，但如果要确保所有依赖文件均可正常运行，需要用户执行手动测试验证。Q：请问在企业级应用中，中间件通常与其他系统组件紧密集成，自动迁移部署中间件时，如何确保与其他组件的兼容性和协同工作能力？A:自动迁移部署中间件时，我们主要确保了中间件能够正常启动，如果要确保应用和中间件的协同工作正常，需要参考迁移指导建议，针对配置文件等进行手动修改，修改完成后即可确保正确。Q：自动分析系统成分的准确性如何保证？是否存在误判或遗漏某些关键系统成分的可能性？如果出现这种情况，如何进行人工复核和修正？A:目前确实存在误报等情况，对此我们提供了系统成分修正功能，可以在扫描完成后增删改查Q：系统迁移就是说整个迁移吗还是？A:系统迁移指的是将整个Java应用程序系统进行搬迁，包括应用、中间件、数据库等。Q：迁移的目标系统，只能是openeuler，还是支持其他的linux？毕昇的make，支持c++哪些版本、java哪些版本？A:迁移的目标系统包括openEuler系的系统，如麒麟统信等常用国产OS，以及一些常用OS，详细信息参见：https://www.hikunpeng.com/document/detail/zh/kunpengdevps/userguide/usermanual/DevKit_Porting_0011.html 编译器支持版本也可参见：https://www.hikunpeng.com/document/detail/zh/kunpengdevps/userguide/usermanual/DevKit_Porting_0011.htmlQ：如何确保编译过程中的依赖项兼容鲲鹏架构？A:可以尝试使用应用迁移中的源码迁移，扫描makefile，查看是否存在不兼容编译选项。Q：如何确保在鲲鹏 DevKit 上迁移的软件与原软件在功能上完全一致？是否存在某些功能在迁移后无法正常使用的风险？A:鲲鹏DevKit迁移后的软件与原软件保持一致，除了需要使用DevKit进行迁移，还依赖用户执行手动测试，针对已有应用的测试用例进行执行，根据测试结果确认迁移后是否一致。 软件某些功能无法使用只会出现在使用了与硬件架构有关的功能中，这在实际编码中非常少，比如intel的内联函数，而这部分鲲鹏已经有替换的兼容库。Q：是否提供了专门的性能分析工具来帮助开发者识别瓶颈？A:是的。DevKit内置性能分析工具，可以帮助开发者识别性能瓶颈，达成快速调优的目标。Q：DevKit支持一站式应用开发吗？如何做好性能分析？A:鲲鹏 DevKit 确实支持一站式应用开发，从代码编写到性能调优都可以在一个环境中完成。它提供了丰富的性能分析工具，帮助开发者在开发过程中进行全面的性能分析和优化。Q：如何确保现有的x86架构上的应用程序能够顺利迁移到鲲鹏平台上？A:针对不同的语言和场景，我们有不同的解决方案，如果是Java系统，我们有系统迁移工具，确保X86的应用程序能够顺利迁移到鲲鹏平台，其他语言，我们可以使用源码迁移进行迁移工作。完成迁移后我们需要进行人工功能验证，保证应用功能正确性。Q：鲲鹏只能运行在鲲鹏CPU硬件上吗？如果我用麒麟的笔记本，比如L420，可以装IDE进行开发吗？A:鲲鹏指鲲鹏服务器，相关插件都是部署在鲲鹏服务器上。用户可以通过笔记本按照IDE远程连接服务器进行开发。Q：鲲鹏只能运行在鲲鹏CPU硬件上吗？如果我用麒麟的笔记本，比如L420，可以装IDE进行开发吗？A:鲲鹏指鲲鹏服务器，相关插件都是部署在鲲鹏服务器上。用户可以通过笔记本按照IDE远程连接服务器进行开发。Q：应用迁移过去有啥好处呢？ 网络协议不一定兼容A:迁移到鲲鹏上能够使用鲲鹏软硬件结合的优势，进一步提高应用的运行速率。Q：在遇到问题时，是否有官方支持渠道或社区可以帮助解决？A:可以在www.hikungpeng.com官网社区反馈。想要了解更多鲲鹏 DevKit 相关知识，欢迎观看DTSE Tech Talk 系列技术直播

有人知道sh巡检文件纹样安装怎样安装吗

比如收集到这些json类型的消息，如何将这些数据传到华为云服务器，或者有没有更好的方法可以让DTU模组将数据实时传到服务器，IOT这里将数据进行操作吗：

安装完dotnet后执行dotnet --info报错，  执行dotnet --list  又没问题 ，大概意思libicuil8n..so.50这个文件有问题，但又找不到正常文件cannot get symbol ucol_setMaxVariable_50 from libicui18n error:/lib64/libicuil8n..so.50: undefined symbol:ucol_setMaxVariable_50 Aborted

sdk版本为3.21.11，实现的功能是依次下载obs内多个文件，并打包生成压缩包放在硬盘路径内首先在本地pc测试无问题，均能正常依次下载文件，但在华为云服务器（华北北京4的服务器，带宽5M）上运行，有很高频率压缩包会生成失败使用文档提供的 带获取进度的下载 示例来测试，观察日志发现，压缩包生成失败的原因，是在某几个文件上会有很高的频率下载到一定进度后就无响应（进度百分比的日志输出到不固定的某个进度后就停止了），直到超过设置的ConnectionTimeout和SocketTimeout时间，才抛出了SocketTimeoutException: Read timed out的异常（未捕获到ObsException异常），进而造成压缩包生成失败问题1：是否有办法继续定位 文件下载到一定进度后就无响应 问题原因的办法？问题2：如果考虑 捕获到SocketTimeoutException: Read timed out后进行重试机制，这边就希望能将设置的ConnectionTimeout和SocketTimeout时间缩小以减少重试的等待时间，但如果因为下载的文件过大，导致文件没有在这两个时间内下载完成，是否也会直接下载失败？注：试过直接在服务器下的浏览器访问这几个文件的url地址，均能正常获取到，所以我猜不是网络原因

 文章目录 一、Libevent概述 1.两个重要的结构体 2.libevent常用接口 二、libevent IO事件 三、libevent信号事件 四、libevent高并发服务器 参考 一、Libevent概述 Libevent 是一个用C语言编写的、轻量级的开源高性能网络库，主要有以下几个亮点：事件驱动（ event-driven），高性能;轻量级，专注于网络，不如 ACE 那么臃肿庞大；源代码相当精炼、易读；跨平台，支持 Windows、 Linux、 *BSD 和 Mac Os；支持多种 I/O 多路复用技术， epoll、 poll、 dev/poll、 select 和 kqueue 等；支持 I/O，定时器和信号等事件；注册事件优先级。 　 　　Libevent 已经被广泛的应用，作为底层的网络库；比如 memcached、 Vomit、 Nylon、 Netchat等等。Libevent之于C语言网络编程，类似于Nettty之于Java Web编程。学习Netty的小伙伴，不防看下Libevent的实现，会加深对Netty框架的理解  安装方式（1）：  $ apt-get download libevent-dev $ dpkg -x  libevent-dev_2.1.12-stable-1build3_amd64.deb libevent 1 2 安装方式（）：  libevent的download urls github assert 1.两个重要的结构体 struct event-base  事件集合 struct event_base用于创建和管理事件循环，而struct event用于表示具体的事件，并与事件循环相关联。 struct event_base 代表一个事件处理的基础框架，它负责管理事件循环（event loop），接收事件并将它们分派给相应的事件处理器。 struct event_base 实例典型地代表了一个事件驱动程序的运行环境，它可以被视为事件循环的主体。 struct event_base 可以支持多种事件驱动的后端（如select、poll、epoll等），因此在创建 struct event_base 实例时，可以指定使用的后端。 struct event  一个事件（可以是一个fd，也可以是一个signal，也可以是一个定时器事件） struct event 包含了事件的相关信息，比如事件类型（读、写、定时器等）、事件触发时需要执行的回调函数等。 当文件描述符上发生关注的事件时，struct event 将通知 struct event_base，然后 struct event_base 将事件分派给相应的事件处理器执行。 两者关系：  struct event结构体中有一个指向struct event_base的指针，用于指示该事件所属的事件循环。这样，当事件发生时，事件循环可以根据事件的描述找到相应的回调函数并执行。 2.libevent常用接口 event_init  用于初始化 libevent 的全局状态。在使用 libevent 前调用此函数是必要的步骤，它会进行一些全局状态的初始化工作。 event_base new  event_base_new 用于创建一个新的事件基础框架（struct event_base 实例）。 返回的 event_base 实例将用于管理事件循环和事件处理。 event_set  event_set 用于设置事件的相关属性，比如事件关联的文件描述符、事件类型、以及事件触发时执行的回调函数。 这个函数被废弃了，不建议使用，建议使用 event_assign 替代。 event_assign  event_assign 用于将事件与指定的 event_base 关联起来，并设置事件的属性。 这个函数类似于 event_set，但是更加灵活，可以避免一些使用上的混淆。 event_add  event_add 用于向事件循环中添加一个事件，让它开始监视文件描述符上的事件。 添加事件后，事件循环将开始监视文件描述符，当有事件发生时，会触发事件的回调函数。 evconnlistener_new_bing  evconnlistener_new_bind 是用于创建一个监听器（listener）的函数，用于监听指定地址和端口上的连接请求。 当有连接请求到达时，监听器将接受连接并创建一个新的套接字来处理该连接。 二、libevent IO事件 fifo-read.c  #include <event.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <sys/stat.h> #include <unistd.h>  void fifo_read(evutil_socket_t fd, short events, void *arg) {    char buf[32] = {0};    int rt = read(fd, buf, sizeof(buf));   if (-1 == rt) {     perror("read");     exit(-1);   }    printf("read <%s>\n", buf);   return; }  int main() {   int ret = mkfifo("fifo.tmp", 0700);    if (-1 == ret) {     perror("mkfifo");     exit(-1);   }    int fd = open("fifo", O_RDONLY);   if (-1 == fd) {     perror("open");     exit(-1);   }    struct event ev;    event_init();    event_set(&ev, fd, EV_READ, fifo_read, NULL);    event_add(&ev, NULL);    event_dispatch();    return 0; } fifo-write.c   #include <fcntl.h> #include <stdio.h> #include <string.h> #include <unistd.h> int main() {   int fd = open("fifo.tmp", O_WRONLY);   if (-1 == fd) {     perror("open");     exit(-1);   }    char buf[32] = {0};    while (1) {      scanf("%s", buf);     int ret = write(fd, buf, sizeof(buf));     if (-1 == ret) {        perror("write");       exit(-1);     }      if (!strcmp(buf, "bye")) {       break;     }     memset(buf, 0, sizeof(buf));   }    return 0; } 三、libevent信号事件 signal.c   #include <event2/event_compat.h> #include <event2/event_struct.h> #include <signal.h>  static int signal_count = 0;  void signal_handler(evutil_socket_t fd, short events, void *args) {   printf("<sig: %d>\n", fd);    ++signal_count;    if (signal_count >= 2) {     event_del((struct event *)args);   } }  int main() {   struct event_base *base = event_base_new();    struct event ev;   event_assign(&ev, base, SIGINT, EV_SIGNAL | EV_PERSIST, signal_handler, &ev);    event_add(ev, NULL);    event_base_dispatch();    event_base_free(base);    return 0; } 四、libevent高并发服务器  #include <arpa/inet.h> #include <cstddef> #include <event2/bufferevent.h> #include <event2/bufferevent_struct.h> #include <event2/event_compat.h> #include <event2/listener.h> #include <netinet/in.h> #include <stdio.h> #include <stdlib.h> #include <string.h>  void read_cb(struct bufferevent *bev, void *ctx) {   char buf[128] = {0};   size_t ret = bufferevent_read(bev, buf, sizeof(buf));   if (ret < 0) {     exit(-1);   }    printf("read from: <%d>\n", *(int *)ctx); }  void event_cb(struct bufferevent *bev, short what, void *ctx) {   if (what & BEV_EVENT_EOF)     printf("Client: <d> down", *(int *)ctx);   bufferevent_free(bev); }  void listen_cb(struct evconnlistener *listener, evutil_socket_t fd,                struct sockaddr *addr, int socklen, void *arg)  {   static int gFd = -1;   printf("Accept: <%d>\n", fd);    gFd = fd;    struct event_base *base = arg;    struct bufferevent *bev =       bufferevent_socket_new(base, fd, BEV_OPT_CLOSE_ON_FREE);   if (NULL == bev) {     exit(-1);   }    bufferevent_setcb(bev, read_cb, NULL, event_cb, &gFd);    bufferevent_enable(bev, EV_READ); }  int main() {   struct event_base *base = event_base_new();    if (NULL == base) {     printf("event_base \n");      exit(-1);   }    struct sockaddr_in server_addr;   memset(&server_addr, 0, sizeof(server_addr));   server_addr.sin_family = AF_INET;   server_addr.sin_port = 8000;   server_addr.sin_addr.s_addr = inet_addr("127.0.0.1");    struct evconnlistener *listen = evconnlistener_new_bind(       base, listen_cb, NULL, LEV_OPT_CLOSE_ON_FREE | LEV_OPT_REUSEABLE, 10,       (const struct sockaddr *)&server_addr, sizeof(server_addr));    event_base_dispatch(base);    evconnlistener_free(listen);   event_base_free(base);    return 0; } ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/u011436427/article/details/138468568