fsync

linux内存分析 | 从内核文件系统看文件读写过程

生来就可爱ヽ(ⅴ<●) 提交于 2020-10-24 08:54:44
转自 http://www.cnblogs.com/huxiao-tee/p/4657851.html 1 系统调用 操作系统的主要功能是为管理硬件资源和为应用程序开发人员提供良好的环境,但是计算机系统的各种硬件资源是有限的,因此为了保证每一个进程都能安全的执行。处理器设有两种模式:“用户模式”与“内核模式”。一些容易发生安全问题的操作都被限制在只有内核模式下才可以执行,例如I/O操作,修改基址寄存器内容等。而连接用户模式和内核模式的接口称之为系统调用。 应用程序代码运行在用户模式下,当应用程序需要实现内核模式下的指令时,先向操作系统发送调用请求。操作系统收到请求后,执行系统调用接口,使处理器进入内核模式。当处理器处理完系统调用操作后,操作系统会让处理器返回用户模式,继续执行用户代码。 (点睛之笔) 进程的虚拟地址空间可分为两部分,内核空间和用户空间。内核空间中存放的是内核代码和数据,而进程的用户空间中存放的是用户程序的代码和数据。 不管是内核空间还是用户空间,它们都处于虚拟空间中,都是对物理地址的映射。 应用程序中实现对文件的操作过程就是典型的系统调用过程。 2 虚拟文件系统 一个操作系统可以支持多种底层不同的文件系统(比如NTFS, FAT, ext3, ext4),为了给内核和用户进程提供统一的文件系统视图,Linux在用户进程和底层文件系统之间加入了一个抽象层

mysql中redo log记录方式

