Linux单主机的负载

数据处理：计算机从磁盘（硬盘）上读出数据并存储到内存上，然后CPU会从内存上取得数据进行处理。而且，从内存上取得的指令会缓存到更高速的CPU缓存中。所以，数据处理要经过磁盘T内存T缓存-CPU多层才能被处理。横向扩展（scaleout）：通过增加服务器数量来提高系统整体的处理能力并分担负载。纵向扩展（scaleup）：通过提高硬件性能来提高处理能力的方法。系统负载情况处理：对于I/O负载较高的服务器扩展其内存对于CPU负载高的服务器升级其CPU。开发所用的工具：编程语言Perl、C/C++、JavaScript等。主要中间件：MySQL、SQLsever等。Web应用程序的框架默认的aspx框架。大规模数据处理的难点：内存和磁盘当大规模数据处理时，会遇到“无法在内存中计算”的问题。导致数据“无法在内存中计算”的原因是因为数据如果在内存中放不下的话，通常就得一直读磁盘，在磁盘中找啊找还是找不到。数据量过大时，其输入数据量也就增大，计算量当然也会增大，更严重问题是“需要读取磁盘”。（但磁盘是十分缓慢的，I/O会耗费很多时间，导致系统过慢。）内存和磁盘的速度差异：内存比磁盘要快1000W倍！！（简单了解磁盘和内存搜索数据的原理就知道）Linux单主机的负载寻找瓶颈的基本流程：1•查看平均负载（Loadaverage）o2.确认CPU、I/O有无瓶颈。査看平均负载（Loadaverage）方法：命令：top\uptime。平均负载是指示系统全体负载状况的指标。平均负载低，吞吐量也低的情况下，应该先检查软件设置是否异常，检查网络和远程主机是否存在故障等。（吞吐量：每秒的数据处理量。是在给定时间段内系统完成的交易数量。即系统的吞吐量越大，说明系统在单位时间内完成的用户或系统请求越多，系统的资源得到充分利用。）査找CPU和I/O的瓶颈方法：当平均负载过高时，要要CPU或I/O中寻找原因osar或vmstat可以查看CPU使用率和I/O等待率随着时间的推移情况，可以作为参考。•“CPU负载”过高时，用以下流程寻找原因：1•确认是用户程序处理的瓶颈，还是系统程序的原因。用top或sar确认。Top的输出结果中包含名为“loadaverage”的数字。Loadaverage:0.70,0.66,0.59平均负载从左到右分别为1分钟、5分钟、15分钟内，单位时间中处于等待状态的任务。（也就是说，此数字报告了平均有多少任务在等待，平均负载高，说明有相应数量的任务在等待，可以认为运行有延迟，也就是负载过高。）再通过ps查看可见进程的状态和CPU使用时间等，确认导致问题的进程。确定进程之后，想要进一步寻找原因的话，可以通过strace跟踪，或oprofile进行剖测，以确定瓶颈所在。（一般来说，CPU负载是由于以下两者原因之一引起：1•磁盘或内存容量等其他部分没有成为瓶颈，即处于理想状态。2.程序失控，需要消耗过多的CPU。如果是前者并且系统的吞吐量有问题的话，可以采取增加服务器、改善程序逻辑和算法的方式。如果中后者，则要去除故障，避免程序失控。）•“I/O负载”过高时，用以下流程寻找原因：“I/O负载”过高，其原因多半是程序发出的I/O请求过多导致负载过高，或是发生页面交换导致频繁访问磁盘。可以通过sar或vmstat确认交换区状态，找出原因。>根据确认结果，如果是发生页面交换的情况，应该从发下几点着手调查：1•用ps确认是否进程消耗了大量内存。如果由于程序故障造成内存消耗过大，应该改进程序。如果是因为内存安装不足，就要增加内存。无法增加内存时考虑分布式。>根据确认结果，如果是没有交换发生的情况，而且磁盘I/O频繁的情况，可能是用于缓存的内存不足。根据服务器拥有的数据量和可增加的内存量，按照以下步骤选择应对方法：1）如果通过增加内存可以扩大缓存，就增加内存。2）如果增加内存还不够用，就考虑分散存储数据，或是增加缓存服务器等。改进I/O频率也是一种方法。改善I/O性能，需要确认发下几点：能否通过增加内存以保证缓存区域的方法解决。数据量是否本来就过多。有无必要改变应用程序的I/O算法。Web应用程序和负载的关系在Web应用程序中，Web应用程序在进行计算时，也就是接受HTTP请求、查询数据库,再把数据库返回的数据加工变成HTML发送给客户端，基本上应用服务器只消耗CPU。相反,数据库服务器则需要较多I/O资源，产生I/O负载。Web应用程序的三层结构：代理服务器、应用程序服务器、数据库组成。如果在应用程序中只造成CPU负载，只需要增加相同结构的应用程序服务器通过负载均衡就可以了。因为应用程序服务器只消耗CPU资源，不需要分散数据，增加多台服务器作为负载均衡器均匀地分发请求就OK了。但是，如果是I/O负载的问题。只使用增加数据库的方法是不正确的。因为要考虑到两个数据库之间数据同步的问题(例如，写入数据库A中的数据，怎么写的数据库B中呢？写入的分布式是很困难的)。特别是大规模的数据量时就更难。还有，在前面说过，1/0是跟磁盘有关系的。当数据量太大，导致无法在内存处理时，就必然使用到磁盘。如果在两个数据库中进行大量的磁盘读/写操作，就会有大量磁盘I/O的产生。而磁盘的速度是很慢的，计算密集型程序(CPUbound)：有一个执行大规模科学计算的程序，虽然此程序与磁盘无数据I/O,但完成处理需要很长时间，从“执行计算”可得知该程序的处理速度依赖CPU的计算速度。这就是产生CPU负载的程序，也称之为“计算密集型程序“。I/O密集型程序(I/Obound)：假设有一个从保存在磁盘上的大量数据中搜索出任意文档的程序。该搜索程序的处理速度不依赖于CPU，而是依赖于磁盘的读取速度，即I/O。磁盘转速越快，搜索用时就越短。这种给I/O加上负载的程序也称之为“I/O密集型程序“。一般情况下，应用程序服务器从数据库是获取数据，加工后发送给客户端的过程很少产生大规模的I/O。因此，大多数情况下应用程序服务器是计算密集型的服务器。相反，数据库服务器则是I/O密集型程序。通过sar查看CPU使用率和I/O等待率Sar（SystemActivityReporter）：查看系统状况报告的工具。它能列出各个时间点的负载指标以便比较。在计算密集型系统上查看sar执行结果“％user”是CPU在用户模式下的使用率°“％system”是系统模式下的使用率。平均负载过高，且CPU使用率也高的话，就可以判断出进程等待的高负载原因就是CPU资源不足。在sar命令上加上选项-p,可以查看四核CPU（现在Intel架构的CPU都是多核的了，就是指只有一个物理CPU,却能看成是多个CPU）服务器上执行结果。加上输入sar-命令之后分别看到（0、1、2、3、）四个CPUID。以及四个CPU的使用率统计结果（在计算型密集服务器上每个CPU都能够均衡负载）。在I/O密集型服务器上査看sar执行结果：“％iowait”是I/O等待率。平均负载过高并且“％iowait”数值也过高的话，可以认为高负载的原因是I/O。在sar命令上加上选项-p,可以查看四核CPU服务器上的执行结果。结果出乎意料，I/O等待只