IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:性能优化

共 213 篇相关文章

IT 累计浏览 2,620

聊聊多线程程序的load balance

这篇讲的是,如何在一个常见的“接收者-工作线程池”模型中,主动优化负载均衡以提升性能。作者从一个大家熟悉的设计出发:一个 receiver 线程接收请求,放入队列,通过条件变量唤醒任意一个 worker 处理。他敏锐地指出,完全依赖内核的调度和负载均衡可能带来问题。 核心问题有两个:如果 worker 线程远多于 CPU 核心数,唤醒时几乎无法均匀分配到不同 CPU,导致某些核过载而某些核空闲,形成“伪并发”。其次,即使 worker 数量合理,内核的负载均衡也未必能确保将任务分配到不同的物理核心(避免争抢共享缓存和计算资源)。 对此,作者提出了应用层的“微调”方案。一方面,将 worker 线程数控制在接近或略小于 CPU 核心数。另一方面,更关键的是,通过线程绑定(affinity)固定 worker 在特定 CPU 上,并设计一个分级的条件变量唤醒机制。这能确保新任务被优先分配给空闲或低负载物理核心上的 worker,从而主动实现更优的负载分布。 文章通过精心设计的实验验证了结论。例如,将 worker 线程数从 240 降至 24 后,CPU 利用率从 2200% 提升至接近 2400%。启用绑定线程和分级唤醒后,处理 12 个并发任务时性能得到进一步提升。作者也发现,对于依赖内存缓存的任务(如 mmap 读文件),让 worker 集中在相邻 CPU 上反而可能提升性能,这体现了负载均衡策略需具体场景具体分析。 作者通过细致的对比实验表明,这些在应用层主动进行的微调,有时能取得比等待内核调度更优的效果。

IT 累计浏览 13,013

Linux 性能监控、测试、优化工具

系统性能专家 Brendan Gregg 在 LinuxCon NA 2014 大会上更新了他的经典演讲。这篇文章梳理了他演讲中关于 Linux 性能工具的核心图谱,最大的变化是新增了测试与优化两大部分,形成了一个完整的工具体系。 作者将复杂的性能问题拆解为三个清晰的场景:日常监控、基准测试与主动调优。针对每个场景,都提供了对应的工具图谱。例如,监控部分聚焦于观察系统运行状态,使用 perf、bpftrace 等工具追踪内核与用户层活动;测试部分则关注量化系统能力,展示了 fio、sysbench 等用于磁盘、网络和数据库的基准工具;优化部分提供了性能调优的视角,介绍了 perf stat、turbostat 等用于分析瓶颈并指导调整的工具。 整篇文章没有泛泛而谈,而是通过三张详尽的工具关系图,直观地展示了如何在不同阶段选择合适的工具。它帮助读者快速建立起 Linux 性能分析的全局观,知道在什么问题下该去哪里找对应的“武器”。

IT 累计浏览 4,198

构建C1000K的服务器(1) – 基础

当C10K问题已成为历史,作者将目光投向了更宏大的C1000K挑战。对于Twitter、微博这类需要维持千万级实时连接的平台,单机百万连接(C1000K)的能力能极大降低服务器集群规模。 这篇文章并没有直接给出某个框架或库的解决方案,而是从根源出发,剖析了限制C1000K实现的四大核心因素。作者以Linux为例,深入讲解了如何突破操作系统默认的“最大打开文件数”限制,给出了包括临时修改(ulimit)和永久配置(sysctl.conf, limits.conf)在内的具体方法与命令。文章还通过一个原始的C语言服务器程序,实际测量并验证了操作系统为维护百万连接所消耗的内存,将理论估算与实际开销结合起来分析。 作者强调,解决C1000K问题不能盲目追求新技术,而应先理清操作系统内核、内存分配与网络吞吐这些底层瓶颈。文中的系统参数配置和测试思路,为需要应对海量并发连接的开发者提供了切实可行的排查起点和优化依据。