|▌冷眼眸甩不掉的悲伤 提交于 2020-10-17 03:03:46
redo log的大小是固定的,在mysql中可以通过修改配置参数innodb_log_files_in_group和innodb_log_file_size配置日志文件数量和每个日志文件大小,redo log采用循环写的方式记录,当写到结尾时,会回到开头循环写日志。redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。 二进制日志相关内容,参考: MariaDB/MySQL的二进制日志 。 redo log不是二进制日志。虽然二进制日志中也记录了innodb表的很多操作, 也能实现重做的功能, 但是它们之间有很大区别。 二进制日志是在 存储引擎的上层 产生的,不管是什么存储引擎,对数据库进行了修改都会产生二进制日志。而redo log是innodb层产生的,只记录该存储引擎中表的修改。 并且二进制日志先于 redo log 被记录 。具体的见后文group commit小结。 二进制日志记录操作的方法是逻辑性的语句。即便它是基于行格式的记录方式,其本质也还是逻辑的SQL设置,如该行记录的每列的值是多少。而redo log是在物理格式上的日志,它记录的是数据库中每个页的修改。 二进制日志只在每次事务提交的时候一次性写入缓存中的日志"文件"(对于非事务表的操作

Linux环境编程2(持续更新中)

。_饼干妹妹 提交于 2020-09-30 12:03:12
文件同步: 1、在写入数据时内存与磁盘之间也有一个缓冲区,这种机制降低了磁盘读写次数,提高了读写的效率。 2、但这种机制带来的后果就是磁盘中的数据与实写入的数据不匹配,系统提供了一个函数可以让缓冲区中的数据立即写入到磁盘。 void sync(void); 功能:把缓冲区中的数据同步到磁盘 注意:并不等到数据同步完成后才返回,而是把缓冲区的数据加入到写入队列。 int fsync(int fd); 功能:把指定文件的内容从缓冲区同步到磁盘 注意:会等到完全定稿磁盘才返回 int fdatasync(int fd); 功能:把指定文件的内容从缓冲区同步到磁盘,只同步文件的内容不同步属性。 文件属性: int stat(const char *path, struct stat *buf); 功能:根据文件的路径获取文件的属性 buf:存储文件属性的结构休指针,是个输出型参数。 int fstat(int fd, struct stat *buf); 功能:根据文件描述符获取文件的属性 int lstat(const char *path, struct stat *buf); 功能:获取软链接文件的文件属性。 struct stat { dev_t st_dev; // 设备ID ino_t st_ino; // i节点号 mode_t st_mode; // 文件的类型和权限

【死磕 Redis】—– info 命令详解

寵の児 提交于 2020-09-26 12:18:22
原文出处: Java 技术驿站 『 chenssy 』 Redis 提供了一个非常有用的查看状态信息的命令:info。它以一种易于理解和阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。使用方法有如下三种: info:部分Redis系统状态统计信息。 info all:全部Redis系统状态统计信息。 info section:某一块的系统状态统计信息,其中section可以忽略大小写。 详细内容如下表格: 参数名 说明 server 获取 server 信息 clients 获取 clients 信息,如客户端连接数等 memory 获取 server 的内存信息,包括当前内存消耗、内存使用峰值 persistence 获取 server 的持久化配置信息 stats 获取 server 的一些基本统计信息,如处理过的连接数量等 replication 获取 server 的主从配置信息 cpu 获取 server 的 CPU 使用信息 keyspace 获取 server 中各个 DB 的 key 的数量 cluster 获取集群节点信息,仅在开启集群后可见 commandstas 获取每种命令的统计信息 其中 memory,stats,clients,keyspace 是 Redis 运行时经常要关注的信息。 server 获取 server 信息,包括

【k8s】etcd集群took too long to execute慢日志告警问题分析

做~自己de王妃 提交于 2020-08-17 09:52:37
背景 目前 机器学习平台 后端采用k8s架构进行GPU和CPU资源的调度和容器编排。总所周知,k8s的后端核心存储使用etcd进行metadata持久化存储。机器学习平台采取[External etcd topology]( http://way.xiaojukeji.com/article/External etcd topology)结构进行etcd的HA部署。 etcd集群的稳定性直接关系到k8s集群和 机器学习平台 的稳定性。odin平台直接接入etcd集群的慢日志(etcd请求操作>100ms)告警,实时监控etcd的稳定性。 问题记录 2020-01-06 运维同学反馈2019年12月中旬etcd慢日志监控出现大量的告警记录,而且告警呈上升趋势。 2020-01-20 运维同学继续反馈etcd慢日志告警数量继续上涨,未呈现稳态趋势。 问题分析 2020-01-06 运维同学反馈告警问题时,当时怀疑etcd 集群磁盘latency性能问题,通过etcd metrics接口dump backend_commit_duration_seconds 和 wal_fsync_duration_seconds,latency区间在128ms。etcd官方文档 what-does-the-etcd-warning-apply-entries-took-too-long-mean

ElasticSearch的基本概念和集群分布式底层实现

限于喜欢 提交于 2020-08-17 08:59:46
云栖号资讯:【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 深度分页引发的机器性能问题 最近碰到一个ElasticSearch深度分页搜索,导致cpu占用过高问题,通过查阅ElasticSearch: 权威指南,了解到了深度分页为何会引起机器资源占用: 在集群系统中深度分页 为了理解为什么深度分页是有问题的,让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一页(结果1到10)时,每个分片产生自己最顶端10个结果然后返回它们给请求节(requesting node),它再排序这所有的50个结果以选出顶端的10个结果。 现在假设我们请求第1000页——结果10001到10010。工作方式都相同,不同的是每个分片都必须产生顶端的10010个结果。然后请求节点排序这50050个结果并丢弃50040个! 你可以看到在分布式系统中,排序结果的资源和时间花费随着分页的深入而成倍增长。这也是为什么网络搜索引擎中任何语句不能返回多于1000个结果的原因。 理解以上那段文字,有必要了解ElasticSearch集群以及在集群中是查询的底层原理,本文试图通过总结ElasticSearch基本概念和底层原理,加深自身理解,同时希望对使用者有所帮助,避免不必要的踩坑。 基本概念 索引(index) “索引” 这个词在 ElasticSearch

2.docker学习笔记之入门,redis主从配置1

允我心安 提交于 2020-08-17 06:55:38
主从复制的作用主要包括: 1、数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。 2、故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。 3、负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点) 分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。 4、读写分离:可以用于实现读写分离,主库写、从库读,读写分离不仅可以提高服务器的负载能力,同时可根据需求的变化,改变从库的数量; 5、高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。 从节点开启主从复制,有3种方式: (1)配置文件 在从服务器的配置文件中加入:slaveof <masterip> <masterport> (2)启动命令 redis-server启动命令后加入 --slaveof <masterip> <masterport> (3)客户端命令 Redis服务器启动后,直接通过客户端执行命令:slaveof <masterip> <masterport>,则该Redis实例成为从节点。 通过 info replication

redis.conf5.0官方配置文件

房东的猫 提交于 2020-08-16 22:33:40
# Redis configuration file example. # # Note that in order to read the configuration file, Redis must be # started with the file path as first argument: # # ./redis-server /path/to/redis.conf # Note on units: when memory size is needed, it is possible to specify # it in the usual form of 1k 5GB 4M and so forth: # # 1k => 1000 bytes # 1kb => 1024 bytes # 1m => 1000000 bytes # 1mb => 1024*1024 bytes # 1g => 1000000000 bytes # 1gb => 1024*1024*1024 bytes # # units are case insensitive so 1GB 1Gb 1gB are all the same. ################################## INCLUDES ###################################

MySQL 的 crash-safe 原理解析

怎甘沉沦 提交于 2020-08-16 06:53:51
本文首发于 vivo互联网技术 微信公众号 链接: https://mp.weixin.qq.com/s/5i9wmJs4_Er7RaYfNnETyA []( https://mp.weixin.qq.com/s/5i9wmJs4_Er7RaYfNnETyA) 作者:xieweipeng MySQL作为当下最流行的开源关系型数据库,有一个很关键和基本的能力,就是必须能够保证数据不会丢。那么在这个能力背后,MySQL是如何设计才能保证不管在什么时间崩溃,恢复后都能保证数据不会丢呢?有哪些关键技术支撑了这个能力?本文将为我们一一揭晓。 一、前言 MySQL 保证数据不会丢的能力主要体现在两方面: 能够恢复到任何时间点的状态; 能够保证MySQL在任何时间段突然奔溃,重启后之前提交的记录都不会丢失; 对于第一点将MySQL恢复到任何时间点的状态,相信很多人都知道,只要保留有足够的binlog,就能通过重跑binlog来实现。 对于第二点的能力,也就是本文标题所讲的 crash-safe 。即在 InnoDB 存储引擎中,事务提交过程中任何阶段,MySQL突然奔溃,重启后都能保证事务的完整性,已提交的数据不会丢失,未提交完整的数据会自动进行回滚。这个能力依赖的就是redo log和unod log两个日志。 因为crash-safe主要体现在事务执行过程中突然奔溃,重启后能保证事务完整性

Redis持久化之AOF

限于喜欢 提交于 2020-08-16 01:29:20
一、定义 AOF是将所有的Redis的写命令记录到文件中,这个文件叫做AOF文件。 二、开启 ############################## APPEND ONLY MODE ############################### appendonly yes #默认的是no #是否开启 appendfilename "appendonly.aof" #文件名称 # appendfsync always appendfsync everysec #表示每秒执行一次fsync # appendfsync no 三、同时开启 RDB与AOF同时开启,优先加载AOF的文件。 四、AOF重写 用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件后去替换原来的 AOF 文件。 五、优缺点 优点:AOF提供了每秒同步得机制,所以丢失的数据最多是1秒内的数据。 缺点:相同的文件,AOF的文件要比RDB文件大一点。而且速度要比RDB慢一点 刻意练习 AOF的优缺点是什么 参考: Redis详解(七)------ AOF 持久化 来源: oschina 链接: https://my.oschina.net/u/4407552/blog/4279419