fsync

9.5的常用的一些设置，自己mark一下防止丢失;参数用途的说明，不做说明，仅为自己记录 <pre> max_connections = 3000 work_mem = 8MB shared_buffers = 1GB fsync = off synchronous_commit = off commit_delay = 500 commit_siblings = 25 checkpoint_completion_target = 0.9 autovacuum = on bgwriter_delay=10ms full_page_writes=off wal_writer_delay=10ms max_wal_size=32GB hot_standby=on wal_receiver_status_interval=1s hot_standby_feedback=on random_page_cost=1.0 maintenance_work_mem=64MB autovacuum_work_mem=64MB archive_mode=off enable_nestloop=off </pre> 9.6的并行查询参数,黑体标明， 官方说明： <pre> <b>Parallel query execution is not (yet) enabled by default. To

fio测试脚本 #!/bin/bash set -e ioengine="libaio" iodepth=128 direct=1 fsync=1 runtime=600 size="10G" mntdir="/mnt/fio-data/" mkdir -p /mnt/fio-data mount /dev/vdb /mnt/fio-data || true for m in seq rand do prefix="" if [ "$m" == "seq" ] ; then bs="1024K" else bs="4K" prefix="rand" fi for op in read write do cat <<EOF >$mntdir/fio-$m-$op.fio [global] fsync=$fsync name=fio-$m-$op filename=fio-$m-$op rw=$prefix$op bs=$bs direct=$direct numjobs=1 time_based=1 runtime=$runtime [file1] size=$size ioengine=$ioengine iodepth=$iodepth EOF done done docker rm -f $(docker ps -a -q) >/dev/null 2>&1|| true

redis 持久化机制有两种：RDB 和 AOF。 RDB RDB 机制是对 redis 中的数据执行周期性的持久化。每个几分钟、几小时、几天生成 redis 内存中的数据的一份完整的快照。 AOF 每条写入命令作为日志，写入 aof 文件中。现代操作系统中，写入文件不是直接写磁盘，会先写到 os cache，然后到一定时间再从 os cache 到磁盘文件。每隔 1 秒调用一次操作系统的 fsync 操作，强制将 os cache 中的数据，刷入磁盘文件中。 为了保证性能，会先写入 os cache 中，然后定期强制执行 fsync 操作将数据刷入磁盘。 原理： 每台单机 redis 的数据量收到内存限制，所以 aof 不会无线增长； 当数据超过内存限制的时候，会自动使用 LRU 算法将数据淘汰掉； AOF 存放的是每条写入的命令，所以会不断的膨胀，当达到一定的时候，会做 rewrite 操作； rewrite 操作：基于当时 redis 的内存中的数据，重新构造一个更小的 aof 文件，然后删除旧的 aof 文件。 总结：aof 被不断的追加，内存中的数据有最大限制，会被自动淘汰，当 aof 中的数据大于内存中数据时，就会执行 rewrite 操作，生成新的 aof 文件。 AOF 机制对每一条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在

英文原文参见： https://moosefs.com/documentation/faq.html#26 找翻译工具翻译的，个人感觉还比较准确，如有疏漏和错误的地方，各位可留言说明。 欢迎交流沟通：QQ 249016681 ------------------------------------------------------------------------------------- 经常问的问题 目录： 1、我们期望什么平均的写入/读取速度？ 2、目标设置是否影响写入/读取速度？ 3、是否支持并发读写操作？ 4、使用多少CPU / RAM资源？ 5、是否可以在飞行中添加/删除chunkserver和磁盘？ 6、如何标记要删除的磁盘？ 7、我对集群文件系统的经验是元数据操作相当慢。你是如何解决这个问题的？ 8、目录大小的值在MooseFS上有什么意义？它与标准Linux ls -l输出不同。为什么？ 9、当我在文件系统上执行df -h时，结果与预期的相符，考虑到书面文件的实际大小。 10、我可以在MooseFS上保留源代码吗？为什么小文件占用的空间比预期的多？ 11、Chunkservers和Metadata Server是否自行进行校验和？ 12、主服务器需要什么资源？ 13、当我删除文件或目录时，MooseFS大小不会改变。为什么？ 14

