顺序预读（prefetch，在Linux中也称为预读，read ahead）是一种用于提升顺序读性能的技术，用于缩小存储设备和应用程序之间巨大的效率差距。Linux内核在通用预读框架中执行顺序文件预读，它主动拦截VFS层中的文件读取请求，并将顺序的请求转换为异步预读请求，为即将到来的请求引入数据块，并在大块中进行。
Redis 的缓存淘汰算法则是通过实现 LFU 算法来避免「缓存污染」而导致缓存命中率下降的问题（Redis 没有预读机制）。
线上某个kafka集群由于种种原因，从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看，排除其他客观因素，置换后，CPU总核数少了一半，使用率上升其实也是预期之内的。事实上置换后，集群CPU使用率确实也由原有的 20%提升至 40%，上升了约 1 倍多。但置换后，cpu sys使用率均值约达到了 12%，较为抢眼，系统相关服务却并无异常，令人有些困惑。
计算机的文件系统是一种存储和组织计算机数据的方法，它使得对其访问和查找变得容易，文件系统使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念，用户使用文件系统来保存数据不必关心数据实际保存在硬盘（或者光盘）的地址为多少的数据块上，只需要记住这个文件的所属目录和文件名。在写入新数据之前，用户不必关心硬盘上的那个块地址没有被使用，硬盘上的存储空间管理（分配和释放）功能由文件系统自动完成，用户只需要记住数据被写入到了哪个文件中。
生产者发送消息有负载均衡。生产者发送消息时，会自动轮询当前所有可发送的broker，一条消息发送成功，下次换另外一个broker发送，以达到消息平均落到所有的broker上。
最近，研究人员发现了一个新型 Golang 恶意软件被用于植入门罗币挖矿程序，并且攻击者可以通过定制修改将挖矿速度提升 15%。
所谓预读，是指文件系统为应用程序一次读出比预期更多的文件内容并缓存在page cache中，这样下一次读请求到来时部分页面直接从page cache读取即可。当然，这个细节对应用程序透明，应用程序可能的感觉就是下次读的速度会更快，当然这是好事。文中我们会通过设置几个情境（顺序读、随机读、多线程交织读）来分析预读的逻辑。
背景 计算机硬件性能在过去十年间的发展普遍遵循摩尔定律，通用计算机的CPU主频早已超过3GHz，内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长迅速，但是在读写性能上并无明显提升，同时SSD硬盘价格高昂，不能在短时间内完全替代传统硬盘。传统磁盘的I/O读写速度成为了计算机系统性能提高的瓶颈，制约了计算机整体性能的发展。 硬盘性能的制约因素是什么？如何根据磁盘I/O特性来进行系统设计？针对这些问题，本文将介绍硬盘的物理结构和性能指标，以及操作系统针对磁盘性能所做的优化，最后讨论下基于磁盘I/O
最近一个项目做了一个模拟u盘的设备，但是在read虚拟u盘的内容时必须每次都从磁盘内读取，而不是从系统的cache中读取，由于这个问题，就查资料看了下read的系统调用，以及文件系统的一些内容。由于文件系统涉及面较广，例如虚拟文件系统（VFS），页缓存，块缓存，数据同步等内容，不可能全部分析到位，这里只记录和read有关的两种使用方式。cached IO和direct IO。 1. 什么是系统调用 首先系统调用能做那些事呢？概括来说，大概有下面这些事需要系统调用来实现。 控制硬件：系统调用往往作为硬件资源和
网上关于BIO和块设备读写流程的文章何止千万，但是能够让你彻底读懂读明白的文章实在难找，可以说是越读越糊涂！
B 树是一种多路自平衡搜索树，它类似普通的二叉树，但是 B 树允许每个节点有更多的子节点。B 树示意图如下：
我们都知道Linux的IO模型有阻塞、非阻塞、SIGIO、多路复用(select，epoll)、AIO（异步I/O）等。
在两台型号相同的机器上(snap1 和snap3)测试磁盘的读取速度，发现两台机器的读取速度差的很大:
磁盘的组成：主要由盘片、机械手臂、磁头、与主轴马达所组成。而数据的写入其实是在盘片上面。盘片上面又可细分出扇区（Sector）与柱面（Cylinder）两种单位，其中扇区每个为512bytes那么大。假设磁盘只有一个盘片，那么盘片如图所示：
大家好，我是 Peter，昨天群里有小伙伴咨询page cache的问题，看到网上有篇不错的文章，分享给大家。如果大家有想看的内容，欢迎给我留言。
如何做系统性能优化 性能优化的目标是什么？不外乎两个： 时间性能：减小系统执行的时间 空间性能：减小系统占用的空间 一、代码优化 做代码优化前，先了解下硬件Cache： （1）Cache Level：通常来说L1、L2的Cache集成在CPU里，L3的Cache放在CPU外； （2）Cache Size：它决定你能把多少东西放到Cache里，有Size就有竞争，就有替换，才有所谓优化的空间； （3）Cache Type：I-Cache（指令），D-Cache（数据），TLB（MMU的Cache）； 代码层次
性能优化的目标是什么？不外乎两个： 时间性能：减小系统执行的时间 空间性能：减小系统占用的空间 一、代码优化 做代码优化前，先了解下硬件Cache： （1）Cache Level：通常来说L1、L2的Cache集成在CPU里，L3的Cache放在CPU外； （2）Cache Size：它决定你能把多少东西放到Cache里，有Size就有竞争，就有替换，才有所谓优化的空间； （3）Cache Type：I-Cache（指令），D-Cache（数据），TLB（MMU的Cache）； 代码层次的优化主要从以下两
InnoDB 存储引擎是以数据页为单位来管理存储空间的。InnoDB 存储引擎在处理客户端的请求时，当需要访问某个数据页的数据时，就会把完整的数据页的数据全部加载到内存中，也就是说即使我们只需要访问一个数据页的一条记录，那也需要先把整个数据页的数据加载到内存中。将整个数据页加载到内存中后就可以进行读写访问了，在进行完读写访问之后并不着急把该数据页对应的内存空间释放掉，而是将其缓存起来，这样将来有请求再次访问该页面时，就可以省去磁盘 IO 的开销了。这个缓存就称之为Buffer Pool。
这一期我们来看一下有哪些办法可以减少linux下的文件碎片。主要是针对磁盘长期满负荷运转的使用场景（例如http代理服务器）；另外有一个小技巧，针对互联网图片服务器，可以将io性能提升数倍。如果为服务器订制一个专用文件系统，可以完全解决文件碎片的问题，将磁盘io的性能发挥至极限。对于我们的代理服务器，相当于把io性能提升到3-5倍。 在现有文件系统下进行优化linux内核和各个文件系统采用了几个优化方案来提升磁盘访问速度。但这些优化方案需要在我们的服务器设计中进行配合才能得到充分发挥。 文件系统缓存lin
廖威雄，就职于珠海全志科技股份有限公司，负责Linux IO全栈研发、性能优化、开源社区开发交流、Linux 内核开源社区pstore/blk,mtdpstore模块的作者(与maintainer交流中)、大客户存储技术支持、全志首个UBI存储方案主导人、全志首个RTOS NFTL主导人。
大概就是，进程写文件（使用缓冲 IO）过程中，写一半的时候，进程发生了崩溃，会丢失数据吗？
There are only two hard things in Computer Science: cache invalidation and naming things.
早上突然就被Meltdown和Spectre这两个芯片漏洞刷屏了，但基本上都是一些新闻报道，对漏洞的分析和利用的信息基本为0。作为安全研究者，不能只浮在表面，还是要深入了解一下漏洞才行，于是开始研究这方面的资料。结果发现其实这个硬件漏洞的影响非常广，不光是Intel， ARM和AMD也受影响，只是AMD的影响比较小罢了。因此基本上所有的操作系统（Windows，macOS，Linux，Android等）都有被攻击的风险。漏洞有两种攻击模式：一种被称为Meltdown，是在用户态攻击内核态，造成内核信息泄露。另一种被称为Spectre，一个应用可以突破自己的沙盒限制，获取其他应用的信息。另外，因为是硬件漏洞，这个攻击对云的影响非常大，利用这个漏洞，一个guest可以获取host或同一台服务器上其他guest的信息，可以说是一个非常严重的漏洞，因此亚马逊和google都在紧急加班修复漏洞。比如google就公布了漏洞修复的进度在：https://support.google.com/faqs/answer/7622138。虽然是硬件漏洞，但是在系统或软件层面上通过牺牲性能的方法还是可以进行修补的。
wait_on_page_locked_killable 在 systrace 上的提示是 IO block, 那到底是怎么阻塞法? 阻塞在谁? 这里是其调用流程图： wait_on_page_loc
最近有很多大侠在交流群里讨论PCI总线，PCI作为高速接口之一，在当下的FPGA产品设计研发中，地位举足轻重，应用广泛，今天给大侠带来PCI Express 系列连载，今天带来第十五篇，预读机制，包括软件预读、硬件预读、PCI总线的预读机制相关内容。希望对各位大侠的学习有参考价值，话不多说，上货。
所谓预读，是指文件系统为应用程序一次读出比预期更多的文件内容并缓存在page cache中，这样下一次读请求到来时部分页面直接从page cache读取即可。当然，这个细节对应用程序透明，应用程序可能的感觉唯一就是下次读的速度会更快，当然这是好事。
MongoDB Manual (Version 4.2）> Administration
从代码中可以看出，只有 MappedFile 的大小等于或大于 CommitLog 的大小并且开启文件预热功能才会预加载文件。 CommitLog 文件的大小默认为 1 G。
大侠好，欢迎来到FPGA技术江湖，江湖偌大，相见即是缘分。大侠可以关注FPGA技术江湖，在“闯荡江湖”、"行侠仗义"栏里获取其他感兴趣的资源，或者一起煮酒言欢。
下载地址：ftp://download2.boulder.ibm.com/ecc/sar/CMA/XSA/ibm_utl_sraidmr_megacli-8.00.48_linux_32-64.zip
每次使用 show engine innodb status 查看mysql状态的时候, 要找的数据每次都找很久, 而且很多参数都忘了是啥意思. 很是浪费时间. 所以整了这么个脚本.
概述 什么是性能？ 性能最通俗的衡量指标就是“时间”，CPU的使用率指的是CPU用于计算的时间占比，磁盘使用率指的是磁盘操作的时间占比，当CPU使用率100%时，意味着有部分请求来不及计算，响应时间
导言：运维工作中除了要维持平台的稳定运行以外，还得对服务器的性能进行优化，让服务器发挥出良好的工作性能是稳定运行的基础。腾讯互娱DBA团队的汪伟（simon）在这一领域里整理出了一套性能优化的资料为大家在性能优化提供充足的方向。
Demos： https://github.com/jiangheyan/JavaScriptBase 一、浏览器 1、“JS解析器”（至少分为两步骤） 1.1 JS预解析（代码正式运行之前的准备工作） “找一些东西并形成一个仓库”：var、function、参数 1.1.1 var a = 1; 找到var a = undefined
最近有项目反应，在服务器CPU使用较高的时候，我们的事件查询页面非常的慢，查询几条记录竟然要4分钟甚至更长，而且在翻第二页的时候也是要这么多的时间，这肯定是不能接受的，也是让现场用SQLServerProfiler把语句抓取了上来。 用ROW_NUMBER()进行分页 我们看看现场抓上来的分页语句： select top 20 a.*,ag.Name as AgentServerName,,d.Name as MgrObjTypeName,l.UserName as userName from event
硬盘的种类主要是SCSI 、IDE 、以及现在流行的SATA等；任何一种硬盘的生产都要一定的标准；随着相应的标准的升级，硬盘生产技术也在升级；比如 SCSI标准已经经历了SCSI-1 、SCSI-2、SCSI-3；其中目前咱们经常在服务器网站看到的 Ultral-160就是基于SCSI-3标准的；IDE 遵循的是ATA标准，而目前流行的SATA，是ATA标准的升级版本；IDE是并口设备，而SATA是串口，SATA的发展目的是替换IDE；
0、使用SSD。资金不足的话，使用RAID设备 【建议使用RAID10，因为RAID5的性能并不太高】
点击上方蓝字每天学习数据库 本文作者：黄稚禹，腾讯云数据库产品经理。曾任职新浪彩票数据库总监，精通金融系统的数据运维体系架构。之前为腾讯视频、腾讯新闻、企鹅号、财经自选股等业务的数据平台总负责人。 ---- 大家都知道很多关于MySQL Server相关的优化技巧,比如:MySQL参数配置优化、MySQL的SQL语句优化、MySQL的schema设计优化。但却对运行MySQL的操作系统和硬件优化有所忽略。本文从Linux操作系统和服务器硬件的角度来说下关于MySQL的优化技巧，如果在MySQL Serve
维持了 20 天的复赛终于告一段落了，国际惯例先说结果，复赛结果不太理想，一度从第 10 名掉到了最后的第 36 名，主要是写入的优化卡了 5 天，一直没有进展，最终排名也是定格在了排行榜的第二页。痛定思痛，这篇文章将自己复赛中学习的知识，成功的优化，未成功的优化都罗列一下。
对于使用InnoDB作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚集索引和非聚集索引），还是各种系统数据，都是以页的形式存放在磁盘上的。而CPU与内存的交互远远快于与磁盘的交互，所以InnoDB存储引擎在处理客户端的请求时，如果需要访问某个页的数据，就会把完整的页中的数据全部加载到内存中。也就是说，即使我们只需要访问一个页的一条记录，也需要先把整个页的数据加载到内存中。
对于一个由对象存储和数据库组合驱动的文件系统，缓存是本地客户端与远端服务之间高效交互的重要纽带。读写的数据可以提前或者异步载入缓存，再由客户端在后台与远端服务交互执行异步上传或预取数据。相比直接与远端服务交互，采用缓存技术可以大大降低存储操作的延时并提高数据吞吐量。
这次天池中间件性能大赛初赛和复赛的成绩都正好是第五名，本次整理了复赛《单机百万消息队列的存储设计》的思路方案分享给大家，实现方案上也是决赛队伍中相对比较特别的。
应用系统分层架构，为了加速数据访问，会把最常访问的数据，放在缓存(cache)里，避免每次都去访问数据库。 操作系统，会有缓冲池(buffer pool)机制，避免每次访问磁盘，以加速数据的访问。 MySQL作为一个存储系统，同样具有缓冲池(buffer pool)机制，以避免每次查询数据都进行磁盘IO。 今天，和大家聊一聊InnoDB的缓冲池。 InnoDB的缓冲池缓存什么？有什么用？ 缓存表数据与索引数据，把磁盘上的数据加载到缓冲池，避免每次访问都进行磁盘IO，起到加速访问的作用。 速度快，那为啥不把
前面讲解了平衡查找树中的2-3树以及其实现红黑树。2-3树种，一个节点最多有2个key，而红黑树则使用染色的方式来标识这两个key。
我们都知道 RocketMQ 和 Kafka 消息都是存在磁盘中的，那为什么消息存磁盘读写还可以这么快？有没有做了什么优化？都是存磁盘它们两者的实现之间有什么区别么？各自有什么优缺点? 今天我们就来一
这篇文章最开始投给我的时候，没有引起太多的重视，但是看了内容之后，真是被里面的细节吸引了。
已经过去的中间件性能挑战赛，和正在进行中的 第一届 PolarDB 数据性能大赛 都涉及到了文件操作，合理地设计架构以及正确地压榨机器的读写性能成了比赛中获取较好成绩的关键。正在参赛的我收到了几位公众号读者朋友的反馈，他们大多表达出了这样的烦恼：“对比赛很感兴趣，但不知道怎么入门”，“能跑出成绩，但相比前排的选手，成绩相差10倍有余”…为了能让更多的读者参与到之后相类似的比赛中来，我简单整理一些文件IO操作的最佳实践，而不涉及整体系统的架构设计，希望通过这篇文章的介绍，让你能够欢快地参与到之后类似的性能挑战赛之中来。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
