标签：性能分析

共 32 篇相关文章

IT 累计浏览 165

「置顶」我做了什么

本文是作者的个人技术项目总览，系统梳理了他长期维护的四大方向工作。在 Android 性能分析与工具链建设上，以 SmartPerfetto 为核心，构建了一套基于 Perfetto 的 AI 辅助分析体系，并配套开发了 Android App Memory Analysis、TraceFix（自动插桩）等专用工具，形成了从 Trace 采集、数据可视化到自动化分析的完整流程。AI 与自动化方向，重点介绍了本地运行的 OpenClaw 系统，它整合了多种模型与工具，用于知识管理、日报生成及工程协作，其公开成果如 AI Field Notes 展现了持续的自动化信息处理能力。此外，作者还开发了数款面向真实需求的 iOS 与 Android 应用，如健康预测 App 100Years。在技术内容输出方面，他通过维护 Android Performance 博客、Android Weekly 周刊及知识星球，沉淀了大量关于系统性能、工具使用及方法论的深度文章与案例，构成了公开的知识体系。整体而言，这些项目贯穿了从底层性能分析、工具开发、AI 实践到应用实现与知识分享的完整技术闭环。

IT 累计浏览 62

Android Perfetto 系列 07 - MainThread 和 RenderThread 解读

本文是Android Perfetto性能分析系列的第七篇，聚焦于主线程（MainThread）与渲染线程（RenderThread）的深入解读。文章旨在帮助开发者利用Perfetto工具，精准分析应用渲染流程，定位卡顿与掉帧问题的根源。核心内容阐述了自Android 5.0引入的双线程渲染架构：主线程负责处理用户输入、执行View的测量、布局与绘制准备（构建DisplayList）；渲染线程则专注于通过GPU异步执行渲染命令，提升帧生成效率。文章详细剖析了一帧的完整生命周期，从等待Vsync信号唤醒，到主线程处理输入与动画、执行核心的Traversal（测量、布局、绘制）三阶段，再到通过syncAndDrawFrame将DisplayList同步给渲染线程，最终由渲染线程完成GPU渲染并提交帧至SurfaceFlinger进行合成显示。通过对Perfetto trace中关键事件（如UI Thread的performTraversals、RenderThread的drawing与queueBuffer）的识别与解读，开发者能够理解帧渲染各环节的耗时分布，从而有效区分性能瓶颈所在，并掌握软件绘制与硬件加速模式下的不同Trace表现。

IT 累计浏览 2,442

不变量及运算优化

这篇讲的是游戏引擎开发中一个看似简单却消耗10%以上CPU时间的性能坑。作者从实际Profiling结果出发，发现每帧重建渲染队列时，需要对每个可渲染物件的包围盒进行世界空间变换运算，而场景中大量静态物件的这类运算是重复的。问题的根源在于输入数据量太大（40个float），直接用作缓存键并不现实。巧妙之处在于，作者利用数学库中矩阵已作为不变量拥有唯一ID这一现有设计，将世界空间矩阵的ID作为缓存键，大幅缩减了比较开销。最终，缓存能按“世界矩阵ID”匹配并直接复用上一帧计算好的所有子模型变换结果，避免了重复计算。这个优化思路透明地解决了问题，而无需对场景或资源系统进行大改。

IT 累计浏览 1,506

JavaScript 代码执行效率对比工具

这篇文章介绍了一个用于对比JavaScript代码执行效率的轻量级工具。作者从小程序和大型工程对性能需求的不同出发，梳理了几种常见的性能测试方案，包括使用在线平台 jsperf.com、利用 `console.time` 计时以及自己编写计时器。为了更直观地对比不同代码片段的性能差异，作者开发了这个名为 Performance 的工具。其核心设计思路是在设定的时间内（默认1000ms）循环执行指定的代码，并基于执行结果计算出一个相对的效率百分比。其中效率最高的代码会被标记为100%，其余代码则显示为相对的性能百分比，从而让性能高低一目了然。文章提供了工具的在线演示页面和 GitHub 仓库地址，方便读者快速上手体验。对于正在编写框架或库、需要精细优化关键代码路径的前端开发者来说，这个工具提供了一种便捷的本地化性能评测与对比方式。

IT 累计浏览 1,530

Akka简单性能分析