IT 累计浏览 2,204

Pora2应用中HBase高并发读写性能优化

这篇讲的是淘宝搜索的Pora2实时分析系统在大量使用HBase进行高并发读写时,所遇到的一系列性能“坑”及优化实践。系统上线后出现处理延迟、集群压力大的问题,排查发现根源主要在于HBase的使用方式。 文章拆解了几个典型案例:一是HBase默认的Periodic Flusher机制引发了过于频繁的flush与compact,通过调整其超时阈值得到了缓解;二是下游消费消息队列时未控制Scan频率,对Region Server造成了无谓压力;三是在超大并发下,过多的客户端连接耗尽了服务端Handler,作者的解决方案是减少进程数、增加线程数以复用连接。 此外,还涉及了因rowkey生成代码bug导致的数据访问热点,以及Bulk Load数据未做Major Compaction引起的读取性能衰减。文章最后总结道,高并发场景下必须合理使用HBase,避免不当操作形成“越慢越压、越压越慢”的恶性循环。这些从实战中沉淀的细节,对同类系统的设计与调优很有参考价值。

IT 累计浏览 4,474

再叙TIME_WAIT

这篇文章从一次“被反复问到”的经历出发,全面梳理了 TCP 协议中的 TIME_WAIT 状态。作者首先用几条简单的 Linux 命令,带我们直观感受繁忙服务器上动辄数万的 TIME_WAIT 连接。文章的核心在于解释了这种状态存在的“必要性”:它通过等待两倍的报文最大生存时间(MSL),确保双向关闭握手的数据包不会在不可靠的网络上引发混乱或干扰新连接。 接着,文章深入对比了控制 TIME_WAIT 数量的几种主流内核参数调优方案。其中,`ip_conntrack` 虽能调整超时,但作者指出它带来的性能下降可能得不偿失。而广为流传的 `tcp_tw_recycle` 参数则隐藏着一个在 NAT 环境下可能导致连接失败的“时间戳陷阱”。相比之下,`tcp_tw_reuse` 被认为相对安全,但其关键限制在于仅对连接发起方(如作为客户端的 PHP)有效,且依赖时间戳递增机制。 整体来看,这篇文章不是在简单罗列解决方案,而是深入剖析了问题的成因与各种方案的权衡。它提醒我们,那些试图强行缩短 TIME_WAIT 的“快捷方式”往往伴随风险,而理解其设计原理,才能为一次连接的优雅退场赋予合理的等待时间。

IT 累计浏览 2,129

window resize和scroll事件的基本优化

这篇讲的是前端开发中一个常见的性能陷阱。文章从同事在项目中实际遇到的“翻车”现场切入:在低版本IE里,频繁触发的`resize`和`scroll`事件会导致页面卡死。问题的根源在于这两个事件触发频率极高,每次都同步执行复杂计算或DOM操作,会瞬间耗尽浏览器的性能资源。 作者的核心优化思路是“节流”:通过一个定时器,确保在设定的时间窗口(如400毫秒)内,无论事件被触发多少次,实际的处理函数只执行一次。代码示例清晰展示了如何用`setTimeout`和`clearTimeout`来实现这个简单的“节流阀”,这个方案对`resize`和`scroll`事件同样有效。 对于需要监听这些高频事件的场景,尤其是需要兼容老版本IE的项目,这个低成本、高收益的基础优化方法能有效避免页面假死,值得借鉴。

IT 累计浏览 3,803

修改Linux网卡连接速度

