61 天前 / 博文视点Broadview
以下内容节选自《BPF 之巅：洞悉 Linux 系统和应用性能》一书！ BPF 是近年来 Linux 系统技术领域一个巨大的创新。作为 Linux 内核的一个关键发展节点，其重要程度不亚于虚拟化、容器、SDN 等技术。 BPF 和 eBPF 是什么 BPF 是 Berkeley Packet Filter（伯克利数据包过滤器）的缩写，这项冷门技术诞生于 1992 年，其作用是提升网络包过滤工具的性能。2013 年，Alexei Starovoitov 向 Linux 社区提交了重新实现 BPF 的内核补丁，经过他和 Daniel Borkmann 的共同完善， 相关工作在 2014 年正式并入 Linux 内核主线。
145 天前 / Leo叔叔
点击上方蓝字关注我们 我们日常接触性能诊断问题，一般分为两种情况，一是线上应用真的出现性能问题；二是我们需要对准备上线的系统进行性能预估；后者需要压力测试辅助进行，此处不表。 针对 GO 应用，性能诊断工具主要分为两层：OS 层面和 GO 应用层面 (go tool pprof /trace /gc) OS 诊断 系统诊断，我们一般主要关注三个方面：CPU、Memory、I/O 1.1 CPUCPU 诊断主要关注平均负载（Load Average），CPU 使用率，上下文切换（Context Switch）。常用 top 命令查看 cpu 使用率以及服务器负载情况。
169 天前 / sjf0115
春节前的最后一篇，在这里提前祝大家春节快乐 ClickHouse聚合函数的性能又提升了，相关PR 在此 : https://github.com/ClickHouse/ClickHouse/pull/19946 可以看到，这个 PR 在各种聚合函数中增加了 __restrict 修饰符，最终提升了 1.6 倍的聚合函数性能。 __restrict 是 C 语言中的关键字，它的作用是为编译器带来附加信息。当对指针增加 __restrict修饰之后，表示当前指针在存活期间是独占内存的，不会有其他指针指向这个地址。编译器在知道这个信息之后，就可以做出优化，从而提升性能。
208 天前 / 铭毅天下001
1、上问题这是来自球友实战问题。 大致需求介绍如下： 约 3600 万的数据，其中关键字段如下所示： _idcreatordoc_1『张三，李四，王五，赵六』doc_2『陈胜，吴广，张三』用 cardinality 聚合统计，creator 的个数有约 1300 万。 问题：但在高基数（high cardinality）的情形下，性能不理想。 2、概念解读：什么是高基数？为了更精确解读，这里直接拿：Elastic 官方博客只字不差的翻译。 Theperformanceoftermsaggregationscanbegreatlyimpactedbythecardinalityofthefieldthatisbeingaggregated. Cardinalityreferstotheuniquenessofvaluesstoredinapartic...
228 天前 / rfyiamcool
主机来了后开始配置环境，这也是烦躁的开始。像一些开发者工具的教程多是 x86 的，所以需要找到 m1 的适配教程。像 brew 工具，官方文档中就有标注 m1 的安装文档。 golang release 里没有 m1 的版本，下载 x86 和 arm 版运行提示不可用，arm 版直接报错，x86 golang 二进制文件运行后一直 hang 住，没有任何提示。go 官方博客中说 1.16 的版本会支持 mac m1，但 1.16 的正式版是 2021 年的 2 月份，预计会提前先放出几版 beta 测试版。
294 天前 / sjf0115
导读： Redis 可以轻松支撑 100k+ QPS，离不开基于 Reactor 模型的 I/O Multiplexing，In-memory 操作，以及单线程执行命令避免竞态消耗。尽管性能已经能满足大多数应用场景，但是如何继续在迭代中继续优化，以及在多核时代利用上多线程的优势，也是大家关注的重点。我们知道性能优化在系统资源层面可以从 I/O 以及 CPU 上入手，对于 Redis 而言，其功能不过度依赖 CPU 计算能力，即不是 CPU 密集型的应用，而 In-memory 的操作也绕开了通常会拖慢性能的磁盘 I/O，所以在 Redis 6.0 版本中，作者 Antirez 从网络 I/O 入手，引入 Threaded I/O 辅助读写...
299 天前 / xiispace
阿里妹导读：压测时或多或少都收到过 CPU 或者 Load 高的告警，如果是单机偶发性的，经常会认为是“宿主机抢占导致的”，那事实是否真是如此呢？是什么引起了这些指标的飙高？网络、磁盘还是高并发？有什么工具可以定位？TOP、PS 还是 vmstat？CPU 高 &Load 高和 CPU 低 &Load 高，不同的表征又代表着什么？ 文末福利：免费下载《ECS 运维指南之 Linux 系统诊断》电子书。 一 背景知识 LINUX 进程状态 LINUX 2.6 以后的内核中，进程一般存在 7 种基础状态：D- 不可中断睡眠、R- 可执行、S- 可中断睡眠、T- 暂停态、t- 跟踪态、X- 死亡态、Z- 僵尸态...
319 天前 / 后场技术
如果您紧跟数据库领域的最新发展，则可能对 ClickHouse 已经耳熟能详了，它是专为 OLAP 设计的列式数据库管理系统。ClickHouse 由 Yandex 开发，于 2016 年开源，这使其成为最新的列式数据库管理系统之一，当前被作为开源数据库被广泛应用。 因为 ClickHouse 支持实时，高速报告，所以它是一个功能强大的工具，特别是对于需要即时，快速和灵活的数据分析方式的现代 DevOps 团队而言。 但是，与大多数 DevOps 工具一样，ClickHouse 仅在受到正确管理和监控的情况下才能提供巨大的价值。
353 天前 / java金融
前言随着互联网的高速发展，市面上也出现了越来越多的网站和 app。我们判断一个软件是否好用，用户体验就是一个重要的衡量标准。比如说我们经常用的微信，打开一个页面要十几秒，发个语音要几分钟对方才能收到。相信这样的软件大家肯定是都不愿意用的。软件要做到用户体验好，响应速度快，缓存就是必不可少的一个神器。缓存又分进程内缓存和分布式缓存两种：分布式缓存如 redis、memcached 等，还有本地（进程内）缓存如 ehcache、GuavaCache、Caffeine 等。
409 天前 / 秦夏
这是《漫谈分布式系统》系列的第 16 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 MapReduce 的性能问题 上一篇，我们提到，分布式系统中，经常存在中心化的角色，随着集群规模的扩大，这些中心化的角色会达到性能瓶颈，使得系统不能持续横向扩展下去。 然后，我们通过 Federation 等方法解决了这些中心化的 master 的性能问题。
409 天前 / OPPO互联网技术
我们通过监控发现，线上多台机器周期性出现 IO 100% 忙问题，该案例用常规的 IO 忙排查方法很难解决，最后从文件系统层一直跟到磁盘控制器那部分代码，才确认最终原因。 本文首先简单介绍使用 iostat/iotop/strace 这些工具，如何排查常规的 IO 忙问题。然后结合 ext4 文件系统层、块设备 block 层、磁盘控制器层内核代码，介绍本案例的排查过程，希望看过本文的小伙伴会有新的内核技能增长。 1、前期使用 iostat/iotop/strace 的排查因为 IO 忙的问题会周期性出现，20 多分钟出现一次，CPU 和内存使用都正常，每次 IO 忙持续的时间在 7s 左右...
528 天前 / 楼外青山
一、背景 3D 形象展示项目的图片及模型等资源以压缩包的形式提供，需要下载并解压后再用 Three.js 加载并展示出来，其中的解压缩环节使用的是 GitHub 上获得 5.6k Star 的 JS 开源组件库 JSZip。经过不断的优化，解压缩的性能已经有了较大提升，从几百毫秒降低到一百多甚至几十毫秒。 压缩和解压缩属于 CPU 密集型计算任务，相对于 JavaScript 这样的解释型语言来说，C 作为编译型语言更加适合，于是有了尝试把 C 解压缩程序编译为 WebAssembly 替换 JSZip 解压缩环节的想法，看看性能是否还会有进一步的提升。
532 天前 / 就想叫yoko
友链站内搜索『译』 Go1.14 将内联 defer 提高性能 发表于 2020-02-08 | 分类于 Go tips&tricks| 热度：| 字数统计： 811 紧接前一篇《Go1.14 为 time.Timer 定时器带来巨幅性能提升》，本文介绍 Go1.14 针对 defer 做的优化。 在 Go1.14 之前，Go 中的每一个 defer 函数，会在编译期在 defer 位置生成一个 runtime.deferproc 调用，并且在包含 defer 的函数退出时生成一个 runtime.deferreturn 调用。 如下代码： 1234560: func run() {1: defer foo()2: defer bar()3:4: fmt.Println("hello")5: }编译器会生成类似如下的代码： 123456runtime.d...
543 天前 / 编程一生
背景 讲一个发生在 15 年自己身上的例子。 当时负责开发维护整个公司的所有搜索引擎。两年时间内大体同样的方法已经搭建过好几套了。所以被要求再搭建一套的时候本以为不会出现什么问题。结果搭建好运行一段时间请求会超时。 登陆服务器观察到了”too many open files( 文件句柄耗尽)“错误。用 linux 命令可看到：用户可以打开文件的最大数目为 65535(linux 命令为 ulimit -a)，已经到极限了。最后观察了系统的内存已经快耗尽了（因为一台机器上同时运行了多个服务）。换了一台内存充足的机器解决了问题。