这篇讲的是如何把异步任务从应用服务器拆分出去时遇到的问题与选型。作者面临的需求是将异步处理独立部署，最初考虑了MQ配合线程池的传统方案，但发现这种方式在某些场景下仍需依赖共享变量（如HashMap或ThreadLocal），导致客户端阻塞，本质上并未完全摆脱多线程共享状态的并发隐患。于是转向了更现代的Akka框架。文章梳理了Akka的核心特性：高吞吐（单机每秒千万级消息）、低内存占用（1GB内存可承载250万Actor）、弹性自愈与无中心设计。作者没有停留在理论介绍，而是用一个极简的例子——循环发送一千万条消息——做了直观的性能验证。通过VisualVM监控截图可以看出，Akka的调度器（dispatcher）仅凭三个线程就高效完成了海量异步消息的处理，展现了其轻量与高性能的特点。整体来看，作者通过实际场景对比，清晰地指出了传统MQ方案在并发模型上的局限，并用可复现的测试案例证明了Akka在实现高性能异步处理时的优势，为架构选型提供了扎实的参考。

IT 累计浏览 2,590

移动端图片格式调研

这篇技术调研从移动端流量与视觉体验的双重痛点出发，系统梳理了从老牌JPEG、PNG、GIF到新兴WebP、APNG、BPG的多种图片格式。作者不仅对比了它们在压缩率、透明通道、动画支持等方面的核心差异，更深入到Android与iOS底层编解码架构（如Skia、ImageIO）和具体开源库（如libjpeg-turbo、MozJPEG）的性能剖析。文章的亮点在于其扎实的实测数据。通过在iPhone 6上对典型图形与照片素材进行编解码测试，直观呈现了不同格式在文件体积、处理速度上的权衡。例如，JPEG在quality 0.9时达到较好的质量与效率平衡；PNG处理照片类图片时体积和速度明显逊色；而WebP凭借其全能特性和广泛的应用，已成为移动端优化的重要选择。对于关注移动端性能优化的开发者来说，这篇文章提供了清晰的选择指南：WebP是当前均衡且普及的解决方案，APNG在动图上优于GIF，而高压缩比的BPG则代表了未来方向，尽管其仍受版权与计算成本制约。

IT 累计浏览 15,214

如何查找消耗资源较大的SQL

这篇讲的是数据库性能优化中一个非常基础但关键的问题：如何找出那些最“吃”资源的SQL语句。作者没有从理论入手，而是直接从Oracle的V$SQLAREA视图出发，给出了一个可直接使用的查询语句。这条SQL的设计很务实，它不仅找出了总磁盘读取（disk_reads）最多的查询，还计算了每次执行的平均磁盘读取次数（rds_exec_ratio）。通过这个比率，你能快速识别出是那些执行频繁但效率低的语句，还是那些单次执行就消耗巨大的语句。同时，语句关联了执行用户（username）和具体的SQL文本（Statement），让定位和后续优化有了明确目标。对于需要快速诊断数据库性能问题的DBA或开发人员来说，掌握这几个从V$SQLAREA中提取关键信息的查询，就相当于有了一个高效的“探照灯”，能立刻照出系统中最耗资源的瓶颈所在，让优化工作不再是大海捞针。

IT 累计浏览 3,629

使用valgrind的callgrind工具进行多线程性能分析

性能分析常让人头疼，尤其在多线程程序里找出瓶颈更不容易。这篇讲的是如何用开源的Valgrind套件中的Callgrind工具，来完成多线程程序的性能剖析。作者从实际命令出发，演示了从数据采集到图形化分析的完整流程。核心步骤很清晰：先用`valgrind --tool=callgrind`运行目标程序生成分析文件。如果是多线程程序，加上`--separate-threads=yes`参数，就能为每个线程单独生成一份数据，比如`callgrind.out.31113-01`、`-02`等，便于逐个排查。采集到的数据再通过`gprof2dot.py`脚本转换成dot格式，最后用`dot`命令生成PNG调用图。最终得到的图形能直观展示函数的调用关系和耗时分布，让性能热点一目了然。文章没有空谈理论，而是给出了可直接复制的命令和参数，对需要快速定位代码性能问题的开发者来说，是个实用且上手快的方案。

IT 累计浏览 3,979

当cpu飙升时，找出php中可能有问题的代码行