这篇讲的是作者如何发现并解决内网Linux服务器上传速度异常缓慢的问题。服务器文件传输速度只有1MB/s,作者怀疑是网卡工作模式所致。通过 `ethtool eth0` 命令检查,果然发现网卡速度被锁定在了10Mb/s的低速模式,即使它支持100Mb/s。 针对这个问题,作者使用了 `ethtool -s eth0 speed 100 duplex full` 命令,将网卡强制设定为100Mb/s全双工模式。调整后再次检查,网卡已成功切换到新的工作状态。最终实测文件传输速度达到了10MB/s,性能恢复正常。 这篇文章简洁清晰地展示了一个常见的网络性能问题排查过程:从现象(速度慢)到诊断(查网卡模式),再到解决(调整速率参数),并验证了效果。对于运维人员或遇到类似网络瓶颈的开发者,这个用 `ethtool` 手动调整链路参数的方法,是一个直接有效的参考方案。

IT 累计浏览 1,625

如何解决WordPress因加载Google链接变慢的问题

这篇讲的是WordPress网站莫名变卡的一个经典坑:因为默认调用Google Fonts和jQuery,导致国内访问加载缓慢。作者从“众所周知的原因”出发,详细拆解了各种应对方案。 常见的做法是安装插件(如Disable Google Fonts)或在functions.php中添加代码来禁用或替换Open Sans字体。但作者实测后认为这些方法治标不治本。更彻底的解决方案是深入系统核心:编辑`wp-includes/script-loader.php`文件,将其中引用的`ajax.googleapis.com`等Google域名批量替换为国内可用的镜像地址(如`ajax.useso.com`)。同时,也需要修改主题目录下`functions.php`中字体加载的URL。 文章的价值在于给出了超越常规插件思路的“手术刀”式修改方案,直接针对资源加载源头进行替换,能更根本地解决加载卡顿问题。

IT 累计浏览 5,587

近距离端详Android ART运行时库

这篇技术分析聚焦于Android平台从Dalvik虚拟机向ART运行时过渡的核心变革。文章从Google I/O大会的发布背景切入,指出传统Dalvik虚拟机在应对多核处理器、大内存等新硬件趋势时已显吃力,从而引出ART的诞生。 文章的核心,是将ART与Dalvik进行多维度对比。最关键的差异在于编译策略:ART采用预编译技术,在应用安装时一次性将字节码编译为本地机器码并存储,而Dalvik依赖于每次运行时的即时编译。这一改变带来了直接好处,例如性能测试显示代码执行效率可提升2到3倍,同时因减少了运行时编译开销而有助于延长设备续航。 另一个对比重点是垃圾回收机制。文章通过详实的日志对比了二者的表现:Dalvik的垃圾回收常导致数十甚至上百毫秒的停顿,引发明显的画面卡顿;而ART经过重新设计的垃圾收集器,能将这类停顿时间压缩到微秒级,卡顿现象得到极大改善。 文章也客观指出了ART的权衡之处,即首次安装或设备启动时的编译时间会变长,但这是用一次性的存储和时间成本,换取了应用运行期的长期性能收益。总体而言,这是一次为匹配现代硬件能力而进行的底层架构升级。

IT 累计浏览 6,637

使用CSS3开启GPU硬件加速提升网站动画渲染性能

这篇讲的是作者在打造个人网站时,为首页的鼠标跟随动画遇到的性能坑,尤其是Chrome浏览器下的卡顿问题。 作者使用了多张大尺寸半透明PNG图片来制作空间透视效果,动画本身逻辑不复杂,但在Chrome中帧率只有30fps左右,渲染非常吃力。通过Chrome DevTools分析,发现主要瓶颈是浏览器在“painting”(绘制)阶段耗时过长。根源在于Chrome对大量大尺寸PNG图片的渲染存在长期未完美修复的性能缺陷。 尝试了requestAnimationFrame等多种前端优化手段均无效后,作者找到了一个巧妙的“小hack”:为动画元素添加CSS3属性 `-webkit-transform: translate3d(0,0,0)`。这个本用于3D变换的声明,在设置为0后并未开启3D效果,却意外激活了GPU硬件加速,将渲染工作从CPU转移至GPU。 效果立竿见影,开启后动画帧率瞬间提升至55fps以上,变得极为流畅。文章最后也提供了适用于所有浏览器的通用写法。这个案例说明,有时解决性能问题的关键,可能在于理解浏览器底层的渲染机制,并善用看似无关的特性来“曲线救国”。

