
一、前提
我们可以在文章的开始就列出一个列表,列出可能影响Linux *** 作系统性能的一些调优参数,但这样做其实并没有什么价值。因为性能调优是一个非常困难的任务,它要求对硬件、 *** 作系统、和应用都有着相当深入的了解。如果性能调优非常简单的话,那些我们要列出的调优参数早就写入硬件的微码或者 *** 作系统中了,我们就没有必要再继续读这篇文章了。正如下图所示,服务器的性能受到很多因素的影响。
当面对一个使用单独IDE硬盘的,有20000用户的数据库服务器时,即使我们使用数周时间去调整I/O子系统也是徒劳无功的,通常一个新的驱动或者应用程序的一个更新(如SQL优化)却可以使这个服务器的性能得到明显的提升。正如我们前面提到的,不要忘记系统的性能是受多方面因素影响的。理解 *** 作系统管理系统资源的方法将帮助我们在面对问题时更好的判断应该对哪个子系统进行调整。
二、Linux的CPU调度
任何计算机的基本功能都十分简单,那就是计算。为了实现计算的功能就必须有一个方法去管理计算资源、处理器和计算任务(也被叫做线程或者进程)。非常感谢Ingo Molnar,他为Linux内核带来了O(1)CPU调度器,区别于旧有的O(n)调度器,新的调度器是动态的,可以支持负载均衡,并以恒定的速度进行 *** 作。
新调度器的可扩展性非常好,无论进程数量或者处理器数量,并且调度器本身的系统开销更少。新调取器的算法使用两个优先级队列。
引用
・活动运行队列
・过期运行队列
调度器的一个重要目标是根据优先级权限有效地为进程分配CPU 时间片,当分配完成后它被列在CPU的运行队列中,除了 CPU 的运行队列之外,还有一个过期运行队列。当活动运行队列中的一个任务用光自己的时间片之后,它就被移动到过期运行队列中。在移动过程中,会对其时间片重新进行计算。如果活动运行队列中已经没有某个给定优先级的任务了,那么指向活动运行队列和过期运行队列的指针就会交换,这样就可以让过期优先级列表变成活动优先级的列表。通常交互式进程(相对与实时进程而言)都有一个较高的优先级,它占有更长的时间片,比低优先级的进程获得更多的计算时间,但通过调度器自身的调整并不会使低优先级的进程完全被饿死。新调度器的优势是显著的改变Linux内核的可扩展性,使新内核可以更好的处理一些有大量进程、大量处理器组成的企业级应用。新的O(1)调度器包含仔2.6内核中,但是也向下兼容2.4内核。
新调度器另外一个重要的优势是体现在对NUMA(non-uniform memory architecture)和SMP(symmetric multithreading processors)的支持上,例如INTEL@的超线程技术。
改进的NUMA支持保证了负载均衡不会发生在CECs或者NUMA节点之间,除非发生一个节点的超出负载限度。
三、Linux的内存架构
今天我们面对选择32位 *** 作系统还是64位 *** 作系统的情况。对企业级用户它们之间最大的区别是64位 *** 作系统可以支持大于4GB的内存寻址。从性能角度来讲,我们需要了解32位和64位 *** 作系统都是如何进行物理内存和虚拟内存的映射的。
在上面图示中我们可以看到64位和32位Linux内核在寻址上有着显著的不同。
在32位架构中,比如IA-32,Linux内核可以直接寻址的范围只有物理内存的第一个GB(如果去掉保留部分还剩下896MB),访问内存必须被映射到这小于1GB的所谓ZONE_NORMAL空间中,这个 *** 作是由应用程序完成的。但是分配在ZONE_HIGHMEM中的内存页将导致性能的降低。
在另一方面,64位架构比如x86-64(也称作EM64T或者AMD64)。ZONE_NORMAL空间将扩展到64GB或者128GB(实际上可以更多,但是这个数值受到 *** 作系统本身支持内存容量的限制)。正如我们看到的,使用64位 *** 作系统我们排除了因ZONE_HIGHMEM部分内存对性能的影响的情况。
实际中,在32位架构下,由于上面所描述的内存寻址问题,对于大内存,高负载应用,会导致死机或严重缓慢等问题。虽然使用hugemen核心可缓解,但采取x86_64架构是最佳的解决办法。
四、虚拟内存管理
因为 *** 作系统将内存都映射为虚拟内存,所以 *** 作系统的物理内存结构对用户和应用来说通常都是不可见的。如果想要理解Linux系统内存的调优,我们必须了解Linux的虚拟内存机制。应用程序并不分配物理内存,而是向Linux内核请求一部分映射为虚拟内存的内存空间。如下图所示虚拟内存并不一定是映射物理内存中的空间,如果应用程序有一个大容量的请求,也可能会被映射到在磁盘子系统中的swap空间中。
另外要提到的是,通常应用程序不直接将数据写到磁盘子系统中,而是写入缓存和缓冲区中。Bdflush守护进程将定时将缓存或者缓冲区中的数据写到硬盘上。
Linux内核处理数据写入磁盘子系统和管理磁盘缓存是紧密联系在一起的。相对于其他的 *** 作系统都是在内存中分配指定的一部分作为磁盘缓存,Linux处理内存更加有效,默认情况下虚拟内存管理器分配所有可用内存空间作为磁盘缓存,这就是为什么有时我们观察一个配置有数G内存的Linux系统可用内存只有20MB的原因。
同时Linux使用swap空间的机制也是相当高效率的,如上图所示虚拟内存空间是由物理内存和磁盘子系统中的swap空间共同组成的。如果虚拟内存管理器发现一个已经分配完成的内存分页已经长时间没有被调用,它将把这部分内存分页移到swap空间中。经常我们会发现一些守护进程,比如getty,会随系统启动但是却很少会被应用到。这时为了释放昂贵的主内存资源,系统会将这部分内存分页移动到swap空间中。上述就是Linux使用swap空间的机制,当swap分区使用超过50%时,并不意味着物理内存的使用已经达到瓶颈了,swap空间只是Linux内核更好的使用系统资源的一种方法。
简单理解:Swap usage只表示了Linux管理内存的有效性。对识别内存瓶颈来说,Swap In/Out才是一个比较又意义的依据,如果Swap In/Out的值长期保持在每秒200到300个页面通常就表示系统可能存在内存的瓶颈。下面的事例是好的状态:
引用
# vmstat
procs ———–memory————- —swap– —–io—- –system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 5696 6904 28192 50496 0 0 88 117 61 29 11 8 80 1
五、模块化的I/O调度器
就象我们知道的Linux2.6内核为我们带来了很多新的特性,这其中就包括了新的I/O调度机制。旧的2.4内核使用一个单一的I/O调度器,2.6 内核为我们提供了四个可选择的I/O调度器。因为Linux系统应用在很广阔的范围里,不同的应用对I/O设备和负载的要求都不相同,例如一个笔记本电脑和一个10000用户的数据库服务器对I/O的要求肯定有着很大的区别。
引用
(1).Anticipatory
anticipatory I/O调度器创建假设一个块设备只有一个物理的查找磁头(例如一个单独的SATA硬盘),正如anticipatory调度器名字一样,anticipatory调度器使用“anticipatory”的算法写入硬盘一个比较大的数据流代替写入多个随机的小的数据流,这样有可能导致写 I/O *** 作的一些延时。这个调度器适用于通常的一些应用,比如大部分的个人电脑。
(2).Complete Fair Queuing (CFQ)
Complete Fair Queuing(CFQ)调度器是Red Flag DC Server 5使用的标准算法。CFQ调度器使用QoS策略为系统内的所有任务分配相同的带宽。CFQ调度器适用于有大量计算进程的多用户系统。它试图避免进程被饿死和实现了比较低的延迟。
(3).Deadline
deadline调度器是使用deadline算法的轮询的调度器,提供对I/O子系统接近实时的 *** 作,deadline调度器提供了很小的延迟和维持一个很好的磁盘吞吐量。如果使用deadline算法请确保进程资源分配不会出现问题。
(4).NOOP
NOOP调度器是一个简化的调度程序它只作最基本的合并与排序。与桌面系统的关系不是很大,主要用在一些特殊的软件与硬件环境下,这些软件与硬件一般都拥有自己的调度机制对内核支持的要求很小,这很适合一些嵌入式系统环境。作为桌面用户我们一般不会选择它。
六、网络子系统
新的网络中断缓和(NAPI)对网络子系统带来了改变,提高了大流量网络的性能。Linux内核在处理网络堆栈时,相比降低系统占用率和高吞吐量更关注可靠性和低延迟。所以在某些情况下,Linux建立一个防火墙或者文件、打印、数据库等企业级应用的性能可能会低于相同配置的Windows服务器。
在传统的处理网络封包的方式中,如下图蓝色箭头所描述的,一个以太网封包到达网卡接口后,如果MAC地址相符合会被送到网卡的缓冲区中。网卡然后将封包移到 *** 作系统内核的网络缓冲区中并且对CPU发出一个硬中断,CPU会处理这个封包到相应的网络堆栈中,可能是一个TCP端口或者Apache应用中。
这是一个处理网络封包的简单的流程,但从中我们可以看到这个处理方式的缺点。正如我们看到的,每次适合网络封包到达网络接口都将对CPU发出一个硬中断信号,中断CPU正在处理的其他任务,导致切换动作和对CPU缓存的 *** 作。你可能认为当只有少量的网络封包到达网卡的情况下这并不是个问题,但是千兆网络和现代的应用将带来每秒钟成千上万的网络数据,这就有可能对性能造成不良的影响。
正是因为这个情况,NAPI在处理网络通讯的时候引入了计数机制。对第一个封包,NAPI以传统的方式进行处理,但是对后面的封包,网卡引入了POLL 的轮询机制:如果一个封包在网卡DMA环的缓存中,就不再为这个封包申请新的中断,直到最后一个封包被处理或者缓冲区被耗尽。这样就有效的减少了因为过多的中断CPU对系统性能的影响。同时,NAPI通过创建可以被多处理器执行的软中断改善了系统的可扩展性。NAPI将为大量的企业级多处理器平台带来帮助,它要求一个启用NAPI的驱动程序。在今天很多驱动程序默认没有启用NAPI,这就为我们调优网络子系统的性能提供了更广阔的空间。
七、理解Linux调优参数
因为Linux是一个开源 *** 作系统,所以又大量可用的性能监测工具。对这些工具的选择取决于你的个人喜好和对数据细节的要求。所有的性能监测工具都是按照同样的规则来工作的,所以无论你使用哪种监测工具都需要理解这些参数。下面列出了一些重要的参数,有效的理解它们是很有用处的。
(1)处理器参数
引用
・CPU utilization
这是一个很简单的参数,它直观的描述了每个CPU的利用率。在xSeries架构中,如果CPU的利用率长时间的超过80%,就可能是出现了处理器的瓶颈。
・Runable processes
这个值描述了正在准备被执行的进程,在一个持续时间里这个值不应该超过物理CPU数量的10倍,否则CPU方面就可能存在瓶颈。
・Blocked
描述了那些因为等待I/O *** 作结束而不能被执行的进程,Blocked可能指出你正面临I/O瓶颈。
・User time
描述了处理用户进程的百分比,包括nice time。如果User time的值很高,说明系统性能用在处理实际的工作。
・System time
描述了CPU花费在处理内核 *** 作包括IRQ和软件中断上面的百分比。如果system time很高说明系统可能存在网络或者驱动堆栈方面的瓶颈。一个系统通常只花费很少的时间去处理内核的 *** 作。
・Idle time
描述了CPU空闲的百分比。
・Nice time
描述了CPU花费在处理re-nicing进程的百分比。
・Context switch
系统中线程之间进行交换的数量。
・Waiting
CPU花费在等待I/O *** 作上的总时间,与blocked相似,一个系统不应该花费太多的时间在等待I/O *** 作上,否则你应该进一步检测I/O子系统是否存在瓶颈。
・Interrupts
Interrupts 值包括硬Interrupts和软Interrupts,硬Interrupts会对系统性能带来更多的不利影响。高的Interrupts值指出系统可能存在一个软件的瓶颈,可能是内核或者驱动程序。注意Interrupts值中包括CPU时钟导致的中断(现代的xServer系统每秒1000个 Interrupts值)。
(2)内存参数
引用
・Free memory
相比其他 *** 作系统,Linux空闲内存的值不应该做为一个性能参考的重要指标,因为就像我们之前提到过的,Linux内核会分配大量没有被使用的内存作为文件系统的缓存,所以这个值通常都比较小。
・Swap usage
这 个值描述了已经被使用的swap空间。Swap usage只表示了Linux管理内存的有效性。对识别内存瓶颈来说,Swap In/Out才是一个比较又意义的依据,如果Swap In/Out的值长期保持在每秒200到300个页面通常就表示系统可能存在内存的瓶颈。
・Buffer and cache
这个值描述了为文件系统和块设备分配的缓存。在Red Flag DC Server 5版本中,你可以通过修改/proc/sys/vm中的page_cache_tuning来调整空闲内存中作为缓存的数量。
・Slabs
描述了内核使用的内存空间,注意内核的页面是不能被交换到磁盘上的。
・Active versus inactive memory
提供了关于系统内存的active内存信息,Inactive内存是被kswapd守护进程交换到磁盘上的空间。
(3)网络参数
引用
・Packets received and sent
这个参数表示了一个指定网卡接收和发送的数据包的数量。
・Bytes received and sent
这个参数表示了一个指定网卡接收和发送的数据包的字节数。
・Collisions per second
这个值提供了发生在指定网卡上的网络冲突的数量。持续的出现这个值代表在网络架构上出现了瓶颈,而不是在服务器端出现的问题。在正常配置的网络中冲突是非常少见的,除非用户的网络环境都是由hub组成。
・Packets dropped
这个值表示了被内核丢掉的数据包数量,可能是因为防火墙或者是网络缓存的缺乏。
・Overruns
Overruns表达了超出网络接口缓存的次数,这个参数应该和packets dropped值联系到一起来判断是否存在在网络缓存或者网络队列过长方面的瓶颈。
・Errors 这个值记录了标志为失败的帧的数量。这个可能由错误的网络配置或者部分网线损坏导致,在铜口千兆以太网环境中部分网线的损害是影响性能的一个重要因素。
(4)块设备参数
引用
・Iowait
CPU等待I/O *** 作所花费的时间。这个值持续很高通常可能是I/O瓶颈所导致的。
・Average queue length
I/O请求的数量,通常一个磁盘队列值为2到3为最佳情况,更高的值说明系统可能存在I/O瓶颈。
・Average wait
响应一个I/O *** 作的平均时间。Average wait包括实际I/O *** 作的时间和在I/O队列里等待的时间。
・Transfers per second
描述每秒执行多少次I/O *** 作(包括读和写)。Transfers per second的值与kBytes per second结合起来可以帮助你估计系统的平均传输块大小,这个传输块大小通常和磁盘子系统的条带化大小相符合可以获得最好的性能。
・Blocks read/write per second
这个值表达了每秒读写的blocks数量,在2.6内核中blocks是1024bytes,在早些的内核版本中blocks可以是不同的大小,从512bytes到4kb。
・Kilobytes per second read/write
按照kb为单位表示读写块设备的实际数据的数量。
linux查看磁盘io的几种方法怎样才能快速的定位到并发高是由于磁盘io开销大呢?可以通过三种方式: 第一种:用 top 命令 中的cpu 信息观察 Top可以看到的cpu信息有: Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si 具体的解释如下: Tasks: 29 total 进程总数 1 running 正在运行的进程数 28 sleeping 睡眠的进程数 0 stopped 停止的进程数 0 zombie 僵尸进程数 Cpu(s): 0.3% us 用户空间占用CPU百分比 1.0% sy 内核空间占用CPU百分比 0.0% ni 用户进程空间内改变过优先级的进程占用CPU百分比 98.7% id 空闲CPU百分比 0.0% wa 等待输入输出的CPU时间百分比 0.0% hi 0.0% si 0.0% wa 的百分比可以大致的体现出当前的磁盘io请求是否频繁。如果 wa的数量比较大,说明等待输入输出的的io比较多。 第二种:用vmstat vmstat 命令报告关于线程、虚拟内存、磁盘、陷阱和 CPU 活动的统计信息。由 vmstat 命令生成的报告可以用于平衡系统负载活动。系统范围内的这些统计信息(所有的处理器中)都计算出以百分比表示的平均值,或者计算其总和。 输入命令: vmstat 2 5 如果发现等待的进程和处在非中断睡眠状态的进程数非常多,并且发送到块设备的块数和从块设备接收到的块数非常大,那就说明磁盘io比较多。 vmstat参数解释: Procs r: 等待运行的进程数 b: 处在非中断睡眠状态的进程数 w: 被交换出去的可运行的进程数。此数由 linux 计算得出,但 linux 并不耗尽交换空间 Memory swpd: 虚拟内存使用情况,单位:KB free: 空闲的内存,单位KB buff: 被用来做为缓存的内存数,单位:KB Swap si: 从磁盘交换到内存的交换页数量,单位:KB/秒 so: 从内存交换到磁盘的交换页数量,单位:KB/秒 IO bi: 发送到块设备的块数,单位:块/秒 bo: 从块设备接收到的块数,单位:块/秒 System in: 每秒的中断数,包括时钟中断 cs: 每秒的环境(上下文)切换次数 CPU 按 CPU 的总使用百分比来显示 us: CPU 使用时间 sy: CPU 系统使用时间 id: 闲置时间 准测 更多vmstat使用信息 第二种:用iostat 安装: Iostat 是 sysstat 工具集的一个工具,需要安装。 Centos的安装方式是: yum install sysstat Ubuntu的安装方式是: aptitude install sysstat 使用: iostat -dx 显示磁盘扩展信息 root@fileapp:~# iostat -dx r/s 和 w/s 分别是每秒的读 *** 作和写 *** 作,而rKB/s 和wKB/s 列以每秒千字节为单位显示了读和写的数据量 如果这两对数据值都很高的话说明磁盘io *** 作是很频繁。+++++++++++++++++++++++++++++++++++++ linux wa%过高,iostat查看io状况 1, 安装 iostat yum install sysstat 之后就可以使用 iostat 命令了, 2,入门使用 iostat -d -k 2 参数 -d 表示,显示设备(磁盘)使用状态;-k某些使用block为单位的列强制使用Kilobytes为单位;2表示,数据显示每隔2秒刷新一次。tps:该设备每秒的传输次数(Indicate the number of transfers per second that were issued to the device.)。"一次传输"意思是"一次I/O请求"。多个逻辑请求可能会被合并为"一次I/O请求"。"一次传输"请求的大小是未知的。kB_read/s:每秒从设备(drive expressed)读取的数据量; kB_wrtn/s:每秒向设备(drive expressed)写入的数据量; kB_read:读取的总数据量;kB_wrtn:写入的总数量数据量;这些单位都为Kilobytes。 指定监控的设备名称为sda,该命令的输出结果和上面命令完全相同。iostat -d sda 2 默认监控所有的硬盘设备,现在指定只监控sda。 3, -x 参数iostat还有一个比较常用的选项 -x ,该选项将用于显示和io相关的扩展数据。 iostat -d -x -k 1 10 输出信息的含义。4, 常见用法iostat -d -k 1 10 #查看TPS和吞吐量信息(磁盘读写速度单位为KB) iostat -d -m 2 #查看TPS和吞吐量信息(磁盘读写速度单位为MB) iostat -d -x -k 1 10 #查看设备使用率(%util)、响应时间(await) iostat -c 1 10 #查看cpu状态5, 实例分析 iostat -d -k 1 | grep vda Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda10 60.72 18.95 71.53 395637647 1493241908 sda10 299.02 4266.67 129.41 4352 132 sda10 483.84 4589.90 4117.17 4544 4076 sda10 218.00 3360.00 100.00 3360 100 sda10 546.00 8784.00 124.00 8784 124 sda10 827.00 13232.00 136.00 13232 136上面看到,磁盘每秒传输次数平均约400;每秒磁盘读取约5MB,写入约1MB。iostat -d -x -k 1 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 1.56 28.31 7.84 31.50 43.65 3.16 21.82 1.58 1.19 0.03 0.80 2.61 10.29 sda 1.98 24.75 419.80 6.93 13465.35 253.47 6732.67 126.73 32.15 2.00 4.70 2.00 85.25 sda 3.06 41.84 444.90 54.08 14204.08 2048.98 7102.04 1024.49 32.57 2.10 4.21 1.85 92.24 可以看到磁盘的平均响应时间<5ms,磁盘使用率>80。磁盘响应正常,但是已经很繁忙了。可以看到磁盘的平均响应时间<5ms,磁盘使用率>90。磁盘响应正常,但是已经很繁忙了。await: 每一个IO请求的处理的平均时间(单位是微秒毫秒)。这里可以理解为IO的响应时间,一般地系统IO响应时间应该低于5ms,如果大于10ms就比较大了 svctm 表示平均每次设备I/O *** 作的服务时间(以毫秒为单位)。如果svctm的值与await很接近,表示几乎没有I/O等待,磁盘性能很好, 如果await的值远高于svctm的值,则表示I/O队列等待太长, 系统上运行的应用程序将变慢。 %util: 在统计时间内所有处理IO时间,除以总共统计时间 所以该参数暗示了设备的繁忙程度 。一般地,如果该参数是100%表示设备已经接近满负荷运行了(当然如果是多磁盘,即使%util是100%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。 也可以使用下面的命令,同时显示cpu和磁盘的使用情况 等待时间超过5ms, 磁盘io有问题欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)