标签：参考 条目 lock vfs type 步骤 root csdn 顺序
cgroup还有其他一些限制特性，如io，pid，hugetlb等，这些用处不多，参见Cgroupv1。下面介绍下与系统性能相关的io和hugepage，cgroup的io介绍参考Cgroup - Linux的IO资源隔离
linux IO
linux io涉及到对文件(磁盘设备)的读写性能，对io的优化主要分为
使用如下命令查看当前系统支持的调度器
# dmesg | grep -i scheduler [ 1.343756] io scheduler noop registered [ 1.343759] io scheduler deadline registered (default) [ 1.343784] io scheduler cfq registered [ 1.343787] io scheduler mq-deadline registered [ 1.343789] io scheduler kyber registered
使用如下命令查看当前磁盘支持的调度器，方括号表示当前生效的调度器
# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
调度器的参数位于/sys/block/sda/queue/iosched/
Noop：该算法实现了最简单的FIFO队列，所有I/O请求大致按照先来后到的顺序进行操作，特别适用于固态硬盘
CFQ：给所有进程分配等同的块设备使用的时间片，进程在时间片内，可以将产生的IO请求提交给块设备进行处理，时间片结束，进程的请求将排进它自己的队列，等待下次调度的时候进行处理，适用于通用服务器。
Deadline：保证每个IO请求在一定的时间内一定要被服务到，以此来避免某个请求饥饿，deadline在大多数多线程应用场景和数据库应用场景下表现的性能要优于cfq
可以通过直接修改/sys/block/sda/queue/scheduler文件来临时修改调度器类型，永久修改可以参考如下命令
grubby --grub --update-kernel=ALL --args="elevator=deadline"
在遇到系统读写过慢时，可以采用如下步骤进行定位。（注：该系统的模拟故障由dd if=/dev/zero of=loadfile bs=1M count=5000触发）：
Tasks: 77 total, 2 running, 75 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.7 us, 14.6 sy, 0.0 ni, 0.0 id, 84.7 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 1014908 total, 63716 free, 69912 used, 881280 buff/cache KiB Swap: 0 total, 0 free, 0 used. 779008 avail Mem
util：采集周期内用于IO操作的时间比率，该值过高直接说明IO占比过高，下面util已经升到了97.19%，IO已经很高了
await：平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)，该值过高说明IO队列可能比较长，IO队列长度可以参考avgqu-sz(平均等待处理的IO请求队列长度)
svctm：平均每次IO请求的处理时间(毫秒为单位)，正常情况下该值与await相差不大，差距越大，越说明IO过高。
IO有读写之分，如下例中明显写操作IO影响了性能，且设备为磁盘sda
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 1.04 227.08 4.17 108850.00 954.34 124.40 1056.26 87.00 1060.71 4.26 97.19
Total DISK READ : 0.00 B/s | Total DISK WRITE : 403.22 M/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 411.90 M/s PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 15162 be/4 root 0.00 B/s 403.22 M/s 0.00 % 80.05 % dd if=/dev/zero... ...
使用lsof查看该进程打开的文件，可以看到/home/loadfile的大小达到了4564156416
# lsof -p 15394 lsof: WARNING: can‘t stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dd 15394 root cwd DIR 253,0 63 50444361 /home dd 15394 root rtd DIR 253,0 238 64 / dd 15394 root txt REG 253,0 74952 50454589 /usr/bin/dd dd 15394 root mem REG 253,0 106075056 17088179 /usr/lib/locale/locale-archive dd 15394 root mem REG 253,0 2151672 162056 /usr/lib64/libc-2.17.so dd 15394 root mem REG 253,0 163400 162049 /usr/lib64/ld-2.17.so dd 15394 root 0r CHR 1,5 0t0 6479 /dev/zero dd 15394 root 1w REG 253,0 4564156416 52606435 /home/loadfile dd 15394 root 2u CHR 136,0 0t0 3 /dev/pts/0
确定/home/loadfile文件的挂载路径，为根路径
# df /home/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/centos-root 17811456 10109916 7701540 57% /
查看根路径挂载的磁盘(本例中为一块磁盘，可以忽略该步骤)，为发生IO性能问题的磁盘sda，到此基本可以确认是因为进程15162引发了IO问题。注：可以使用如“time dd if=/dev/zero bs=1M count=2048 of=direct_2G”命令测试磁盘性能
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 20G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 19G 0 part ├─centos-root 253:0 0 17G 0 lvm / └─centos-swap 253:1 0 2G 0 lvm [SWAP]
linux 大页
Linux采用了通用的分页模型，用以减少进程使用的页表以及增加对内存的索引。在Linux-2.6.10版本中, Linux采用了三级分页模型. 而从2.6.11开始普遍采用了四级分页模型，32位系统中取消了PUD和PMD，为二级分页模型。注：每个进程都有其自身的页面目录PGD
下面是一个线性地址包含的个字段以及个字段的用途
注：CR3中含有页目录表物理内存基地址，因此该寄存器也被称为页目录基地址寄存器PDBR（Page-Directory Base address Register），用于定位进程PGD
对于32位系统来说，如果采用4K的分页大小，每个PGD含1024个目录，每个目录含1024个PT，每个PT可寻址4K物理内存，总计4G。从上述可以看出，当进程需要访问实际物理内存时需要经过多级页才行，为了增加地址访问效率，linux使用了一种页缓存，TLB(translation lookaside buffer)。当需要访问物理地址时会首先从TLB中寻找，若找到则称为TLB hit，否则称为TLB miss。
这篇文章描述了使用系统默认4k分页下出现的性能问题，总结下来就是：64位系统下，一个进程访问的内存空间变大时，其PGD里面的页表项也会变大，如一个进程访问一个12G内存时，其页表需要24M，当300个进程同时需要访问这12G内存时，总的页表达到了7200MB，这么大的页表不仅占用大量内存空间，页增加了地址访问的负担(TLB miss也会大大增加)。解决办法是使用大页内存，通过增加单个分页大小，进而减少总体需要的分页的数目(同时也提升了TLB hit的几率)
可以看出，大页内存一般用于64位系统或32位系统启用了PAE(内存地址扩展)的情况。页表的使用情况可以参见/proc/meminfo中的PageTables字段
下面描述来自这里
典型地，内存管理器在 x86 系统上处理的内存页为 4 KB。实际的页大小是与体系结构相关的。对大部分用途来说，内存管理器以这样大小的页来管理内存是最有效的。不过，有一些应用程序要使用特别多的内存。大型数据库就是其中一个常见的例子。由于每个页都要由每个进程映射，必须创建页表条目来将虚拟地址映射到物理地址。如果您的一个进程要使用 4KB 的页来映射 1 GB 内存，这将用到 262,144 个页表条目来保持对那些页的追踪。如果每个页表条目消耗 8 个字节，那些每映射 1 GB 内存需要 2 MB 的开销。这本身就已经是非常可观的开销了，不过，如果有多个进程共享那些内存时，问题会变得更严重。在这种情况下，每个映射到同一块 1 GB 内存的进程将为页表条目付出自己 2 MB 的代价。如果有足够多的进程，内存在开销上的浪费可能会超过应用程序请求使用的内存数量。
解决这一问题的一个方法是使用更大的页。大部分新的处理器都支持至少一个小的和一个大的内存页大小。在 x86 上，大内存页的大小是 4 MB，或者，在物理地址扩展（PAE）打开的系统上是 2 MB。假定在前面的中使用页大小为 4 MB 的大内存页，同样 1 GB 内存只用 256 个页表条目就可以映射，而不需要 262,144 个。这样开销从 2 MB 变为 2,048 个字节。
大内存页的使用还可以通过减少 变换索引缓冲（translation lookaside buffer, TLB）的失败次数来提高性能。TLB 是一种页表的高速缓存，让那些在表中列出的页可以更快地进行虚拟地址到物理地址的转换。大内存页可以用更少的实际页来提供更多的内存，相当于较小的页大小，使用的大内存页越多，就有越多的内存可以通过 TLB 引用。
TIPS：
参考：
https://blog.csdn.net/gzh0222/article/details/8666657
https://www.ibm.com/developerworks/cn/linux/l-lo-io-scheduler-optimize-performance/index.html
https://zorro.gitbooks.io/poor-zorro-s-linux-book/content/linuxde-io-diao-du.html
http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/
https://www.ibm.com/developerworks/cn/linux/l-memmod/index.html
https://www.ibm.com/developerworks/cn/linux/l-cn-hugetlb/
https://github.com/gatieme/LDD-LinuxDeviceDrivers/blob/master/study/kernel/02-memory/02-pagetable/01-develop/README.md
标签：参考 条目 lock vfs type 步骤 root csdn 顺序
原文地址：https://www.cnblogs.com/charlieroro/p/10290310.html