IT 累计浏览 4,477

Jetty线程“互锁”导致数据传输性能降低问题分析

这篇讲的是在Jetty 7.2.1这个特定版本中,一个会导致数据传输性能降低的“互锁”问题。作者从Jetty经典的NIO异步反映器模型入手,分析了主线程(selector)与子线程(工作线程)之间的一种微妙配合失误。 问题的核心在于,当子线程遭遇网络拥塞、缓冲区写满时,它会进入阻塞状态并向主线程注册一个内部事件,等待拥塞解除的通知。然而,主线程的select循环在等待selector的网络事件时,可能并未及时轮询和处理这些内部事件,导致子线程无法被唤醒,形成“互锁”,拖累了整体性能。 文章通过拆解具体的代码逻辑,清晰地展示了这种线程间交互的瓶颈点。最终,作者指出了相应的解决或规避思路,比如合理设置超时参数,以帮助开发者在类似场景下优化配置,避免性能陷阱。

IT 累计浏览 3,720

关于Rsyslogd 的一些配置 (高性能、高可用 rsyslogd)

这篇讲的是作者公司日志传输服务器因带宽调整引发的日志堵塞实战。他们遇到的情况是,业务通过PHP syslog接口写日志时被“卡住”了,根源在于rsyslog默认配置追求“不丢任何数据”,但当传输链路异常时,队列堆积反而拖垮了业务。 排查发现,原有配置仅有基础传输逻辑,进程、队列、传输效率等关键参数全部使用了默认值。这种配置在理想环境下能运行,一旦出现网络波动或突发流量就暴露出问题。文章分享了如何通过调整队列参数来破解困境:例如定义`$MainMsgQueueFilename`和`$MainMsgQueueMaxDiskSpace`来控制磁盘队列大小,利用`$QueueHighWatermark`触发磁盘存储,并通过`$MainMsgQueueDiscardMark`与`$MainMsgQueueQueueDiscardSeverity`配合实现有策略的消息丢弃,避免业务被阻塞。 作者还附上了关键配置的截图和几份深入阅读的官方文档,特别是关于rsyslog队列机制的那篇。此外,文末也提及了RELP(可靠事件日志协议)等更健壮的传输方案,以及社区开发的syslog-safer工具作为补充。这是一次从故障现象到配置调优的完整经验梳理,对于使用rsyslog的日志架构很有参考价值。

IT 累计浏览 5,023

遭遇php的in_array低性能

这篇讲的是 PHP 中 `in_array` 函数的一个性能陷阱。作者从一次真实的接口优化经历出发,发现将重复的缓存读取移出循环后,接口响应时间虽从 5 秒降至 2 秒,但仍未达到预期。通过编写测试代码重现,问题被定位到 `in_array` 函数本身。 性能杀手在于 `in_array` 默认的“松散比较”模式。当数组元素和待查找值均为“字符串型的数字”时,PHP 引擎会尝试将它们转换为长整型再进行比较。这个过程中频繁调用 `strtol` 系列库函数,消耗了大量时间,导致仅 3000 次循环就耗时超过 1 秒。 解决办法很简单:为 `in_array` 添加第三个参数 `true`,启用严格比较模式,同时比较值与类型。这避免了 PHP 内部不必要的类型转换,性能因此提升数倍,测试用例的执行时间从 1.132 秒骤降至 0.267 秒。文章通过 `strace` 和 `ltrace` 工具深入剖析了问题根源,对于处理大量数据的 PHP 开发者而言,这是一个值得警惕的细节。

IT 累计浏览 2,177

闲扯Nginx的accept_mutex配置