概要 本篇我们来看看shard内部的一些操作原理，了解一下人家是怎么玩的。 倒排索引 倒排索引的结构，是非常适合用来做搜索的，Elasticsearch会为索引的每个index为analyzed的字段建立倒排索引。 基本结构 倒排索引包含以下几个部分： 某个关键词的doc list 某个关键词的所有doc的数量IDF（inverse document frequency） 某个关键词在每个doc中出现的次数：TF（term frequency） 某个关键词在这个doc中的次序 每个doc的长度：length norm 某个关键词的所有doc的平均长度 记录这些信息，就是为了方便搜索的效率和_score分值的计算。 不可变性 倒排索引写入磁盘后就是不可变的，这样有几个好处： 不需要锁，如果不更新索引，不用担心锁的问题，可以支持较高的并发能力 如果cache内存足够，不更新索引的话，索引可以一直保存在os cache中，可以提升IO性能。 如果数据不变，filter cache会一直驻留在内存。 索引数据可以压缩，节省cpu和io开销。 doc底层原理 前面提到倒排索引是基于不可变模式设计的，但实际Elasticsearch源源不断地有新数据进来，那光是建立、删除倒排索引，岂不是非常忙？ 如果真是不停地建立，删除倒排索引，那ES压力也太大了，肯定不是这么实现的

为什么这么设计（Why’s THE Design）是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题，可以在文章下面留言。 数据库管理系统在今天已经是软件的重要组成部分，开源的 MySQL、PostgreSQL 以及商业化的 Oracle 等数据库已经随处可见，几乎所有的服务都需要依赖数据库管理系统存储数据。 图 1 - 数据库 数据库不会丢失数据听起来像是理所当然的事情，持久化能力也应该是数据库的最基本保障，但是在这个复杂的世界上想要保证数据不丢失是很困难的。在今天，我们能找到很多数据库出现问题导致数据丢失的例子： MongoDB 在过去很长的一段时间都不能保证持久性，很容易就会丢失数据1； RocksDB DeleteRange 功能导致的数据丢失问题2； 腾讯云硬盘故障，导致创业公司线上生产数据完全丢失的问题3； 无论是开源数据库还是云服务商提供的服务，都有可能发生数据丢失的。本文将数据库丢失数据的原因归结到以下的几个方面，我们将详细展开介绍这些原因： 人为因素导致的运维和配置错误是数据库丢失数据的首要原因； 数据库存储数据使用的磁盘损坏导致数据丢失； 数据库的功能和实现复杂，数据没有及时刷入磁盘就有丢失的风险； 人为错误

为什么这么设计（Why’s THE Design）是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题，可以在文章下面留言。 数据库管理系统在今天已经是软件的重要组成部分，开源的 MySQL、PostgreSQL 以及商业化的 Oracle 等数据库已经随处可见，几乎所有的服务都需要依赖数据库管理系统存储数据。 图 1 - 数据库 数据库不会丢失数据听起来像是理所当然的事情，持久化能力也应该是数据库的最基本保障，但是在这个复杂的世界上想要保证数据不丢失是很困难的。在今天，我们能找到很多数据库出现问题导致数据丢失的例子： MongoDB 在过去很长的一段时间都不能保证持久性，很容易就会丢失数据1； RocksDB DeleteRange 功能导致的数据丢失问题2； 腾讯云硬盘故障，导致创业公司线上生产数据完全丢失的问题3； 无论是开源数据库还是云服务商提供的服务，都有可能发生数据丢失的。本文将数据库丢失数据的原因归结到以下的几个方面，我们将详细展开介绍这些原因： 人为因素导致的运维和配置错误是数据库丢失数据的首要原因； 数据库存储数据使用的磁盘损坏导致数据丢失； 数据库的功能和实现复杂，数据没有及时刷入磁盘就有丢失的风险； 人为错误

