linux服务器的平均负载问题

如果是web服务器，用到程序与数据库交互的服务器，您报出的硬件配置，负载6以内可以稳定运行，负载12以内可以正常运行，负载高于15运行吃力，负载18以上明显感觉变慢，更高可能就运行出错了。我指的是一般情况下。

如果是特殊情况，内部机制导致的服务宕机假死，那么负载值的呈现可能不高的，但是有问题的服务已经不能正常工作了，需要重启这个服务，一旦重启这个假死的服务进程，系统负载就会立刻随之升高，因为可能随着重启这个服务进程之后，服务突然能响应了堆积的并发请求，导致突发性升高，然后可能迅速降低负载。 所以负载是表示系统的综合运行载荷，不完全是cpu的占用率。 在linux系统里，几种情况都可以导致负载高：1.系统进程占用时间过长 2.应用程序的进程占用cpu时间过长 3.磁盘读写I/O的进程占用cpu的时间过长。 是否稳定运行，不能单单以负载值作为评估标准，只能作为大概的参考。负载高的原因要从我之前说的3个原因方面去查，查到了问题后，就可以改进改善，从而实现稳定运行。

其实有很多特例的，据我所知，某些大型的知名网站服务器原来采用lamp架构的，在负载100以上都能正常运行，这么高的负载其实在某些情况下特别是大规模并发情况下，只要把控好软硬件的协作关系，照样可以正常运作。

我从事linux网站运维数年了，希望我的回答你能满意。

在linux系统里面，常见的有两个地方可以看到当前系统的最近平均负载，top命令和uptime，如果执行一下uptime命令的话，可以看到有一个load average，表示最近1分钟，5分钟，15分钟的系统负载。

# uptime

23:31:04 up 5 days, 10:20, 1 user, load average: 0.00, 0.01, 0.05

一般单核的CPU的话，负载到1证明系统已经运行比较满了，多核的话，有几个核就能到几。

但是，有没有仔细想过，这个负载值究竟可以有多高？

我们先用一个程序做下实验

等这个程序运行一会，再执行uptime看下负载

# uptime

23:44:53 up 5 days, 10:33, 2 users, load average: 16383.13, 14111.52, 7705.88

看到没，这个程序竟然把load神奇的刷到了16000这个级别，真是厉害，这个一下子似乎打破了对系统负载的认识。

原理是这样的，通过调用vfork产生指定数量的D状态的进程，从而提高负载。看看系统文档，是这样说的

vfork() differs from fork(2) in that the calling thread is suspended until the child terminates (either normally, by calling _exit(2), or abnormally, after delivery of a fatal signal), or it makes a call to execve(2). Untilthat point, the child shares all memory with its parent, including the stack.

vfork 的子进程只要不 execve 或者退出，父进程就一直挂着(在D状态）。这里就是让最后一个子进程用 scanf 等输入。

但是这个就是极限了吗？

程序员在这种事情上是不会停止追求的，下来再看一个终极版本的程序

执行一下

# stap -g loadavg.stp $(((1

看下效果

# uptime

23:48:19 up 5 days, 10:37, 2 users, load average: 9007199254740991.00, 14987.03, 9007199254740991.00

我天，这是要爆表了，终极load，系统要炸了吗？

不过，你知道其中的原理吗，vfork相当于还是利用了系统计算load的原理，通过增加D状态进程影响计算，这个终极版，则是直接修改计算过程中用到的参数，让系统算出一个极大值来，没有什么能够超越这个了。

刷新频率。linux出现超出范围调整1440这种问题一般是因为设置的刷新频率超出了显示器的频率范围，修改显示器刷新频率即可解决。Linux，全称GNULinux，是一种免费使用和自由传播的类UNIX *** 作系统。

---