当PHP进程CPU占用率突然飙升至接近100%，如何在解释型语言中精确定位问题代码行？这篇内容深入Zend引擎内部，展示了如何通过调试工具直击PHP运行时状态。文章的核心思路是，利用Zend引擎维护的全局数据结构（`executor_globals`）来获取执行现场。作者聚焦于其中关键的两个变量：`active_op_array`和`current_execute_data`。通过分析其C语言结构体定义，文章指出`active_op_array`中的`filename`和`function_name`记录了当前执行的文件与函数，而`current_execute_data`里的`opline`则指向了正在执行的操作码（opcode），其`lineno`字段直接对应源码行号。实战演示部分极具操作性：编写一个包含死循环的PHP脚本，通过`gdb`附加到进程后，只需几条简单的打印命令，就能立即看到脚本正卡在第四行的`sleep(1)`上。文章还介绍了PHP源码附带的`.gdbinit`文件，其中的`zbacktrace`命令能一键生成完整的调用栈回溯，大大简化了调试流程。这篇内容为PHP性能问题排查提供了一种底层的、引擎级的视角。它告诉我们，即使面对解释型语言，依然可以通过理解其底层实现（如Zend执行器），在应用层优化之外，找到更直接的故障诊断路径。

IT 累计浏览 2,811

redis超时问题分析

这篇讲的是Redis在实际运维中遇到超时问题的深度排查。作者从dump中心cm8集群的真实故障出发，发现内存充足的情况下依然出现超时，进而深入Redis源码寻找根因。问题最终定位在三个方面：一是网络闪断，可通过监控带宽排查；二是内存使用，尤其是RDB持久化时fork子进程会触发Linux的写时复制机制，可能导致物理内存不足而发生swap，引发超时。解决方案包括调低swappiness参数、谨慎使用RDB持久化，或改用AOF及读写分离架构。第三个原因在于Redis单进程串行处理命令的架构。基于epoll的事件驱动模型意味着任何慢命令（如sort、hgetall）都会阻塞后续请求，导致超时。因此，从应用层避免使用慢命令、增加实例分流是关键优化方向。文章结合源码片段，清晰剖析了从网络、内存到内部执行模型的完整故障链路。

IT 累计浏览 1,681

HBase在单Column和多Column情况下批量Put的性能对比分析

这篇讲的是HBase在不同数据模型下批量写入的性能差异。作者从一个实际现象出发：将数据存储在单个列（单列模式）与拆分成多个列（多列模式）时，批量Put的吞吐量存在巨大差距。测试数据显示，单列模式的TPS是多列模式的7倍以上，RPC调用次数也相差9倍。文章核心是从HBase的KeyValue内存模型入手，解释了这种差距的根本原因。在多列模式下，每一列都会携带大约50-60字节的元数据开销（如行键、列族、时间戳等），导致一行数据在客户端缓冲区中占用的内存远大于单列模式，进而触发更频繁的RPC提交，拉低了整体吞吐。作者通过代码计算put.heapSize()和KeyValue对象大小，验证了这一理论估算与测试结果高度吻合。文章最终给出实用建议：如果业务模型必须使用多列存储，在批量写入场景下，可以考虑适当调大客户端的write buffer，以缓解性能下降。

IT 累计浏览 16,309

Linux如何统计进程的CPU利用率

想在脚本里“非阻塞”地获取Linux进程CPU利用率，却遇到top需要等1秒、ps只显示平均值的问题？这篇文章就从这个实际需求出发，直接深入到/proc文件系统，带你看清背后的原理。文章的核心是对比两种思路：使用现成工具vs手动计算。作者明确指出，像top和ps这样的工具，虽然方便，但本质上提供了不同的“快照”——ps给出的是进程生命周期的平均利用率，而top需要至少1秒的采样间隔。关键差异在于，它们都无法满足对“当前时刻”瞬时利用率的精确、非阻塞获取。真正的解决方案隐藏在/proc/stat和/proc/[pid]/stat这两个文件中。文章详细拆解了其中各列的含义，并给出了具体的计算公式：在两个时间点分别读取系统总CPU时间片和进程CPU时间片，通过差值比来计算这段时间内的利用率。这就像用两张“照片”的位移差来算速度，揭示了CPU利用率本质是一个时间段内的统计量，而非一个瞬时值。最后，文章还解释了ps命令中%CPU指标的准确含义，即它是进程自启动以来的累计平均利用率。如果你需要在监控脚本中实现高精度的进程CPU统计，或者对系统工具背后的实现原理感到好奇，这篇文章提供的思路和细节会很有参考价值。

