首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    [linux][block]readahead导致的md-raid1读速度慢问题

    前言 为了提高虚拟机的网盘的高科用,同时挂载了两块,在Guest内部使用RAID1,如果后端一块发生故障,可以保证在10s内failover,恢复业务运行。当前的配置是把RAID1的md设备格式化成ext4文件系统,挂载后使用。 atop每天大约生成了200M+的文件,文件在md设备上。发现在查看atop文件的时候,耗时很长,大约估计需要30s。 分析 1,使用filemap分析文件的物理分布 首先怀疑是ext4的文件在物理分布上的情况,有可能是比较零碎,会导致读消耗更高的IOPS。 作者写过一个工具,用来dump出来文件的物理layout情况,代码路径: https://github.com/pacepi/tool/blob/master/filemap.c 编译后执行,

    03

    谈下Linxu系统中虚拟内存的重要性

    我们知道程序代码和数据必须驻留在内存中才能得以运行,然而系统内存数量很有限,往往不能容纳一个完整程序的所有代码和数据,更何况在多任务系统中,可能需要同时打开子处理程序,画图程序,浏览器等很多任务,想让内存驻留所有这些程序显然不太可能。因此首先能想到的就是将程序分割成小份,只让当前系统运行它所有需要的那部分留在内存,其它部分都留在硬盘。当系统处理完当前任务片段后,再从外存中调入下一个待运行的任务片段。的确,老式系统就是这样处理大任务的,而且这个工作是由程序员自行完成。但是随着程序语言越来越高级,程序员对系统体系的依赖程度降低了,很少有程序员能非常清楚的驾驭系统体系,因此放手让程序员负责将程序片段化和按需调入轻则降低效率,重则使得机器崩溃;再一个原因是随着程序越来越丰富,程序的行为几乎无法准确预测,程序员自己都很难判断下一步需要载入哪段程序。因此很难再靠预见性来静态分配固定大小的内存,然后再机械地轮换程序片进入内存执行。系统必须采取一种能按需分配而不需要程序员干预的新技术。

    01

    扫码

    添加站长 进交流群

    领取专属 10元无门槛券

    手把手带您无忧上云

    扫码加入开发者社群

    相关资讯

    热门标签

    活动推荐

      运营活动

      活动名称
      广告关闭
      领券