这篇闲扯文章深入探讨了Nginx中一个常被忽略却影响吞吐量的配置——accept_mutex。文章从它的基本作用说起:启用时,新连接到达只会唤醒一个worker来处理,从而避免“惊群问题”;禁用时则所有worker都会被唤醒,虽可能导致性能损耗,但Nginx作者Igor Sysoev指出,由于Nginx的worker进程通常较少(几十个),惊群影响其实有限。 文中对比了启用与禁用accept_mutex的场景:启用更像“主动喂小鸡”,在资源稀缺时(如连接数少)高效且稳定;禁用则像“撒粮让鸡抢”,当访问量大时能提升整体吞吐量,尽管可能增加上下文切换(可通过sar -w观察)。作者引用Igor Sysoev的解释,强调这与Apache(动辄上百进程)不同,Nginx因进程少而更灵活。 基于这些分析,文章最终建议:对于高流量网站,关闭accept_mutex是值得考虑的优化选择,以平衡惊群风险与系统性能。整体从具体配置出发,用生动比喻和权威引用,提供了清晰的实践指导。

IT 累计浏览 2,647

ext4+delalloc造成单次写延迟增加的分析

这篇讲的是淘宝内核组在将线上系统升级到Ext4文件系统后,发现应用写操作延迟异常增大的故障。根源在于Ext4的新特性“延迟分配”(delalloc)。 简单来说,delalloc为了优化后续的顺序访问性能,将原本每次写操作都会进行的磁盘块分配过程,推迟到了系统批量回写数据时才进行。这导致了一个关键的锁竞争问题:回写进程在批量分配磁盘块时需要持有排他写锁(i_data_sem),这个过程可能耗时较长(例如约30秒一次)。如果此时有应用程序发起新的写操作,它就必须等待这把锁释放,从而导致单次写操作的延迟被显著拉高。 作者通过fio工具进行了量化测试:开启delalloc后,虽然写操作的平均延迟更低(5.86微秒 vs 7.00微秒),但最大延迟却飙升到了193毫秒,是关闭时(16毫秒)的10倍以上。这清晰地说明了delalloc“集中处理”带来的长尾延迟问题。 对于使用Buffer IO进行追加写、不主动刷新数据且对延迟敏感的应用,这个问题会尤为突出。文章给出的解决方法是在挂载时加上`nodelloc`参数来关闭此特性。

IT 累计浏览 6,928

程序员最怕的事

这篇文章汇总了程序员社区里流传最广的五大恐惧,数据源自 Stack Overflow、Quora 等平台上相关帖子的投票结果。它并非严肃的技术探讨,而是一次有趣的技术人“心理体检”。 排名从低到高,恐惧依次是:与不称职的上级或同事共事;被迫学习或使用自己讨厌的技术(比如有人“怕用 COBOL”);不再热爱编程这份工作;失业风险(包括被外包、技术平台封闭甚至身体伤病);而高居榜首、最普遍的恐惧是“做砸事情”——具体表现为害怕代码里的 Bug。从“周五晚上发现无法编译”到“担心 Bug 造成经济损失或物理伤害”,这种对交付质量的敬畏与焦虑,几乎伴随每一位开发者的日常。 这篇文章的价值在于,它揭示了技术光环之下程序员真实的情感与压力。它可能让你会心一笑,找到共鸣;也可能提醒团队管理者,除了技术能力,程序员更需要一个健康的协作环境和工作热情。你的恐惧上榜了吗?

IT 累计浏览 6,863

Linux探索:一次删除一百万个文件的最快方法

这篇讲的是如何在Linux系统下极高效地删除海量文件。作者从一个Quora上的讨论出发,对几种常见的批量删除方案进行了系统性的速度对比。 文章的核心发现令人意外:通常用于数据同步的`rsync`命令,在删除任务中表现极其出色。作者通过两次测评(第二次使用了新硬件和更精确的计时工具)发现,使用`rsync --delete`将一个空目录与目标目录同步,可以在10秒内删除100万个文件。相比之下,传统的`find -delete`、`find | xargs rm`以及直接使用`rm -rf`,耗时都在28秒到41秒之间,性能差距明显。 这种高效的背后,是`rsync`直接操作文件系统索引的高效机制,避免了为每个文件单独发起系统调用的巨大开销。文章不仅给出了具体命令(`rsync -a --delete empty/ target/`),还指出该方法的灵活性——配合`--exclude`参数可以实现选择性删除,并且在删除后保留了原目录结构,方便复用。 对于运维人员或需要处理临时文件、缓存文件的开发者来说,这是一个非常实用的技巧,能显著节省处理时间。