IT 累计浏览 6,663

Linux下CPU的利用率

这篇讲的是如何真正理解Linux系统下CPU时间的构成，从而看懂利用率背后的含义。文章从内核时间基础切入，解释了HZ（时钟中断频率）、tick（中断间隔）和jiffies（中断累计次数）这几个关键概念，为你打下理解的底子。核心部分是将CPU时间拆解得明明白白：它并非一个整体，而是由用户态（User time、Nice time）、内核态（System time、Hardirq time、Softirq time）以及等待（Waiting time）、空闲（Idle time）和虚拟机偷取（Steal time）时间共同组成。文章直接给出了计算公式，让你能一一对应`top`命令输出中那些让人困惑的`%us`、`%sy`、`%id`等百分比，原来它们分别代表了不同时间段的占用情况。作者最后指明，`top`、`iostat`、`vmstat`这些常用工具的数据源头都是`/proc/stat`文件，其中的时间单位就是tick。搞清楚这些组成，当看到系统卡顿时，你才能从高企的`%sy`判断是内核子系统瓶颈，还是从高`%wa`看出是I/O等待拖了后腿，让性能分析有据可依。

IT 累计浏览 11,874

Linux Used内存到底哪里去了？

这篇讲的是Linux运维中一个经典困惑：用`free`命令看到内存已用7-8G，但`ps aux`统计的进程RSS总和却不到30M，多出的内存到底去哪了？作者从同事的实际问题出发，逐步拆解。先解释`free`输出的含义，指出buffer/cache虽被计入used但可回收；然后通过工具如nmon、top分析，发现进程RSS确实占了大头，但还有剩余。进一步揭示内核开销：slab缓存用于对象池，通过`slabinfo`计算消耗了约900MB；页表管理物理页面，从`/proc/meminfo`读取占了58MB；加上struct page等固定消耗。通过编写脚本累加进程RSS、页表和slab，结果与`free`的used基本吻合，但略多171MB，原因是RSS计算中共享库被重复计算。文章最后澄清了内存计算的迷糊账，教会读者如何用`slabinfo`、`/proc/meminfo`等工具自查，理解Linux内存管理的底层细节。对于遇到类似问题的开发者，这是一次清晰的排查示范。

IT 累计浏览 3,399

通过blktrace, debugfs分析磁盘IO

这篇讲的是当磁盘利用率飙到100%、程序变卡时，如何揪出背后的“元凶”文件。作者从实际场景出发，演示了如何组合使用blktrace和debugfs这两个工具，层层追查IO的来源。具体来说，当iostat显示磁盘压力巨大时，先用blktrace捕获块设备层的IO请求。关键点在于grep出以“A”开头的日志行，这里是原始请求的入口，能清晰看到读写操作对应的源设备扇区。接着，通过debugfs的“icheck”命令，根据扇区号换算出的文件系统块号，反查到对应的inode号。最后，用“ncheck”命令把这个inode号映射为具体的文件路径——比如例子中的“test_file”。整个流程就像顺藤摸瓜：从设备层的扇区，到文件系统的块和inode，最终定位到用户可见的文件。拿到这个结果后，就能结合自己的应用程序，分析为什么这个文件会被频繁读写，从而进行优化。文章给出了完整的命令示例和输出解读，实操性很强。

IT 累计浏览 16,536

由浅入深探究mysql索引结构原理、性能分析与优化

这篇文章系统梳理了MySQL索引的核心原理与实战优化。作者从最基础的索引定义（索引相当于书的目录）讲起，深入对比了MyISAM与InnoDB两种主流存储引擎的索引结构差异。核心在于B+树的实现细节：MyISAM的索引与数据文件分离，索引叶子节点存储的是指向数据物理地址的指针；而InnoDB采用聚簇索引，主键索引的叶子节点直接包含了完整的行数据，这意味着其二级索引叶子节点存储的是主键值，需要通过主键进行“回表”查询。这一结构差异直接影响了查询性能和内存使用。文章后半部分聚焦于优化实战，详细拆解了“最左前缀原则”在联合索引中的应用，剖析了ORDER BY与索引配合的五种场景，以及如何通过避免对索引列使用函数、谨慎选择OR/IN等操作来提升查询效率。最后，还涉及了系统配置调优与索引维护的命令。内容覆盖了从存储结构原理到日常优化技巧的全链路，对理解“为什么这么写SQL更快”很有帮助，适合需要夯实数据库基础或进行性能调优的开发者阅读。