　　在自动化测试中，经常需要查找操作文件，比如说查找配置文件（从而读取配置文件的信息），查找测试报告（从而发送测试报告邮件），经常要对大量文件和大量路径进行操作， 这个时候就需要用到 os 模块 ，使用前先导入 os 模块，即： import os（该模块是系统自带的，直接导入就可以） 举例说明几个常用的OS模块下的方法 os.getcwd() 获取当前工作目录 os.chdir()切换工作目录 os.listdir() 返回指定目录下的文件名， 注：返回的是以列表形式 os.path.join() 连接目录或文件名 序号 方法及描述 1 os.access(path, mode) 检验权限模式 2 os.chdir(path) 改变当前工作目录 3 os.chflags(path, flags) 设置路径的标记为数字标记。 4 os.chmod(path, mode) 更改权限 5 os.chown(path, uid, gid) 更改文件所有者 6 os.chroot(path) 改变当前进程的根目录 7 os.close(fd) 关闭文件描述符 fd 8 os.closerange(fd_low, fd_high) 关闭所有文件描述符，从 fd_low (包含) 到 fd_high (不包含), 错误会忽略 9 os.dup(fd) 复制文件描述符 fd 10 os.dup2

使用python的os模块，简单方便完成对文件夹、文件及路径的管理与访问操作。 1 前言 在最近开发中，经常需要对文件进行读取、遍历、修改等操作，想要快速、简单的完成这些操作，我选择用 python 。通过 python 的标准内置 os 模块，只需要几行代码，即可完成想要的操作。经过对 os 的使用，本文把 os 模块的常用的操作进行总结，主要分为以下几个划分： 文件夹操作：即文件夹的创建、修改（改名/移动），查询（查看、遍历）、删除等。 文件操作：即文件的创建、修改、读取、删除等。 （文件夹/文件）路径操作：即文件夹或文件的路径操作，如绝对路径，文件名与路径分割，扩展名分割等 本文涉及常用 的 os 函数的使用展示，主要使用 python 交互模式下进行代码说明。后续操作默认已经引入 os 模块，如下： import os 2 文件夹操作 以本地 E://pythontest 目录作为演示目录，此目录下当前文件如下： test │ test.txt └─test-1 test-1.txt test 及 test-1 是文件夹， test.txt 及 test-1.txt 是文件。 2.1 查询操作 熟悉 linux 同学应该对 ls / pwd / cd 等操作不陌生，对应的 python 也有对应的方法，主要包括： listdir ： 文件及目录列表 getcwd

RDB：将当前进程数据生成快照保存到硬盘的过程。 两种方式： save：阻塞当前Redis服务器知道RDB过程完成。 bgsave：Redis进程fork子进程，完成后自动结束，Redis阻塞只发生在fork阶段。 执行shutdown命令时在没有开启AOF时会自动执行bgsave。 Redis会对采用LZF算法对RDB文件进行压缩处理 RDB优点 RDB是一个紧凑的二进制文件，代表某个时间点上的数据快照，适用于备份、全量复制等场景 RDB的数据恢复速度远快于AOF模式 RDB缺点 RDB无法做到实时持久化，且每次都需要fork子进程，执行成本高 RDB文件存在多个格式，新老版本无法兼容 AOF：通过日志记录每次写命令，重启时再重新执行AOF文件中的命令打到数据恢复的目的，解决了数据持久化的实时性问题。 文件同步： always：每次写入aof_buf后都需要调用fsync进行同步到AOF的操作。 everysec：每次写入aof_buf后调用write操作，fsync操作由专门线程每秒执行一次。 no：每次写入aof_buf后调用write操作，同步周期不可控，通常最长30秒 AOF重写机制：减少了文件的占用空间，且更小的AOF文件能更快被Redis加载。 超时数据不再写入文件 删除旧AOF文件中的无效命令 多条写操作合并为一条