例子 以打印一个蓝色斜体的”hello, world“为例: C printf(“\033[3;34mhello, world\033[0m\n”); python print “\033[3;34mhello, world\033[0m” Shell echo -e ‘\033[3;34mhello, world\033[0m’ 格式 \033[Para0{;Para1…}mYOUR_TEXT\033[0m \033[Para0{;Para1…}m 表示转义开始 *033[0m 作为转义结束 Para0(1,2…) 参数可以为多个,比如上述例子*,3表示为斜体,34表示蓝色 YOUR_TEXT 在例子中就是hello, world 参数 Linux中通过man console_codes命令可查看详细的参数描述*这里写一下常用的格式和颜色: 常用格式: 参数代码 描述 0 重置所有格式 1 粗体(高亮) 2 暗色 3 斜体 4 下划线 5 闪烁 常用颜色: (前景色为30+颜色代码;背景色为40+颜色代码。) 颜色 代码 前景 背景 黑 0 30 40 红 […]

从MySQL 5.7版本开始,MySQL不仅支持原有的压缩表格式(Table Compression),还支持一种称为透明页压缩的特性(Transparent Page Compression)。通过阅资料和源码,我对这个特性有了一定的了解。以下我将从它的使用方法、实现原理等方面对它进行简单分析,并同压缩表格式进行一些对比。 1. 开启方法 官方文档对于透明页压缩的特性的说明仅仅一页,主要说明了它的使用方法,我也对这页官方文档进行过翻译,详见:InnoDB Page Compression MySQL文档翻译:InnoDB透明页压缩 对于透明页压缩的使用方法,和压缩表格式相同的是,都是通过CREATE TABLE或者ALTER TABLE语法对于一个表使用的。不同点是压缩表格式使用ROW_FORMAT=COMPRESSED这个字段,而透明页压缩使用COMPRESSION=”zlib”、COMPRESSION=”lz4″或者COMPRESSION=”None”这种字段。分别用两种压缩形式创建一个表的例子: ## 创建一个表,启用压缩表格式,块的大小为8K CREATE TABLE t1(c1 INT) ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; # 创建一个表,启用透明页压缩,压缩算法为LZ4 CREATE TABLE t1(c1 INT) COMPRESSION=”zlib”(“lz4”…); 另外要注意:开启透明页压缩需要文件系统和操作系统支持 Sparse File 和 Hole Punching 特性,并且需要开启InnoDB的file-per-table选项。更详细的使用方法见上边的那篇翻译。 2. 原理简述 2.1. 先说说以前压缩表格式

原文: [MySQL 5.7 Reference Manual 15.9.2 InnoDB Page Compression] https://dev.mysql.com/doc/refman/5.7/en/innodb-page-compression.html InnoDB支持file-per-table表空间中的表的页级压缩。 此功能称为透明页压缩。 通过使用CREATE TABLE或ALTER TABLE指定”COMPRESSION”这个表属性来启用页面压缩。 支持的压缩算法包括Zlib和LZ4。 支持的平台 页面压缩需要稀疏文件(sparse file)和打洞(hole punching)支持。 页面压缩在使用NTFS的Windows上被支持,并且在以下MySQL支持的Linux平台发行版的内核级别提供了打孔支持: RHEL 7 and derived distributions that use kernel version 3.10.0-123 or higher OEL 5.10 (UEK2) kernel version 2.6.39 or higher OEL 6.5 (UEK3) kernel version 3.8.13 or higher OEL 7.0 kernel version 3.8.13 or […]

原文: [MySQL 5.7 Manual 15.9.1.5 How Compression Works for InnoDB Tables] https://dev.mysql.com/doc/refman/5.7/en/innodb-compression-internals.html 本节介绍关于InnoDB表的压缩的一些内部实现细节。 这里介绍的信息可能有助于性能调优,但对压缩功能的基本使用并不必要。 压缩算法 某些操作系统在文件系统级别实现压缩。文件通常被分为固定大小的块,这些块被压缩后大小不固定,很容易导致碎片化。当块内的内容被修改时,在被写入磁盘之前,整个块都要被重新压缩。这些特性使得这种压缩技术不适合在update密集型当数据库系统中使用。 MySQL利用了广为人知的zlib库(基于LZ77压缩算法)来实现压缩功能。这种压缩算法在CPU利用率和减小数据大小方面都是成熟,稳健和高效的。该算法是“无损”的,从而可以始终从压缩形式重构原始的未压缩数据。 LZ77压缩通过查找要压缩的数据中重复的数据序列来实现压缩的目的。数据的具体形式决定了它的压缩程度,典型的用户数据通常会压缩50%或更多。 与一个应用程序执行的压缩或某些其他数据库管理系统的压缩功能不同,InnoDB压缩既适用于用户数据又适用于索引数据。在许多情况下,索引可以构成总数据库大小的40-50%以上,所以这带来的差异是显著的。当压缩对于某个数据集工作良好时,InnoDB数据文件(file-per-table的表空间或一般的表空间.idb文件)的大小是未压缩大小的25%到50%或更小。根据工作负载,压缩后的较小的数据库反过来很可能导致I/O数的减少,并以适度增加CPU占用率为成本增大了吞吐量。你可以通过修改innodb_compression_level配置选项来调整压缩级别和CPU开销之间的平衡。 InnoDB数据存储和压缩 InnoDB表中的所有用户数据都存储在包含B树索引(聚簇索引, clustered index)的页面中。 在其他一些数据库系统中,这种类型的索引称为“索引组织表”。 索引节点中的每一行都包含(用户指定的或系统生成的)主键和表的所有其他列的值。 InnoDB表中的辅助索引(secondary indexes)也是B树,包含键值对:索引键和指向聚簇索引中的某个行的指针。 指针实际上是表的主键的值,在需要除索引键和主键之外的列时,则需要查找到该值用来访问聚簇索引,进而访问到需要的列。 辅助索引记录必须始终可以放在单个B树页面。

原文: [MySQL 5.7 Manual 15.9.1.6 Compression for OLTP Workloads] https://dev.mysql.com/doc/refman/5.7/en/innodb-performance-compression-oltp.html 传统上,InnoDB压缩功能主要用于只读或大部分读取的工作负载,例如在数据仓库配置中。快速但相对较小和昂贵的SSD存储设备的兴起使得压缩对于OLTP工作负载也越发具有吸引力的:高流量的交互式网站可以通过使用压缩表同时使用具有执行频繁INSERT,UPDATE和DELETE操作的应用程序来减少其存储需求和每秒I/O操作数(IOPS)。 MySQL 5.6中引入的配置选项可让您调节压缩对特定MySQL实例的工作参数,其对于写入密集型操作的性能和可扩展性是很重要的: innodb_compression_level: 允许你向上或向下调整压缩程度,更高的值可以让你节省更多空间存储更多数据,同时在压缩时牺牲更多CPU周期,比较低的值可以让你在存储空间不重要时或者在数据不太适合被压缩时减小CPU开销。 innodb_compression_failure_threshold_pct: 指定了一个进行页压缩失败的百分比阈值,当它被超过时,MySQL开始在每个新的压缩页中增加一些额外的空闲的保留空间(padding),动态的调整这个空余空间的大小,padding的上限是由innodb_compression_pad_pct_max指定的,它是页面大小的一个百分比。 innodb_compression_pad_pct_max:允许你调整每个页面中用于直接保存更改和插入数据的空闲保留空间(padding)的最大值(这样就无需每次更改和插入都再次压缩整个页面)。 值越高,就可以记录更多的更改(???),而无需重新压缩页面。MySQL运行时,只有当需要昂贵分割操作的”压缩失败”达到上一个参数所指定的百分比时,才会为每个压缩表中的页面增加一个大小可变的空余空间(padding)。 innodb_log_compressed_pages:默认情况下,此选项被启用,以防止在恢复期间使用不同版本的zlib压缩算法时可能会发生损坏。 如果你确定zlib版本不会更改,请禁用innodb_log_compressed_pages以减少为修改压缩数据而生成的重做日志。 由于开启压缩时,内存中可能同时保留存在数据的压缩版本和未压缩版本,所以在OLTP工作负载下进行压缩时,innodb_buffer_pool_size配置选项的值可能会需要增加。

译者的废话 这是Red Hat RHEL 7文档中关于KVM虚拟机超量分配的说明文档,这里说的KVM,应该就是适用QEMU管理的KVM虚拟机的,因为在启动QEMU虚拟机的时候,只要-smp N和-m N参数分别就可以指定虚拟机的vCPU数和内存数,我实际实验发现,它们是都可以超过实际的物理CPU核数和内存大小的。 硬件资源超量分配,说的好听是节约资源,但是资源的分配超的不切实际,也就是”VPS超售”的万恶之源。。。比如一个4核8G内存的服务器,碰上黑心商家,不知道会被分出多少个1核1G内存的小崽子呢。。。不过这里Red Hat只是给出技术上的建议,没有提及VPS超售问题。嗯,做技术,不可耻。。。 原文: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/chap-Overcommitting_with_KVM.html#sect-Overcommitting_with_KVM-Introduction 简介 KVM hypervisor支持CPU和内存的超量分配。超量分配就是划分的虚拟CPU(vCPUs)或者内存比系统的实际物理资源多。通过CPU的超量分配,使用中的虚拟服务器或桌面就可以在更少的服务器上跑了,节省了不少系统资源,同时会减少电源、冷却等硬件方面的投资。 由于大多数进程始终不能访问其分配的内存的100%,因此KVM虚拟机可以利用此行为来分配给客户机虚拟机的多于实际可用的内存空间。 内存的超量分配 注意!