IT 累计浏览 2,216

实时计算引擎处理延迟的排查过程

这篇讲的是量子后端团队如何揪出一次实时计算引擎处理延迟故障的故事。问题很明确：实时引擎必须保证处理速度跟上数据流入，比如一分钟生成一个日志文件，就必须在一分钟内处理完毕，否则日志堆积会导致系统无法承载。作者从一次真实的线上故障切入，生动描述了排查过程。团队没有停留在表面的监控指标，而是深入系统调用层，使用了`ltrace`和`strace`这两个利器，去追踪和分析进程的底层库函数调用与系统调用行为。通过剖析这些工具的输出，他们最终定位到了导致延迟的根源。整个排查过程堪称一次扎实的“系统诊断”教学，展示了当性能问题隐藏在复杂调用链中时，如何运用底层工具自顶向下、层层剥茧地定位关键瓶颈。对于需要处理实时流数据的工程师而言，这篇文章提供了一套清晰的排查思路和实用的工具使用范例。

IT 累计浏览 2,387

关于sar的一个问题： Invalid system activity file

这篇讲的是在使用Linux性能分析工具SAR时遇到的一个棘手报错：“Invalid system activity file”。作者从一次服务器故障排查的实战场景出发，详细记录了当SAR无法正常读取历史数据文件时的排查思路。问题表现为系统明明配置了数据采集，但执行`sar -f`命令查看历史负载时，总会提示活动文件无效，导致无法回溯性能数据。作者首先排除了文件路径和权限这类基础配置问题，随后将焦点锁定在了数据文件本身。经过深入分析，发现根因在于系统时间的不正确跳变——一次非预期的NTP时间同步导致系统时间短暂回退，而SAR在记录数据时生成了时间戳异常的文件段，从而引发了后续的校验失败。文章不仅给出了修复已有损坏文件的方法（例如使用`sa1`工具重新转换），更重要的是分享了预防性建议：确保系统时间同步服务稳定，并在关键服务器上为SAR的日志轮转和存储路径做好规划。这些经验对于需要长期监控服务器健康状态的运维人员来说，提供了切实的避坑参考。

IT 累计浏览 2,969

深入浅出Flashcache（五）

这篇是《深入浅出Flashcache》系列的第五篇。作者为了一次版本测试的监控需求，用Perl编写了一个秒级采集的性能监控工具“Flashstat”。故事从最初的设计出发：起初工具通过定期解析`dmsetup status`命令的输出来获取数据，这虽然可行，但解析过程相对繁琐。关键的优化转机出现在作者参与的邮件列表讨论中。Flashcache的原作者Mohan Srinivasan透露，监控所需的关键统计信息已经直接暴露在更易于解析的`/proc/flashcache_stats`文件中。基于这一信息，作者调整了实现方案，使监控程序能直接读取这个proc文件，大幅简化了数据采集逻辑，提升了工具的效率和可靠性。这次实践不仅完成了具体的工具开发，也展示了一个典型的优化路径：从满足功能需求的“能用”方案，到借助社区信息进行重构，走向更清晰高效的“好用”实现。对于正在编写类似运维工具的读者来说，这个关于寻找更好数据源、简化实现细节的思考过程，或许能带来一些直接的启发。

IT 累计浏览 1,959

oprofile抓不到采样数据问题和解决方法

这篇讲的是在新机器上使用oprofile进行性能分析时，可能会遇到采样数据为空的怪问题。作者从读者反馈出发，亲自在具体环境（RHEL 5.4内核2.6.18、华为RH2285服务器）中复现了该现象。文章完整记录了从使用aspersa查看系统配置、重置oprofile、启动分析到最终发现`/var/lib/oprofile/samples/current/`目录为空、opreport报错“No sample file found”的全过程。它清晰地展示了问题现象：所有命令都执行正常，daemon也已启动，但就是抓不到任何采样。对于正被此问题困扰的开发者，文章给出了针对性的排查思路和验证方法，能帮助大家快速定位自己环境中是配置有误还是遇到了相同的兼容性陷阱。