content.json

{"pages":[],"posts":[{"title":"OutOfMemory的Kafka学习笔记(1)","text":"背景Kafka是Apache的顶级消息中间件项目，因为强大的处理能力，被广泛应用于大数据处理和日志采集等领域，发展的前景非常好。 我希望通过对Kafka的学习，深入了解流式数据处理的基本原理，为深入大数据领域的工作奠定基础。 同时也希望能够在金融业务处理中借鉴或引入相关思想和技术。 目标 理解Kafka的原理、架构和关键处理机制 掌握构建、部署和管理Kafka集群的技术 掌握Kafka的参数配置和应用编程 熟悉Kafka关键处理模块的源码 为Kafka开源项目贡献力量 计划 每周至少两个番茄投入 先学习了解Kafka官方文档，了解Kafka的基本概念 搭建Kafka集群 学习Kafka集群管理和基本功能 学习Kafka参数配置和应用编程 制定学习Kafka源码想要了解的问题，并不断完善 从Kafka的核心功能入手，理解源码的结构和主要逻辑 搭建Kafka编译环境，编译、构建Kafka程序 尝试重现和调试Kafka开源项目的issue 官方文档学习官方网站: kafka.apache.org/Kafka的核心能力 高吞吐 使用一组集群机器，可以以达到网络限制的吞吐处理消息，时延低至2ms 灵活扩展 生产集群可以扩展至上千broker，每天处理万亿级消息、pb级数据、数十万分区，可弹性伸缩的存储和处理能力 永久性存储 将数据流存储在分布式的、持久的、容错的集群中 高可用 将集群伸展到多个可用的区域，或可连接多个地理分隔的集群 introduction video跟随官网指引观看了一个Kafka的introduction视频，提到了几个核心要点： Kafka描述事件而不是描述对象，事件以log的方式被永久性存储 Kafka将一系列事件log描述为一个topic，应用程序可以产生和消费topic中的事件记录 Kafka可以应用于将宏服务拆分为相互独立的微服务架构 Kafka connect工具可以连接已有系统的数据库，将数据导入Kafka，提供给其他应用程序消费 Kafka提供join聚合、过滤topic数据的能力，应用程序通过steam api操作 Apache Kafka 定位为事件流式处理平台,流式处理就像是人类身体的神经系统，一个很形象的比喻 To publish (write) and subscribe to (read) streams of events, including continuous import/export of your data from other systems. To store streams of events durably and reliably for as long as you want. To process streams of events as they occur or retrospectively.","link":"/2021-01-16-leaning-kafka-1/"},{"title":"Guide to UUID in Java","text":"by baeldung 原文地址:https://www.baeldung.com/java-uuid 最近没怎么写代码，简单复习一下Java的UUID知识点吧，原文来自于baeldung，这个网站有很多Java语言的技巧，经过我长期观察，内容相对各种中文博客是严谨靠谱很多的，可以日常看看，巩固知识。 1.概览Java中的UUID是一个128bit的值，通常用十六进制数字加”-“字符表示为长度36位的字符串，例如123e4567-e89b-12d3-a456-556642440000，因为128bit是16字节，而一个字节可以表示为2个十六进制字符，”-“符号纯粹是为了可读性添加的，不实际存储于数据中。 UUID广泛用于表示全局唯一值的场景，但是并不是完全不会重复，只是重复的概率较小，在数据量较大和多服务器环境中要注意UUID可能出现重复。 2.Java的UUID类Java的UUID类有构造函数，具体我就不列了，因为不常用，UUID提供了三个便利的静态方法来生成UUID，最常用的是UUID uuid = UUID.randomUUID();，这个方法会生成一个version 4标准的UUID。 3.结构12123e4567-e89b-42d3-a456-556642440000xxxxxxxx-xxxx-Bxxx-Axxx-xxxxxxxxxxxx 3.1 UUID变体结构里面的A位置（第9个字节）的前三位表明了变体的种类，示例里面的小写a (=10xx)说明是variant 2。 12345MSB1 MSB2 MSB3 0 X X reserved (0) 1 0 X current variant (2) 1 1 0 reserved for Microsoft (6) 1 1 1 reserved for future (7) 3.2 UUID版本结构里面的B位置（第7个字节）的前四位表示版本号，这里版本号是4。对于当前variant 2的UUID来说，有5个不同的版本， java实现了v3和v4版本，并且提供一个构造函数可以自定义生成任意规则的UUID。 Time Based (UUIDv1) 基于当前设备的时间戳和MAC地址 DCE Security (UUIDv2) 也是基于时间戳和MAC地址，但是RFC 4122中没有描述详细实现规则 Name Based (UUIDv3 and UUIDv5) 基于命名空间和名称的hash生成，v3和v5的区别在于hash算法不同， v3使用MD5(128 bits)而v5使用SHA-1(160 bits)。 Random (UUIDv4) 基于随机数生成，Java实现使用SecureRandom生成一个不可预测的随机数种子，以减少重复的概率。","link":"/2021-01-17-guide-to-uuid-in-java/"},{"title":"Maximizing Developer Effectiveness Review","text":"Tim Cochran, 06 January 2021 原文地址:https://martinfowler.com/articles/developer-effectiveness.html 背景这篇文章是一系列文章的开篇，作者观察到许多企业在引入新技术后，开发者的效能不增反降，作者认为这是由于新技术的复杂性和认知负担导致的。 通过研究，作者识别了开发者的关键反馈回路（key developer feedback loops），包括开发者每天重复200次的微反馈回路（micro-feedback loops），本系列文章试图引入一个最大化开发者效能的框架，通过优化这些回路提高开发者效能。 作者经常帮助转型中的组织，这些组织通常同时面临技术转型和文化转型，例如将宏服务拆分为微服务架构，建立独立迭代的团队和DevOps流水线，同时采取敏捷的产品开发以更快响应市场。 但是这样的转型经常失败，经理们不满意交付延迟和预算超支，技术人员忙于解决各种绊脚石，生产效率低下，团队同时开展许多依赖项繁多的工作、认知超载、对新工具新流程缺乏掌握。最终向领导层承诺的成果无法兑现。 作者认为主要的原因在于组织忽视了给开发人员提供高效的工作环境。在转型中引入了太多的新流程和新工具，给每日的工作带来了更大的复杂性和阻力。 高效工作环境中的开发人员作者假想了高效工作环境中的开发人员应该是怎么样的 通过项目管理工具了解工作进展和当天工作内容 研发环境自动升级到最新版本，CI/CD通过 拉取最新代码，增量代码可以通过本地环境部署和单元测试快速验证 对于依赖其他团队提供的功能，能够通过开发者中心方便找到文档说明和API接口规格 几小时不受打扰的专注于自己的工作 中途放松休息 提交代码，通过一系列自动化检查校验后部署到生产环境，灰度发布给用户，同时监控业务和运营指标变化。 作者也列举了低效开发人员的工作是什么样的，大致就是陷入无尽的生产告警、问题排错、低效的沟通、无意义的会议等等，我就不详细列出了，大部分人看看自己每天的工作就有同感。 对比我工作的体会，我将重点内容以黑体标识了，这些目标可以用来评估我们建立DevOps工作流程是否高效，至于用什么工具和方式达到是次要的，经常回顾一下可以是我们不至于陷入技术细节忘了初心。 作者提到低效的组织工作起来摩擦更大，久而久之这种工作方式就被工程师习以为常了，大家会认为软件开发本身就是这样，这种现象叫习得性无助（learned helpless）。为了改变现状，低效的组织更倾向于寻求度量开发者开发产出的方法，常见的反模式是度量代码行数、需求产出数量和花费大量精力找出表现不好的人（Damn right，怀疑作者在监控我们^_^）。 开发者效能作者提出更好的办法是关注于如何创造更好的高效工作环境，更顺畅的工作环境会给员工更多创新的机会。我赞同作者的观点，这是一种基于对员工信任的管理思路，但是国内大部分公司依然是一种不信任员工的思路在管理，依然把人视为流水线上的工具，我们为“鞭策”那一小部分员工牺牲了大多数人的创造性。 案例研究：Spotify作者接下来列举了Spotify的例子，Spotify为了解决内部工具碎片化和开发信息不透明的问题，开发并开源了一套开发者门户项目Backstage，去Backstage的官网看了下，提供服务目录、项目模板、技术文档等功能，同时有快速增长的插件生态，这跟我们去年在建设的架构资产管理平台很多诉求是相通的，肯定有许多理念和能力可以借鉴，要是早半年看到就更好了，虽然现在看到也不晚。 接下来是最重要的部分，作者阐述了应该从哪些方面入手提高组织效能。 常见的是建立DevOps文化等等，四个关键度量指标（前置时间、部署频率、平均修复时间、变更失败率）。 反馈回路（Feedback Loops）作者研究了一系列反馈回路，推荐专注于优化这些反馈回路来提高效率 反馈回路 低效组织 高效组织 验证本地代码修改的正确性 2分钟 5-15秒（根据技术栈） 找到故障的根因 4-7天 1天 验证组件集成的正确性 3天-2周 2小时 验证变更是否满足非功能要求 3个月 1天到1周（根据变更范围大小） 进入新团队后能够有效产出的时间 2个月 4周 内部技术咨询得到回答的时间 1-2周 30分钟 在生产发布一个新的服务 2-4个月 3天 验证一项变更对客户有用 6个月或者没办法 1-4周 （根据变更范围大小） 就我的体会而言，这些选项并不是都特别典型，标准各个企业也不尽相同，例如验证本地代码正确性这一点，有的团队可能只要编译通过、代码检查通过就达标，有的团队可能要求主流程测试通过，因此需要根据企业的情况调整，这里的关键是借鉴这样贴合实际并且量化的思路，发掘适合自己的关键反馈回路。 最后，作者介绍了微反馈回路，就是开发者每天会做几十上百次的操作，例如修复bug时反复运行单元测试、提交代码修改到本地环境、刷新环境数据等等，这些微反馈回路太细小通常容易被企业忽略。 这让我深有体会，2020年我们的DevOps团队花了一个多月的时间，将每次代码提交增量检查的耗时从几分钟优化到几秒，耗费的精力不少，但是在企业层面很难看到这样工作的成绩和效果具体是什么。作者后续也提到了这一点，大致就是说每次优化的时间乘以频率就会有很大不同，从逻辑上我是认同的，但是实际工作中，高层管理人员尤其是非技术的管理人员，对此通常毫无理解。 好了，这篇文章的信息含量其实很大，作者在文章中附带了许多概念的介绍链接例如习惯性无助、DevOps文化等等，也推荐了Accelerate等书籍和文章，值得慢慢消化，今天的文章评析就到这里，期待作者后续的文章。","link":"/2021-01-17-maximizing-developer-effectiveness-review/"},{"title":"Open Source Load Testing Tool Review 2020","text":"Ragnar Lönn, 04 MARCH 2020 原文地址:https://k6.io/blog/comparing-best-open-source-load-testing-tools 摘要今年想在DevOps平台上集成一些性能测试的工具，方便开发团队自助进行性能测试，调研了一些工具，分享其中一篇文章。 这篇文章的作者分别在17年和20年对市面上的性能测试工具进行了详细的比较和评测，内容非常翔实，他自己也是其中k6工具的作者。 文中参与评测的12款工具的清单如下： 123456789101112Apachebench 2.3Artillery 1.6.0Drill 0.5.0 (new)Gatling 3.3.1Hey 0.1.2Jmeter 5.2.1k6 0.26.0Locust 0.13.5Siege 4.0.4Tsung 1.7.0Vegeta 12.7.0Wrk 4.1.0 文章主要关注众多测试工具的两方面内容：一是性能表现如何，二是易用性如何。 主要内容 介绍了各个工具的基本信息，包括License、实现的语言、脚本化/多线程/分布式支持等，今年Drill作为唯一的Rust实现的工具被加入比较，简单数了一下其他语言实现的数量： C语言 3，NodeJS 1， Scala 1，Go 3，Java 1，Python 1，Erlang 1。 比较各个工具的开发活跃度，Jmeter、k6、Gatling、Locust最活跃，wrk改动较少，Apachebench没怎么维护了 介绍各个工具的历史和背景，Wrk看起来非常稳定和性能强大，缺点就是不支持HTTP/2和一些新功能， Hey的输出很简洁清晰，在支持脚本化的工具中Locust被认为很棒，当然从作者的角度k6是最好的。 介绍了性能测试的一些观察指标，例如CPU负载、内存消耗、网络延迟、网络带宽，以及这些指标对理论性能的约束。 文章测试了工具的最大流量生成能力、每个虚拟用户（VU）的平均内存消耗、每笔请求的平均内存消耗、响应时间的测量精准度。 最大流量生成能力，Wrk独树一帜（5w RPS），Hey紧随其后（1.8w RPS），k6 1.1w，Jmeter 7000，Locust 2900， Drill拉胯。 内存占用方面，Java和Python的工具内存消耗最大，C和Go编写的表现更好。通过观察每个虚拟用户的平均内存消耗和每笔请求的平均内存消耗，作者发现除了Jmeter，大部分工具的内存占用并不会随着VU的增长而增长。 在响应时间的测量精准度方面，Wrk产生了4.5w RPS，但是响应时间中位数为1.79ms（Amazing），而Artillery只有266 RPS，响应时间中位数高达158ms。 测试总结，Gatling更像现代版的Jmeter，Hey很适合简单的命令行测试，Vegeta适合更复杂一些的命令行测试场景， Jmeter太笨重也许适合非开发者用户，作者推荐在面向开发者的自动化测试场景使用k6，推荐喜欢用Python写测试脚本的用户使用Locust，推荐在希望产生海量请求的场景使用Wrk。 最后，文章的评论中有人提到了一些不错的工具，例如Grinder（Java）、Yandex Tank（Python），也有人提到Gatling的测试成绩有偏差，作者重新经过warm up之后测试能达到4000 RPS，比Jmeter要快 后记这些工具里面之前用得多的就是Jmeter，看完文章后去了解了下Gatling，可惜只有企业版有很完善的可视化报告界面，相比之下k6的做法更好，没有配套的界面，但是度量数据可以输出到Kafka、InfluxDB + Grafana等工具中，方便与企业已有的可视化工具集成，k6的文档也很规范完善，本身是完全开源的，适合与DevOps工具集成。","link":"/2021-01-22-open-source-load-testing-tool-review-2020/"},{"title":"Linux OOM Killer","text":"今天介绍一个跟公众号名字很相关的Linux内存管理机制。 概念在软件故障中，Out-Of-Memory(OOM,系统可用内存不足)是最古老的故障之一，并且一直延续至今。 在早期的计算机系统中，内存小到以kb为单位，那时的程序员要精细的计算每一条指令的内存使用量，犹如在钢丝绳上表演杂技，稍有不慎就会出现内存不足导致软件或操作系统崩溃，但是即使限制那么苛刻，依然产生了许多伟大的软件，这也是这个公众号的名字由来。 即使今天的家用计算机内存已经至少8G起步，操作系统上运行的软件也会遇见OOM错误，Linux为了避免系统内存不足导致整个系统不可用，建立了一套OOM管理机制。 Linux的OOM管理机制会检测可用内存，在内存不足故障发生时选择性的杀死一个或者几个进程以释放内存，而执行这一任务的进程就被称作Linux Out-Of-Memory(OOM) Killer。 为什么要了解OOM Killer那么Linux的这一机制对我们有什么影响呢？ 因为OOM Killer选择杀死哪个进程有不确定性。 在服务器上运行着我们为客户提供服务的进程、监控系统情况的进程、数据库进程等等，通常这些进程的内存占用都相对较大，容易被OOM Killer选中。 如果杀死的是客户服务进程或者数据库进程，轻则服务失败降低用户体验，重则丢失数据引起严重的生产事故。 如果杀死的是监控进程，可能造成服务器异常下线，或者无法及时重启等问题。 所以我们需要了解OOM Killer的运行机制，然后根据生产服务的情况进行合适的配置，以避免关键进程被杀死带来的损失。 OOM Killer的机制Linux的OOM管理机制可以大致分为“检查可用内存-判定OOM状态-选择牺牲者进程-杀死牺牲者”四个步骤。 检查可用内存当程序申请操作系统分配内存时，需要的内存数量会被传递给vm_enough_memory()，除非系统管理员设置了内存过载使用，否则Linux会检查可用内存是否充足。 Linux检查可用内存时，除了当前可以直接使用的free pages内存，还会检查page cache等容易被回收的内存和swap交换区的可用空间。 如果这些内存空间加起来能够满足申请分配的数量，Linux会执行回收并分配内存的动作，不会触发OOM处理。 判定OOM状态当系统内存不足，并且向磁盘交换并回收旧页帧（page frames）也无法释放足够的内存时，Linux会调用 out_of_memory()来决策是否要杀死进程。 因为有可能系统只是极短时间的内存不足，等某个IO操作完成或者内存换页后就缓解了，所以为了避免误杀进程，在真正杀死进程之前，需要根据一些条件判定是否进入OOM状态： 是否有足够的交换空间，如果有，不进入OOM状态 是否距离上一次内存分配失败已经超过5秒，如果是，不进入OOM状态 是否OOM检查一秒内未通过次数大于一次，如果否，不进入OOM状态 是否在最近5秒内至少10次内存分配错误，如果否，不进入OOM状态 是否5秒内已经杀死过一个进程，如果是，不进入OOM状态 当前Linux内核的规则不一定跟上面完全一样，但是我们可以看出Linux会尽力避免频繁的进入OOM状态。 所有这些检查都通过之后，就会进入下一步，选择牺牲者进程。 选择牺牲者进程到了这一阶段，OOM Killer会从一众程序中按照一定规则计算和选取一个进程杀死并释放内存，以保证系统能够继续运行。选择进程时会遵循如下原则： 尽量选择内存占用较多的进程（通常容易命中我们的服务进程） 尽量通过杀死最少的进程来达到目标 尽量不杀死系统和内核运行需要的进程 如果有进程处于SIGKILL或者退出动作中，优先选择以加快内存释放 OOM Killer通过一套尽心设计的算法计算每个进程的oom_score，按照分数高低选择应该杀死哪个进程。 具体进程的oom_score可以通过命令cat /proc/[pid]/oom_score来查看。 在我的ubuntu上，系统进程的oom_score通常是0，chrome中内存占用较大页面进程在300左右。 杀死牺牲者选出牺牲者进程后，OOM Killer会发送``信号杀死牺牲者，即使这个程序本身没有任何问题。 如果内存依然不足，OOM Killer会重复上面的步骤，继续选择并杀死新的进程，直到释放足够的内存位置，颇有为了拯救世界宁愿杀尽天下人的冷血范。 查看OOM Killer的运行情况可以通过dmesg命令查看OOM Killer的日志记录 1sudo dmesg | grep -i “killed process” 在不同的发行版也可以查看以下日志 12345#CentOSgrep -i "out of memory" /var/log/messages#Debian / Ubuntugrep -i "out of memory" /var/log/kern.log 如何控制OOM Killer我们可以通过以下方法避免OOM Killer杀死指定进程。 调整进程的oom_socre 可以向/proc/[pid]/oom_score_adj文件中写入一个负数（例如-1000）来避免进程被选中（oom_adj已经废弃）， 为了使系统重启后调整仍然生效，可以在systemd的service unit中写入如下配置 12[Service]OOMScoreAdjust=-1000 关闭OOM Killer 通过命令sudo -s sysctl -w vm.oom-kill = 0可以关闭OOM Killer. 通过命令echo vm.oom-kill = 0 >>/etc/sysctl.conf写入配置文件可以使重启后也生效. 但是强烈建议不要关闭OOM Killer，可能导致系统出现不可预知的异常 配置overcommit_memory内核参数 12sudo sysctl vm.overcommit_memory=2echo "vm.overcommit_memory=2" >> /etc/sysctl.conf overcommit_memory有三个取值: 0 - 操作系统自行决定进程是否过载使用内存，通常这是默认值 1 - 强制过载使用内存，这样配置会有导致内核进程内存不足的风险，适用于某些内存必须分配成功的科学计算场景 2 - 不允许过载使用内存，意味着系统分配的内存不会超过总内存乘以overcmmit_ratio (/proc/sys/vm/overcommit_ratio，默认50%)，这是最安全的配置。 配置panic_on_oom内核参数 echo 1 > /proc/sys/vm/panic_on_oom 将panic_on_oom内核参数设置为1可以让系统在内存不足时抛出内核错误(kernel panic)，这通常也不是我们希望的。 增加内存😀 可能有点废话，不过如果经常内存不足，物理手段有时比软件优化来得快速有效。 降低软件的内存消耗，修复内存泄漏问题。 大部分场景下，软件系统自身错误的内存使用方式和Bug是内存不足的主要元凶，例如在数据库查询中不限制查询出来的记录数量等等","link":"/2021-01-26-linux-oom-killer/"},{"title":"Ubuntu 20.04 启用休眠(Hibernate)配置过程","text":"最近经常带笔记本回家工作，每次都需要先关闭打开的虚拟机、资料文档和开发环境，回家之后再打开，特别繁琐，所以研究了下Ubuntu 20.04（20.10）如何配置休眠模式。 基础广义来讲，在Linux中支持三种睡眠模式，分别是: Suspend to RAM，即狭义的挂起（Suspend），本文后面提到挂起都是指这种模式。 Suspend to Disk，即我们常说的休眠（Hibernate）。 Suspend to Both，也被称作Hybrid Suspend，是上面两种模式的混合，兼具两种模式的优点（和缺点）。 Ubuntu桌面版默认只有挂起（Suspend）模式，没有启用休眠（Hibernate）模式。 挂起和休眠的目标都是保存冻结系统当前状态，后续需要时“快速”唤醒恢复，但是两者的实现方式是不同的。 挂起时系统的运行数据仍然保存在内存（RAM，通常也叫MEM）中，所以系统还是会以较低的功耗消耗电池电量。这种状态下唤醒系统恢复非常快速，在普及SSD的现在是包括苹果在内很多操作系统的默认选项。 休眠时系统的运行数据被写入磁盘（DISK），系统也会完全切断电源（大部分情况下），唤醒时需要先从硬盘读取数据到内存，因为恢复速度比挂起慢，实测甚至要慢于开机（20s vs 10s）。 休眠的好处就是笔记本实际是关机状态，完全不耗电不发热，不用担心意外断电、进水和误触键盘唤醒系统，可以放心的携带和保存。 Linux底层有两种实现来支持挂起和休眠，一种是内核（kernel）自带的swsusp，另一种是uswsusp(‘Userspace Software Suspend’) ，后者封装了前者，并且提供了更多的功能，通常swsusp已经够用了。 swsusp的原理是向/sys/power目录中的文件写入特定的状态字符串来操作系统的状态。 最重要的是/sys/power/state、/sys/power/mem_sleep、/sys/power/disk三个文件，分别保存了当前系统支持的睡眠模式、挂起方法、休眠方法，具体信息可以参考官方文档 Systemd工具提供了睡眠管理的高级命令systemctl suspend、systemctl hibernate、systemctl hybrid-sleep。 配置 配置/swapfile，启用休眠需要比内存稍大的swap空间，推荐使用swapfile，从2.4内核开始， swapfile的性能已经不弱于swap分区，并且更容易调整大小，如果使用btrfs文件系统，需要内核升级到5.0以上才支持swapfile 12345678910111213# 先关闭已有的swap空间sudo swapoff -a# 分配连续的磁盘空间，fallocate比dd命令更安全快速，空间大小参考后面的表格sudo fallocate -l 20G /swapfile# 修改权限sudo chmod 600 /swapfile# 启用swapfilesudo mkswap /swapfilesudo swapon /swapfile# 确认结果sudo swapon --showfree swap文件的大小可以参考下面的表格 内存 关闭休眠时swap空间大小 启用休眠时swap空间大小 最大swap空间大小 4GB 2GB 6GB 8GB 8GB 3GB 11GB 16GB 12GB 3GB 15GB 24GB 16GB 4GB 20GB 32GB 24GB 5GB 29GB 48GB 32GB 6GB 38GB 64GB 64GB 8GB 72GB 128GB 文件系统启动时挂载/swapfile 1echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab 配置启动内核参数 12345678910111213141516171819# 查看swapfile的UUIDsudo findmnt -no UUID -T /swapfile# 查看swap_file_offset，忽略..符号sudo filefrag -v /swapfile | awk '{ if($1=="0:"){print substr($4, 1, length($4)-2)} }'# 编辑grub文件sudo nano /etc/default/grub# 将grub文件中GRUB_CMDLINE_LINUX_DEFAULT参数修改为如下形式# 其中UUID和resume_offset的值更换为上面两个命令的输出GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=51f8eab4-d775-4020-aace-0e411ef5b8ed resume_offset=34816"# 保存退出，然后更新grub配置sudo update-grub# 编辑initramfssudo nano /etc/initramfs-tools/conf.d/resume# 加入下面一行，UUID替换为实际值resume=UUID=51f8eab4-d775-4020-aace-0e411ef5b8ed# 保存退出，然后更新initramfs配置sudo update-initramfs -u# 重启reboot 重启后执行sudo systemctl hibernate测试是否可以正常休眠。 配置Gnome界面 这时休眠功能已经生效，但是每次都需要输入命令太繁琐，我们需要配置Gnome界面按钮 首先安装Hibernate Status Button插件 然后增加如下配置文件 123456789101112# 新建配置文件sudo nano /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla# 添加以下内容并保存[Re-enable hibernate by default in upower]Identity=unix-user:*Action=org.freedesktop.upower.hibernateResultActive=yes[Re-enable hibernate by default in logind]Identity=unix-user:*Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.handle-hibernate-key;org.freedesktop.login1;org.freedesktop.login1.hibernate-multiple-sessions;org.freedesktop.login1.hibernate-ignore-inhibitResultActive=yes 重启后可以在菜单中看到挂起和休眠按钮了。","link":"/2021-01-28-ubuntu-20-04-hibernate/"},{"title":"Hello World","text":"Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post1hexo new "My New Post" More info: Writing Run server1hexo server More info: Server Generate static files1hexo generate More info: Generating Deploy to remote sites1hexo deploy More info: Deployment","link":"/2016-11-03-hello-world/"}],"tags":[{"name":"Apache Kafka","slug":"apache-kafka","link":"/tags/apache-kafka/"},{"name":"Distributed Streaming Platform","slug":"distributed-streaming-platform","link":"/tags/distributed-streaming-platform/"},{"name":"Java","slug":"java","link":"/tags/java/"},{"name":"UUID","slug":"uuid","link":"/tags/uuid/"},{"name":"Development Effectiveness","slug":"development-effectiveness","link":"/tags/development-effectiveness/"},{"name":"DevOps","slug":"devops","link":"/tags/devops/"},{"name":"Load Testing","slug":"load-testing","link":"/tags/load-testing/"},{"name":"Performance Testing","slug":"performance-testing","link":"/tags/performance-testing/"},{"name":"Open Source","slug":"open-source","link":"/tags/open-source/"},{"name":"Linux","slug":"linux","link":"/tags/linux/"},{"name":"Operating System","slug":"operating-system","link":"/tags/operating-system/"},{"name":"Memory Management","slug":"memory-management","link":"/tags/memory-management/"},{"name":"Ubuntu","slug":"ubuntu","link":"/tags/ubuntu/"}],"categories":[{"name":"ARTS","slug":"arts","link":"/categories/arts/"},{"name":"Review","slug":"arts/review","link":"/categories/arts/review/"},{"name":"Share","slug":"arts/share","link":"/categories/arts/share/"},{"name":"Tip","slug":"arts/tip","link":"/categories/arts/tip/"}]}