ID Mapper, idmapper, fs.nfs.idmap_cache_timeout Id mapper is used by NFS to translate user and group ids into names, and to translate user and group names into ids. Part of this translation involves performing an upcall to userspace to request the information. fs.nfs.idmap_cache_timeout 设置idmapper缓存项的最大寿命,单位是秒 https://www.kernel.org/doc/Documentation/filesystems/nfs/idmapper.txt https://www.cnblogs.com/tolimit/p/5065761.html
epoll, kqueue epoll 通过使用红黑树(RB-tree)搜索被监视的文件描述符(file descriptor)。 用户空间与内核空间 现在操作系统都是采用虚拟存储器,那么对32位操作系统而言,它的寻址空间 (虚拟存储空间) 为4G (2的32次方) 。操作系统的核心是内核,独立于普通的应用程序,可以访问受保护的内存空间,也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核 (kernel) ,保证内核的安全,操心系统将虚拟空间划分为两部分,一部分为内核空间,一部分为用户空间。针对linux操作系统而言,将最高的1G字节 (从虚拟地址0xC0000000到0xFFFFFFFF) ,供内核使用,称为内核空间,而将较低的3G字节 (从虚拟地址0x00000000到0xBFFFFFFF) ,供各个进程使用,称为用户空间。 进程切换 为了控制进程的执行,内核必须有能力挂起正在CPU上运行的进程,并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说,任何进程都是在操作系统内核的支持下运行的,是与内核紧密相关的。 从一个进程的运行转到另一个进程上运行,这个过程中经过下面这些变化: 保存处理机上下文,包括程序计数器和其他寄存器。 更新PCB信息。 把进程的PCB移入相应的队列,如就绪、在某事件阻塞等队列。 选择另一个进程执行,并更新其PCB。 更新内存管理的数据结构。 恢复处理机上下文。 进程的阻塞 正在执行的进程,由于期待的某些事件未发生,如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等,则由系统自动执行阻塞原语(Block),使自己由运行状态变为阻塞状态。可见,进程的阻塞是进程自身的一种主动行为,也因此只有处于运行态的进程 (获得CPU) ,才可能将其转为阻塞状态。当进程进入阻塞状态,是不占用CPU资源的。 缓存 I/O 缓存 I/O 又被称作标准 I/O,大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中,操作系统会将 I/O 的数据缓存在文件系统的页缓存 ( page cache ) 中,也就是说,数据会先被拷贝到操作系统内核的缓冲区中,然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。 缓存 I/O 的缺点: 数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作,这些数据拷贝操作所带来的 CPU 以及内存开销是非常大的。 IO模式 刚才说了,对于一次IO访问 (以read举例) ,数据会先被拷贝到操作系统内核的缓冲区中,然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。所以说,当一个read操作发生时,它会经历两个阶段: 等待数据准备 (Waiting for the data to be ready) 将数据从内核拷贝到进程中 (Copying the data from the kernel to the process) 正式因为这两个阶段,linux系统产生了下面五种网络模式的方案。 ...
Shell 逐行处理文本文件， shell 读文件 https://www.cnblogs.com/dwdxdy/archive/2012/07/25/2608816.html read命令 read命令接收标准输入,或其他文件描述符的输入,得到输入后,read命令将数据放入一个标准变量中． 用read读取文件时,每次调用read命令都会读取文件中的"一行"文本． 当文件没有可读的行时, read命令将以非零状态退出． #!/bin/bash cat data.dat | while read line; do echo "File:${line}" done while read line; do echo "File:${line}" done <data.dat 2.使用awk命令完成 awk是一种优良的文本处理工具,提供了极其强大的功能． 利用awk读取文件中的每行数据,并且可以对每行数据做一些处理,还可以单独处理每行数据里的每列数据． 1 cat data.dat | awk ‘{print $0}’ 2 cat data.dat | awk ‘for(i=2;i<NF;i++) {printf $i} printf “\n”}’ 第1行代码输出data.dat里的每行数据,第2代码输出每行中从第2列之后的数据． 如果是单纯的数据或文本文件的按行读取和显示的话,使用awk命令比较方便． 3.使用for var in file 命令完成 for var in file表示变量var在file中循环取值．取值的分隔符由$IFS确定． 复制代码 1 for line in $(cat data.dat) 2 do 3 echo “File:${line}” 4 done 6 for line in cat data.dat ...
RCU RCU是read-copy-update的简称,翻译为中文有点别扭"读-复制-更新"。它是是一种同步机制,有三种角色或者操作: 读者、写者和复制操作,我理解其中的复制操作就是不同CPU上的读者复制了不同的数据值,或者说拥有同一个指针的不同拷贝值,也可以理解为: 在读者读取值的时候,写者复制并替换其内容 (后一种理解来自于RCU作者的解释) 。它于2002年10月引入Linux内核。 RCU允许读操作可以与更新操作并发执行,这一点提升了程序的可扩展性。常规的互斥锁让并发线程互斥执行,并不关心该线程是读者还是写者,而读/写锁在没有写者时允许并发的读者,相比于这些常规锁操作,RCU在维护对象的多个版本时确保读操作保持一致,同时保证只有所有当前读端临界区都执行完毕后才释放对象。RCU定义并使用了高效并且易于扩展的机制,用来发布和读取对象的新版本,还用于延后旧版本对象的垃圾收集工作。这些机制恰当地在读端和更新端并行工作,使得读端特别快速。在某些场合下 (比如非抢占式内核里) ,RCU读端的函数完全是零开销。 https://cloud.tencent.com/developer/article/1006226 https://cloud.tencent.com/developer/article/1006236 https://blog.csdn.net/juS3Ve/article/details/78447574
SysRq https://blog.csdn.net/jasonchen_gbd/article/details/79080576 SysRq是Linux提供的一个"Magic System Request Key", 它可以在系统出现故障的时候协助恢复和调试系统。只要你的虚拟终端或串口还可以接收键盘输入 (系统还能响应键盘的按键中断), SysRq 就可用, 你可以借助它来查看当时的内存、进程状态等信息,而不是直接强行拔掉电源重启系统。 SysRq能做的事情看HELP就知道了: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) SysRq的用法 2.1 启用SysRq 首先要确保内核打开了CONFIG_MAGIC_SYSRQ配置项,这样SysRq的底层处理才可用。 另外内核中有一个宏定义SYSRQ_DEFAULT_ENABLE,表示系统默认情况下是否启用SysRq功能键。当然,不管这个值是不是yes,你都可以通过proc文件系统来开启或关闭SysRq键: 查看当前SysRq是否被开启 (0表示关闭), archlinux 默认开启 cat /proc/sys/kernel/sysrq 开启SysRq: echo 1 > /proc/sys/kernel/sysrq 也可以使用sysctl命令: sysctl -w kernel.sysrq=1 kernel.sysrq = 1 实际上sysctl这条命令就是通过修改/proc/sys/kernel/sysrq来生效的。可以把"kernel.sysrq = 1"设置到/etc/sysctl.conf中,使SysRq在下次系统重启仍生效。 上面说0表示完全关闭SysRq,1表示使能SysRq的所有功能,还可以设置成其他数字来选择开启部分功能,可参考内核里的Documentation/sysrq.txt。 SysRq支持的所有功能列表及相应的handler见drivers/tty/sysrq.c中静态数组sysrq_key_table[]的定义,当然,也可以通过下面提到的SysRq的help信息了解到。 2.2 使用SysRq 我们可以直接通过按键的方式或者通过写/proc/sysrq-trigger的方式来触发SysRq的操作。SysRq支持的操作可参考下面的HELP输出: echo > /proc/sysrq-trigger [16037.132214] SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) ...
rclone mount google drive, webdav, onedrive install rclone # install rclone sudo pacman -S rclone sudo pacman -S fuse config fuse sudo vim /etc/fuse.conf # uncomment user_allow_other user_allow_other google drive # config rclone rclone config # n, new config # name? name-foo, a name # 11, google drive # client id, leave blank # client secret, leave blank # 1, full access # root_folder_id, get from https://drive.google.com/drive/folders/ # service_account_file, leave blank # Edit advanced config? (y/n) n # auto config? y # team drive? y # y) Yes this is OK, y # q) Quit config, q rclone mount name-foo:path/to/files /path/to/local/mount --allow-other --vfs-cache-mode writes rclone lsl foo: rclone dedupe --dedupe-mode newest $name # linux mount google drive rclone mount foo: /path/to/mount/point --allow-other --vfs-cache-mode writes # windows mount google drive rclone.exe mount foo:/ x: --cache-dir C:\path\to\cache\dir --vfs-cache-mode writes # foo: google drive rclone name # x: 挂载到的系统盘符 # --cache-dir C:\path\to\cache\dir, 缓存目录 mount webdav rclone config n name0 # enter name 24 #webdav, see help at https://rclone.org/webdav/ #enter webdav url #列出目录内容 # 注意: rclone 挂载点名字后面有冒号 rclone lsl mount via systemd uid=1000, gid=2000 ...
Awk/Unix group by $ awk -F, 'NR>1{arr[$1]++}END{for (a in arr) print a, arr[a]}' file.txt joe 1 jim 1 mike 3 bob 2 EXPLANATIONS -F, splits on , NR>1 treat lines after line 1 arr[$1]++ increment array arr (split with ,) with first column as key END{} block is executed @ the end of processing the file for (a in arr) iterating over arr with a key print a print key , arr[a] array with a key ...
sysctl archlinux systemd-sysctl 服务在启动时会加载 /etc/sysctl.d/*.conf, 配置内核参数 /etc/sysctl.conf 不起作用 sysctl 命令被用于在内核运行时动态地修改内核的运行参数, 可用的内核参数在目录 /proc/sys 中。它包含一些 TCP/ip 堆栈和虚拟内存系统的高级选项,用sysctl可以读取设置超过五百个系统变量。 CentOS 5 supported the placement of sysctl directives in files under /etc/sysctl.d/ . The code is within /etc/init.d/functions sysctl [options] [variable[=value] …] -a: 打印所有内核参数 -n: 打印时只打印值,不打印参数名称； -e: 忽略未知关键字错误； -N: 打印时只打印参数名称,不打印值； -w: 设置参数的值 -p: 从配置文件 "/etc/sysctl.conf" 加载内核参数设置 -A: 以表格方式打印所有内核参数变量。 查看变量 # 查看 sysctl net.ipv4.ip_forward cat /proc/sys/net/ipv4/ip_forward # 查看变量, 打印所有参数并过滤 sysctl -a | grep tcp_syn_retrie sudo sysctl -a | egrep "rmem|wmem|adv_win|moderate" 设置内核参数 临时设置 重启之后会恢复为默认值。 ...
Uboot https://www.jianshu.com/p/42106ed7cbde 我们知道,bootloader是系统上电后最初加载运行的代码。它提供了处理器上电复位后最开始需要执行的初始化代码。 在PC机上引导程序一般由BIOS开始执行,然后读取硬盘中位于MBR(Main Boot Record,主引导记录)中的Bootloader(例如LILO或GRUB),并进一步引导操作系统的启动。 然而在嵌入式系统中通常没有像BIOS那样的固件程序,因此整个系统的加载启动就完全由bootloader来完成。它主要的功能是加载与引导内核映像 一个嵌入式的存储设备通过通常包括四个分区: 第一分区: 存放的当然是u-boot 第二个分区: 存放着u-boot要传给系统内核的参数 第三个分区: 是系统内核 (kernel) 第四个分区: 则是根文件系统 如下图所示: 四大分区 u-boot是一种普遍用于嵌入式系统中的Bootloader。 Bootloader介绍 Bootloader是进行嵌入式开发必然会接触的一个概念,本篇文章主要讲解Bootloader的基本概念以及内部原理,这部分内容的掌握将对嵌入式linux系统开发的学习非常有帮助！ Bootloader的定义: Bootloader是在操作系统运行之前执行的一小段程序,通过这一小段程序,我们可以初始化硬件设备、建立内存空间的映射表,从而建立适当的系统软硬件环境,为最终调用操作系统内核做好准备。意思就是说如果我们要想让一个操作系统在我们的板子上运转起来,我们就必须首先对我们的板子进行一些基本配置和初始化,然后才可以将操作系统引导进来运行。具体在Bootloader中完成了哪些操作我们会在后面分析到,这里我们先来回忆一下PC的体系结构: PC机中的引导加载程序是由BIOS和位于硬盘MBR中的OS Boot Loader (比如LILO和GRUB等) 一起组成的,BIOS在完成硬件检测和资源分配后,将硬盘MBR中的Boot Loader读到系统的RAM中,然后将控制权交给OS Boot Loader。Boot Loader的主要运行任务就是将内核映象从硬盘上读到RAM中,然后跳转到内核的入口点去运行,即开始启动操作系统。在嵌入式系统中,通常并没有像BIOS那样的固件程序 (注: 有的嵌入式cpu也会内嵌一段短小的启动程序) ,因此整个系统的加载启动任务就完全由Boot Loader来完成。比如在一个基于ARM7TDMI core的嵌入式系统中,系统在上电或复位时通常都从地址0x00000000处开始执行,而在这个地址处安排的通常就是系统的Boot Loader程序。 (先想一下,通用PC和嵌入式系统为何会在此处存在如此的差异呢？) Bootloader是基于特定硬件平台来实现的,因此几乎不可能为所有的嵌入式系统建立一个通用的Bootloader,不同的处理器架构都有不同的Bootloader,Bootloader不但依赖于cpu的体系结构,还依赖于嵌入式系统板级设备的配置。对于2块不同的板子而言,即使他们使用的是相同的处理器,要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上,一般也需要修改Bootloader的源程序。 Bootloader的启动方式 Bootloader的启动方式主要有网络启动方式、磁盘启动方式和Flash启动方式。 网络启动方式 如图1所示,里面主机和目标板,他们中间通过网络来连接,首先目标板的DHCP/BIOS通过BOOTP服务来为Bootloader分配IP地址,配置网络参数,这样才能支持网络传输功能。我们使用的u-boot可以直接设置网络参数,因此这里就不用使用DHCP的方式动态分配IP了。接下来目标板的Bootloader通过TFTP服务将内核映像下载到目标板上,然后通过网络文件系统来建立主机与目标板之间的文件通信过程,之后的系统更新通常也是使用Boot Loader的这种工作模式。工作于这种模式下的Boot Loader通常都会向它的终端用户提供一个简单的命令行接口。 磁盘启动方式 这种方式主要是用在台式机和服务器上的,这些计算机都使用BIOS引导,并且使用磁盘作为存储介质,这里面两个重要的用来启动linux的有LILO和GRUB,这里就不再具体说明了。 Flash启动方式 这是我们最常用的方式。Flash有NOR Flash和NAND Flash两种。NOR Flash可以支持随机访问,所以代码可以直接在Flash上执行,Bootloader一般是存储在Flash芯片上的。另外Flash上还存储着参数、内核映像和文件系统。这种启动方式与网络启动方式之间的不同之处就在于,在网络启动方式中,内核映像和文件系统首先是放在主机上的,然后经过网络传输下载进目标板的,而这种启动方式中内核映像和文件系统则直接是放在Flash中的,这两点在我们u-boot的使用过程中都用到了。 U-boot的定义 U-boot,全称Universal Boot Loader,是由DENX小组的开发的遵循GPL条款的开放源码项目,它的主要功能是完成硬件设备初始化、操作系统代码搬运,并提供一个控制台及一个指令集在操作系统运行前操控硬件设备。U-boot之所以这么通用,原因是他具有很多特点: 开放源代码、支持多种嵌入式操作系统内核、支持多种处理器系列、较高的稳定性、高度灵活的功能设置、丰富的设备驱动源码以及较为丰富的开发调试文档与强大的网络技术支持。另外u-boot对操作系统和产品研发提供了灵活丰富的支持,主要表现在: 可以引导压缩或非压缩系统内核,可以灵活设置/传递多个关键参数给操作系统,适合系统在不同开发阶段的调试要求与产品发布,支持多种文件系统,支持多种目标板环境参数存储介质,采用CRC32校验,可校验内核及镜像文件是否完好,提供多种控制台接口,使用户可以在不需要ICE的情况下通过串口/以太网/USB等接口下载数据并烧录到存储设备中去 (这个功能在实际的产品中是很实用的,尤其是在软件现场升级的时候) ,以及提供丰富的设备驱动等。 u-boot源代码的目录结构 board中存放于开发板相关的配置文件,每一个开发板都以子文件夹的形式出现。 Commom文件夹实现u-boot行下支持的命令,每一个命令对应一个文件。 cpu中存放特定cpu架构相关的目录,每一款cpu架构都对应了一个子目录。 Doc是文档目录,有u-boot非常完善的文档。 Drivers中是u-boot支持的各种设备的驱动程序。 Fs是支持的文件系统,其中最常用的是JFFS2文件系统。 Include 文件夹是 u-boot 使用的头文件, 还有各种硬件平台支持的汇编文件,系统配置文件和文件系统支持的文件。 ...
pandavan # restart dnsmasq restart_dhcpd
arp command ARP 协议概述 IP 数据包常通过以太网发送。以太网设备并不识别32位IP地址: 它们是以48位以太网地址传输以太网数据包的。因此,IP驱动器必须把IP目的地址转换成以太网网目的地址。在这两种地址之间存在着某种静态的或算法的映射,常常需要查看一张表。地址解析协议(Address Resolution Protocol,ARP)就是用来确定这些映象的协议。 ARP工 作时,送出一个含有所希望的IP地址的以太网广播数据包。目的地主机,或另一个代表该主机的系统,以一个含有IP和以太网地址对的数据包作为应答。发送者将这个地址对高速缓存起来,以节约不必要的ARP通信。 https://www.ibm.com/developerworks/cn/linux/l-arp/index.html pacman -S core/net-tools # mac ip mapping arp -a
MySQL count 性能 https://blog.csdn.net/kjsoftware/article/details/76762208 COUNT()的作用 COUNT()是一个特殊的函数,有两种非常不同的作用: 它可以统计某个列值的数量,也可以统计行数。在统计列值时要求列值时非空的 (不统计NULL) 。如果在COUNT()的括号中指定了列或列的表达式,统计的就是这个表达式有值的结果数。因为很多人对NULL理解有问题,所以这里很容易产生误解。如果想了解更多关于SQL语句中NULL的含义,建议阅读一些关于SQL语句基础的书籍。 (关于这个话题,互联网上的一些信息是不够精确的) COUNT()的另外一个作用是统计结果集的行数。当MySQL确认括号内的表达式值不可能为空时,实际上就是在统计行数。最简单的就是当我们使用COUNT(_)的时候,这种情况下通配符_并不会像我们猜想的那样扩展成所有的列,实际上,它会忽略所有的列而直接统计所有的行数。 我们发现一个最常见的错误就是,在括号内指定了一个列却希望统计结果集的行数。如果希望知道的是结果集的行数,最好使用COUNT(*),这样写意义清晰,性能也会很好。 于MyISAM的神话 一个容易产生的误解就是: MyISAM的COUNT()函数总是非常快,不过这是有前提条件的,即只有没有任何where条件的COUNT()才非常快,因为此时无需实际地去计算表的行数。MySQL可以利用存储引擎的特性直接获得这个值。如果MySQL知道某列col不可能为NULL值,那么MySQL内部会将COUNT(col)表达式优化为COUNT()。 当统计带WHERE子句的结果集行数,可以是统计某个列值的数量时,MySQL的COUNT()和其它存储引擎没有任何不同,就不再有神话般的速度了。所以在MyISAM引擎表上执行COUNT()有时候比别的引擎快,有时候比别的引擎慢,这受很多因素影响,要视具体情况而定。 《高性能MySQL》这本书只介绍了MyISAM存储引擎在count上的误区以及在MyISAM存储引擎上的count优化,而对于常用的innodb执行Count没有做过多讲解,下面我们就聊聊如何在Innodb上进行count优化。 Innodb存储引擎: (1) innodb存储引擎的物理结构包含 表空间、段、区、页、行 五个层级,数据文件按照主键排序存储在页中 (页在逻辑上连续) ,主键的位置即为数据存储位置。 (2) 二级索引存储的数据为指定字段的值与主键值。当我们通过二级索引统计数据的时候,无需扫描数据文件；而通过主键索引统计数据时,由于主键索引与数据文件存放在一起,所以每次都会扫描数据文件,故大多数情况下,通过二级索引统计数据效率 >= 基于主键统计效率。 (3) 由于二级索引存储的数据为指定字段的值与主键值,故在无索引覆盖的情况下,查询二级索引后会根据二级索引获取的主键到主键索引中提取数据,此过程可能造成大量的随机io,导致查询速度较慢。 (4) 由于主键索引与数据存储保持一致,故基于主键的查找数据要比通过二级索引查询数据要快 (使用二级索引时,查询到的数据条数>总条数的20%时候MySQL就选择全表扫描,但在主键索引上,即使符合条件的达到 90%依然会走索引) 。 count慢的原因: innodb为聚簇索引同时支持事物,其在count指令实现上采用实时统计方式。在无可用的二级索引情况下,执行count会使MySQL扫描全表数据,当数据中存在大字段或字段较多时候,其效率非常低下 (每个页只能包含较少的数据条数,需要访问的物理页较多) 。 innodb可优化点: 主键需要采用占用空间尽量小的类型且数据具有连续性 (推荐自增整形id) ,这样有利于减少页分裂、页内数据移动,可加快插入速度同时有利于增加二级索引密度 (一个数据页上可以存储更多的数据) 。 2.在表包含大字段或字段较多情况下,若存在count统计需求,可建一个较小字段的二级索引 (例 char(1) , tinyint )来进行count统计加速。 下面做个count优化例子: 1.首先我们创建一直innodb表,并包含大字段 (或包含较多字段) : CREATE TABLE qstardbcontent ( id BIGINT(20) NOT NULL DEFAULT ‘0’, content MEDIUMTEXT, length INT(11) NOT NULL DEFAULT ‘0’, PRIMARY KEY (id) ...
MySQL 聚簇索引 https://yq.aliyun.com/articles/142879 https://blog.csdn.net/bigtree_3721/article/details/51335479 因为存储引擎负责实现索引,因此不是所有的存储引擎都支持聚簇索引。 一些数据库服务器允许选择哪个索引作为聚簇索引,但直到本书写作之前,还没有任何一个MySQL内建的存储引擎支持这一点。InnoDb将通过主键聚集数据。 如果没有定义主键,InnoDB 会选择一个唯一的非空索引代替。如果没有这样的索引,InnoDB 会隐式定义一个主键来作为聚簇索引。InnoDB值聚集在同一个页面中的记录。包含相邻键值的页面可能会相距很远。 聚簇索引可能对性能有帮助,但也可能导致严重的性能问题。所以需要考虑聚簇索引,尤其是将表的存储引擎从InnoDB 该成其他的引擎的时候 (返回来也一样) 。 数据访问更快。聚簇索引将索引和数据保存在同一个B-Tree中,因此从聚簇索引中获取数据通常比非聚簇索引中快。 二级索引 (非聚簇索引) 可能比想象的要更大,因为在二级索引的子节点包含了最优一个几点可能让人有些疑惑,为什么二级索引需要两次索引查找？答案在于二级索引中保存的"行指针"的实质。要记住,二级索引叶子节点保存的不是只想物理位置的指针,而是行的主键值。 InnoDB 的数据分布。因为InnoDB支持聚簇索引,索引使用非常不同的方式存储同样的数据。在InnoDB中,聚簇索引"就是"表,所以不像myISAM那样需要独立的行存储。聚簇索引的每一个叶子节点都包含了主键值、事务id,用于事务和MVCC的回滚指针。这样的策略减少了当前出现行移动或者数据页分裂是二级索引的维护工作。使用主键值当作指针会让二级索引占用更多的存储空间,存储,换来的好处是,InnoDB在移动行时,无需更新二级索引中的这个指针。InnoDB 的非叶子节点包含了索引列和一个纸箱下级节点的指针 (下级节点可以是叶子节点,也可以是非叶子节点) 。这对聚簇索引和二级索引都使用。 聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。相比之下,聚簇索引适合排序,非聚簇索引 (也叫二级索引) 不适合用在排序的场合。 因为聚簇索引本身已经是按照物理顺序放置的,排序很快。非聚簇索引则没有按序存放,需要额外消耗资源来排序。 当你需要取出一定范围内的数据时,用聚簇索引也比用非聚簇索引好。 另外,二级索引需要两次索引查找,而不是一次才能取到数据,因为存储引擎第一次需要通过二级索引找到索引的叶子节点,从而找到数据的主键,然后在聚簇索引中用主键再次查找索引,再找到数据。 辅助索引 在聚簇索引之上创建的索引称之为辅助索引,辅助索引访问数据总是需要二次查找。辅助索引叶子节点存储的不再是行的物理位置,而是主键值。通过辅助索引首先找到的是主键值,再通过主键值找到数据行的数据叶,再通过数据叶中的Page Directory找到数据行。 复合索引 由多列创建的索引称为符合索引,在符合索引中的前导列必须出现在where条件中,索引才会被使用 前缀索引 当索引的字符串列很大时,创建的索引也就变得很大,为了减小索引体积,提高索引的扫描速度,就用索引的前部分字串索引,这样索引占用的空间就会大大减少,并且索引的选择性也不会降低很多。而且是对BLOB和TEXT列进行索引,或者非常长的VARCHAR列,就必须使用前缀索引,因为MySQL不允许索引它们的全部长度。 使用: 列的前缀的长度选择很重要,又要节约索引空间,又要保证前缀索引的选择性要和索引全长度选择性接近。 唯一索引 唯一索引比较好理解,就是索引值必须唯一,这样的索引选择性是最好的 主键索引 主键索引就是唯一索引,不过主键索引是在创建表时就创建了,唯一索引可以随时创建。 说明 主键和唯一索引区别 主键是主键约束+唯一索引 主键一定包含一个唯一索引,但唯一索引不是主键 唯一索引列允许空值,但主键列不允许空值 一个表只能有一个主键,但可以有多个唯一索引
聚合函数 aggregation function, UNION, UNION ALL 聚合函数 (aggregation function) -也就是组函数 在一个行的集合 (一组行) 上进行操作,对每个组给一个结果。 集合查询操作 union 去重 union用于把两个或者多个select查询的结果集合并成一个 默认情况下,UNION = UNION DISTINCT 进行合并的两个查询,其SELECT列表必须在数量和对应列的数据类型上保持一致; 默认会去掉两个查询结果集中的重复行；默认结果集不排序； 最终结果集的列名来自于第一个查询的SELECT列表 union all 不去重 UNION ALL 不去掉结果集中重复的行 SELECT ... UNION [ALL | DISTINCT] SELECT ... [UNION [ALL | DISTINCT] SELECT ...] 常用的组函数: AVG([distinct] expr) 求平均值 COUNT({*|[distinct] } expr) 统计行的数量 MAX([distinct] expr) 求最大值 MIN([distinct] expr) 求最小值 SUM([distinct] expr) 求累加和 ①每个组函数接收一个参数 ②默认情况下,组函数忽略列值为null的行,不参与计算 ③有时,会使用关键字distinct剔除字段值重复的条数 注意: 当使用组函数的select语句中没有group by子句时,中间结果集中的所有行自动形成一组,然后计算组函数； 组函数不允许嵌套,例如: count(max(…))； 组函数的参数可以是列或是函数表达式； ...
nftable 透明代理 https://www.yangcs.net/posts/linux-circumvent/
svn change passwd svn change password after svn password changed, delete the folder $HOME/.subversion run svn checkout -username user svn://server/repo, input new password run git svn
systemd-networkd MAC address spoofing vim /etc/systemd/network/00-default.link [Match] MACAddress=old mac address [Link] MACAddress=new mac address NamePolicy=kernel database onboard slot path NamePolicy 应该如何设置网卡的名称, 仅在未使用 “net.ifnames=0” 内核引导选项时有意义。 接受一个空格分隔的策略列表, 顺序尝试每个策略,并以第一个成功的策略为准。 所得的名字将被用于设置网卡的 “ID_NET_NAME” 属性。 注意,默认的udev规则会用 “ID_NET_NAME” 的值设置 “NAME” 属性(也就是网卡的名称)。 如果网卡已经被空户空间命名,那么将不会进行任何重命名操作。 可用的策略如下: kernel 如果内核已经为此网卡设置了固定的可预测名称, 那么不进行任何重命名操作。 database 基于网卡的 “ID_NET_NAME_FROM_DATABASE” 属性值(来自于udev硬件数据库)设置网卡的名称。 onboard 基于网卡的 “ID_NET_NAME_ONBOARD” 属性值(来自于板载网卡固件)设置网卡的名称。 slot 基于网卡的 “ID_NET_NAME_SLOT” 属性值(来自于可插拔网卡固件)设置网卡的名称。 path 基于网卡的 “ID_NET_NAME_PATH” 属性值(来自于网卡的总线位置)设置网卡的名称。 mac 基于网卡的 “ID_NET_NAME_MAC” 属性值(来自于网卡的固定MAC地址)设置网卡的名称。 windows mac address windows 的无线网卡不支持直接修改 mac 地址，虽然可以通过修改注册表实现修改但是mac地址第二位只能修改为 2, 6, A, E 其中的一个， 改成其它值都不会生效。 ...
MySQL 在线修改表结构 http://www.cnblogs.com/wangtao_20/p/3504395.html MySQL在线修改表结构大数据表的风险与解决办法归纳 整理这篇文章的缘由: 互联网应用会频繁加功能,修改需求。那么表结构也会经常修改,加字段,加索引。在线直接在生产环境的表中修改表结构,对用户使用网站是有影响。 以前我一直为这个问题头痛。当然那个时候不需要我来考虑,虽然我们没专门的dba,他们数据量比我们更大,那这种问题也会存在。所以我很想看看业界是怎么做的,我想寻找有没有更高级的方案,呵呵,让我觉得每次开发一个新功能,我在线加字段都比较纠结。后来只知道,不清楚在什么时候,无意中看到一个资料介绍online-schema-change这个工具,于是顺便搜出了不少东西。后来逐渐发现腾讯,淘宝他们都会存在这种问题,我发现解决思路都差不多。具体看完我这篇归纳的文章 由于MySQL在线ddl(加字段、加索引等修改表结构之类的操作) 过程如下: A.对表加锁(表此时只读) B.复制原表物理结构 C.修改表的物理结构 D.把原表数据导入中间表中,数据同步完后,锁定中间表,并删除原表 E.rename中间表为原表 F.刷新数据字典,并释放锁 在这个过程中会锁表。造成当前操作的表无法写入数据,影响用户使用。由于需要复制原表的数据到中间表,所以表的数据量越大,等待的时候越长,卡死在那里(用户被拒绝执行update和insert操作,表现就是延迟了一直在等待)。 其实就是对表加了个排它锁,这个时候其他用户只能读表的数据,不能写。想具体体验一下是什么效果,我以前测验对MySQL的表加锁,操作的时候是如何的: http://www.cnblogs.com/wangtao_20/p/3463435.html 平时进行修改表的结构,更改字段,新增字段,更改字段名称一般都是通过ALTER TABLE TABLENAE 语法进行修改的。对于测试库,在线小表或者并发访问不是很大的情况是OK。但是如果是在线大表。那就很麻烦。由于表数据量大,复制表需要比较长的时间,在这个时间段里面,表是被加了锁的(写锁),加写锁时其他用户只能select表不能update、insert表。表数据量越大,耗时越长。 所以,对于数据量大的表,数量很大。在线修改表结构一直是一个头痛的问题,因为互联网应用的一大特点不能影响用户正常使用,否则用户会慢慢流失掉。 有些公司碰到的表数据很小,几万到几十万行数据一张表,可能还不会遇到应用卡死的问题。所以我们网站在跑,开发个新功能,需要加个新字段,经常是直接操作不会影响什么(何况只是延迟写入操作而已,呵呵) 看这几篇文章就知道了: http://wiki.hexnova.com/pages/viewpage.action?pageId=2031684 MySQL在线修改表字段造成的锁表 http://hidba.org/?p=795 比如就有人专门在加字段之前进行测验MySQL是否复制表,以减低应用卡死的风险: http://www.cnblogs.com/zuoxingyu/archive/2013/03/28/2986715.html 拷贝表结构,然后插入少量的数据。去修改表结构。看影响的行。如果为0,则表示不会拷贝中间表的方式 目前业界实践出了一些成熟的解决办法: 很多公司以前的做法是: 停掉MySQL服务器来修改表结构。然后进行滚动式更新。比如很多台MySQL服务器。先修改主服务器的表结构,把这台服务器停掉来更新(一般多台主服务器,让其他主服务器提供服务)。等到更新完,就滚动到从服务器(在此之前是其他从服务器提供服务的)。其实想想发现有个弊病: 修改表结构要等到很长时间才能生效。MySQL服务器越多,就需要的时间越长。那我可以理解: 假设需要几天,那只有等到更新完毕。才能把代码丢上去,因为表结构没有更新完毕,新的程序操作新的字段会出错的。 从冯大辉那篇文章那里听说,Facebook数千台MySQL服务器在过去增加个索引需要几个月的滚动升级(后来他们自己开发了后面提到的工具,只需要几天) 能够停掉MySQL服务器来修改字段,这就好办,时间长也无所谓,呵呵,至少用户不会使用你网站的时候卡死吧。但是互联网应用往往不能影响用户使用,所以很多公司尽量是在凌晨的时候进行操作(这个时候访问用户少,对用户影响就小) 比如像这个例子: http://www.MySQLops.com/2011/03/30/myisam-innodb.html 表的数据量上亿。要把表的存储引擎从myisam改为innodb(我觉得存储结构都不同了,转换需要时间更长),但是他是停掉MySQL服务器操作的。 阿里巴巴的冯大辉分享中也提到,业务应用大,需求就会频繁变化。所以就经常涉及到修改数据库字段,在线的调整字段是要考虑很多的问题的。作者认为,目前没有特别的方法来解决这个问题(技术是适应需求变化,支撑运营的)。他说豆瓣对此也很头痛,只能把服务器短暂的停一下。 测验法。加字段,加索引,先在测试环境模拟测试一下需要多长时间。免得服务器生产环境正式加的时候,应用卡死了,好有个预期准备。 我记得以前在a公司,表数据量也上千万,压根就没这种测验吧,大白天,就直接加字段和索引,反正我也不知道前台影响如何,当时我也没这个经验,何况我也不是技术负责人,呵呵,技术负责人都没不清楚这个,我那就更加没了,那个技术经理是做企业级开发的,跟web开发环境和思维方式是不同的,他不清楚会存在这些影响吧,再说,当时在加的时候没法凑巧用户投诉说,网站无法下单了啊,没这么巧的情况。其实从我现在理解角度来看,我绝对会更加严格点。 前面也提到了,国外有人研究修改表结构会不会复制一张临时表,就看"rows affected “的值。如果为0,则表示不会拷贝中间表的方式,这样子就很快的。我没试过 使用专门的辅助工具。一些公司开发了自己的内部工具来辅助进行。比如facebook。 另外腾讯的技术也介绍了他们自己定制的tMySQL进行在线加字段的实现原理: http://www.zhdba.com/MySQLops/2013/09/14/MySQL-innodb-online-ddl/ facebook自己开发的工具,官网: http://bazaar.launchpad.net/~MySQLatfacebook/MySQLatfacebook/tools/files/head:/osc 我记得好像最先是facebook进行了方案创新(呵呵,当你的遇到的是复杂问题,没有人解决过就只能先创造新的技术方案了),当时冯大辉专门写了一篇,其他文章介绍他们的创新。其他工具都是跟这个思路差不多的。不过我下载了facebook官网的,是用php实现的。没具体看。因为下载的包里面都是php文件。 总的来说,这些工具大致的理大同小异: 表结构的修改在创建的一张新表中执行(这样不需要锁定原表了,也就不会影响MySQL提供服务),更为关键的是解决了一个问题,当这个间隔时间内,用户在使用MySQL,对表数据进行了更新怎么办？ 工具的解决办法思路是,在原表中创建几个触发器针对uptate、delete 、insert操作都记录下来,这样子把对原表的操作记录下来,方便更新到新建立的临时表中中去。 听过豆瓣网的架构变迁分享会中提到,他们以前在这方面也吃过苦头的,一张很大的表(比如上千万),在线加个索引,由于数据量大,整个应用就卡死了。 其实有时候卡几个小时可能都很正常。死锁了嘛。另外对临时表要进行复制数据,建立这个临时表也需要时间嘛。 他们现在用的办法是: 先拷贝一张一模一样的表,数量也是差不多,先在这张表上面测试,看看需要多长时间。如果几分钟,是在可以接受的时间范围内,就可以。如果几个小时就不行了。这样子提早预先知道。 另外,也使用了online-schema-change这个工具。 关于online-schema-change 是percona推出的一个针对MySQL在线ddl的工具 percona是一个MySQL分支维护公司,专门提供MySQL技术服务的。我的理解,类似于linux的分支redhat公司 官网下载地址为: http://www.percona.com/redir/downloads/percona-toolkit/2.2.1/percona-toolkit-2.2.1.tar.gz 腾讯,淘宝,百度这些公司多少都有自己开发的工具来解决这个头痛的问题。 另外,MySQL5.5企业版是支持在线ddl了,不过企业版要收费嘛 MySQL 5.6改进了安全功能,例如对关键配置文件和用户密码的加密方式,但是对InnoDB的提升才是大新闻。使用该存储引擎的最后一个主要障碍便是缺少全文索引,但是现在这个问题已经不复存在了。 该版本还为InnoDB引入了在线DDL,DBA一定会非常喜欢这个功能。增加、重命名和删除列等常用的操作可以和并发查询同时执行。尽管可能涉及到一些数据的复制或重组,但是大多数在线DDL操作都能够就地执行。
java import cert keytool -importcert -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -file /path/to/ca.der -alias "digicertglobalrootca" # storepass 默认值changeit keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit | grep digicertglobalrootca
Git HEAD 当你提交（commit）新更改时，HEAD 会随着分支一起移动到新的提交。 当你切换分支（比如用 git checkout 或 git switch），HEAD 会改变指向，指向你切换到的分支。 这个 HEAD 随你切换分支而变化，始终指向你“当前所在”的分支或 commit。 你在 main 分支，HEAD 内容是 ref: refs/heads/main 你切换到 dev 分支，HEAD 变为 ref: refs/heads/dev 你 checkout 某个历史 commit，HEAD 内容是该 commit 的 SHA（分离 HEAD 状态） # 正常情况下(attached HEAD)，HEAD 是一个符号引用，指向当前分支 # 本地 HEAD 通常指向分支，而不是直接指向提交 cat .git/HEAD # 输出：ref: refs/heads/main # 1. HEAD 指向 main 分支 # 2. main 分支指向它的最新提交 # 3. HEAD 通过分支间接指向最新提交 # HEAD -> 分支 -> 最新提交 # HEAD → refs/heads/main → commit_abc123 # 查看 HEAD 指向的分支 git symbolic-ref HEAD # 输出：refs/heads/main # 查看 HEAD 最终指向的提交 git rev-parse HEAD # 输出：abc123...（提交SHA） git rev-parse HEAD # 获取当前HEAD指向的提交SHA git rev-parse main # 获取main分支的最新提交SHA cat .git/refs/heads/main # 直接查看分支文件内容（提交SHA） detached HEAD # 当检出具体 commit 时，HEAD 直接指向提交 git switch --detach commit_abc123 cat .git/HEAD # 输出：commit_abc123...（直接是提交SHA，不是 ref: 开头） # 此时 HEAD 直接指向提交，不通过分支 HEAD 的作用是告诉 Git “我现在在哪里工作” ...