IT 累计浏览 3,533

Javascript 装载和执行

这篇讲的是浏览器如何处理JavaScript文件的装载和执行问题。作者从JavaScript两大特性——“载入后立即执行”且“执行时阻塞页面”——出发,通过一系列具体示例,对比了多种解决方案的差异与适用场景。 传统将script标签放在head中会导致页面渲染被完全阻塞。即便使用document.write动态插入,对整个页面来说仍然是同步阻塞的。HTML5的async属性虽允许并行下载,但脚本执行时机不可控;而IE的defer属性能延迟执行且不阻塞DOM渲染,不过浏览器兼容性有限。 作者重点推荐了“动态创建DOM元素”的方式,这已成为异步加载的常用模式。进一步地,为了解决“何时执行”的问题,可以将脚本加载绑定到window.onload或特定交互事件上。文章还探讨了预加载脚本但不立即执行的进阶需求,介绍了利用object或iframe标签进行缓存的变通方法。 最终,作者通过对比演示,清晰地展现了每种方案在执行顺序、阻塞行为和浏览器支持上的权衡,为开发者在实际项目中选择合适的脚本加载策略提供了实用参考。

IT 累计浏览 5,026

http keepalive

这篇讲的是HTTP KeepAlive机制的工作原理与正确配置。作者从早期每个HTTP请求都需要单独建立TCP连接的性能瓶颈出发,解释了KeepAlive如何允许在一个TCP连接上持续传输多份数据,从而显著减少连接建立开销、降低服务器内核调用与TIME_WAIT状态连接数。 不过,文章也明确指出KeepAlive并非“免费午餐”,配置不当的长连接反而会导致系统资源被无效占用,其损失可能超过重复建立连接。因此,正确设置`keepalive_timeout`参数至关重要。 作者通过编写脚本与`tcpdump`抓包,细致地分析了三种场景:关闭KeepAlive、开启KeepAlive(超时300秒)、以及在同一连接上发送多个请求(超时180秒)。测试清晰地揭示了TCP连接从建立、数据传输到最终释放的完整生命周期。一个关键发现是,`keepalive_timeout`的计时器是在最后一个HTTP响应发送完毕后才开始启动,并在每次收到新请求后重置。这意味着合理的超时设置需要在复用连接提升性能与避免资源长期占用之间取得平衡。

IT 累计浏览 5,603

Oracle DBA的学习进阶成长树-从初出茅庐到高瞻远瞩

这篇文章探讨的是 Oracle DBA 这条技术路径上的长期成长规划。作者根据自己多年的经验,将 DBA 从新手到专家的历程,清晰地划分为五个进阶阶段,并指出这大约需要十年的持续积累。 文章的核心观点是,在任何一个技术领域,扎实的阶段性积累远比频繁跳槽更为重要。作者特别强调,对于一位有十年经验的 DBA,面试官最看重的是他是否曾在某个阶段,全心钻研过底层技术。如果没有这样深入的“磨练”,职业高度便会受限。这个视角点明了技术精进的关键。 文中还引用了一位网友的精彩比喻,用“少年听雨”到“灯火阑珊”的五句宋词,来映射 DBA 从青涩到豁达的五重境界,为硬核的技术成长增添了一份人文的注解。 如果你正在数据库管理的职业道路上探索,这篇文章提供的阶段模型和心态建议,或许能帮助你更好地校准自己的方向。