必威体育Betway必威体育官网
当前位置:首页 > IT技术

CPU核数和load average的关系

时间:2019-06-02 08:41:05来源:IT技术作者:seo实验室小编阅读:77次「手机版」
 

loadaverage

在前面的文章linux系统监控——top命令》中我简单提到了,判断load average的数值到底大不大的判断依据,就是数值除以cpu核数,大于5,就说明超负荷运转了。——这里其实不太严谨

今天这篇文章来仔细分析分析,CPU和load average的关系。

转载文章一

我们知道判断一个系统的负载可以使用top,uptime等命令去查看,它分别记录了一分钟、五分钟、以及十五分钟的系统平均负载

例如我的某台服务器

这里写图片描述

你可能对于 Linux 的负载均值(load averages)已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到,它们可能会显示成这个样子:

load average: 1.84, 1.34, 0.68

很多人会这样理解负载均值:三个数分别代表不同时间段的系统平均负载(一分钟、五 分钟、以及十五分钟),它们的数字当然是越小越好。数字越高,说明服务器的负载越大,这也可能是服务器出现某种问题的信号。

而事实不完全如此,是什么因素构成了负载均值的大小,以及如何区分它们目前的状况是 “好”还是“糟糕”?什么时候应该注意哪些不正常的数值?

回答这些问题之前,首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明, 一台只配备一块单核处理器的服务器。

行车过桥

一只单核的处理器可以形象得比喻成一条单车道。设想下,你现在需要收取这条道路的过桥费 — 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息,例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待,那么你可以告诉后面的司机通过。 如果车辆众多,那么需要告知他们可能需要稍等一会。

因此,需要些特定的代号表示目前的车流情况,例如:

0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的,总而言之很通畅,过往的车辆可以丝毫不用等待的通过。

1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕,只是车流会有些堵,不过这种情况可能会造成交通越来越慢。

超过 1.00,那么说明这座桥已经超出负荷,交通严重的拥堵。 那么情况有多糟糕? 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍,那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了,说明这座桥基本上已经快承受不了,还有超出桥负载两倍多的车辆正在等待。

上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。

和收过桥费的管理员一样,你当然希望你的汽车(操作)不会被焦急的等待。所以,理想状态 下,都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00,但长此以往保持这 个状态,就说明会有问题,这时候你应该会很焦急。

假设当前服务器只有一个CPU,那么上面的”load average”就告诉我们在最近一分钟内,平均有0.14个进程在等待CPU;最近五分钟内,CPU有30%的idle时间;而最近15分钟,平均有3.06个进程在等待CPU。而当服务器有4个CPU的时候,则是另外一番景象。

“所以你说的理想负荷为 1.00 ?”

嗯,这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ,有经验的系统管理员都会将这条线划在 0.70:

“需要进行调查法则”: 如果长期你的系统负载在 0.70 上下,那么你需要在事情变得更糟糕之前,花些时间了解其原因。

“现在就要修复法则”:1.00 。 如果你的服务器系统负载长期徘徊于 1.00,那么就应该马上解决这个问题。否则,你将半夜接到你上司的电话,这可不是件令人愉快的事情。

“凌晨三点半锻炼身体法则”:5.00。 如果你的服务器负载超过了 5.00 这个数字,那么你将失去你的睡眠,还得在会议中说明这情况发生的原因,总之千万不要让它发生。

PS:接下来是非常关键的一点,当前的CPU负载高还是不高,只看上面的数据是不行的,还要看服务器有多少个CPU 。

转载文章二:

CPU利用率与Load Average的区别?

CPU利用率,是对一个时间段内CPU使用状况的统计,通过这个指标可以看出在某一个时间段内CPU被占用的情况,如果CPU被占用时间很高,那么就需要考虑CPU是否已经处于超负荷运作,长期超负荷运作对于机器本身来说是一种损害,因此必须将CPU的利用率控制在一定的比例下,以保证机器的正常运作。

Load Average是 CPU的Load,它所包含的信息不是CPU的使用率状况,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息。

那么CPU利用率与Load Average对于性能测试的意义有什么区别呢?实际上,CPU利用率反映的是CPU被使用的情况,当CPU长期处于被使用而没有得到足够的时间休息间歇,那么对于CPU硬件来说是一种超负荷的运作,需要调整使用频度。而Load Average却从另一个角度来展现对于CPU使用状态的描述,Load Average越高说明对于CPU资源的竞争越激烈,CPU资源比较短缺。对于资源的申请和维护其实也是需要很大的成本,所以在这种高Average Load的情况下CPU资源的长期“热竞争”也是对于硬件的一种损害。

如何评估性能需求中合理的Load Average?

一般来说,Load Average是与机器内核数有关的。以一个单核的机器为例,load=0.5表示CPU还有一半的资源可以处理其他的线程请求,load=1表示CPU所有的资源都在处理请求,没有剩余的资源可以利用了,而load=2则表示CPU已经超负荷运作,另外还有一倍的线程正在等待处理。所以,对于单核机器来说,理想状态下,Load Average要小于1。同理,对于双核处理器来说,Load Average要小于2。结论是:多核处理器中,你的Load Average不应该高于处理器核心的总数量。

不同核处理器之间的load值怎样换算?

性能测试中可能遇到这样的问题,你的线上机器是8核的,但是线下性能测试机只有4核的,那么我用4核机器测试得到的load值是4,换算到8核机器上应该是多少呢?————这里原作者计算感觉晕了,我写自己的逻辑

应该是4*4/8=2,即核多了,load值会变小。

转载文章三

平均负载是指上一分钟同时处于就绪状态的平均进程数。在CPU中可以理解为CPU可以并行处理的任务数量,就是CPU个数X核数。如果CPU Load等于CPU个数乘以核数,那么就说CPU正好满负载,再多一点,可能就要出问题了,有些任务不能被及时分配处理器,那要保证性能的话,最好要小于CPU个数X核数X0.7。

Load Average是指CPU的Load。它所包含的信息是在一段时间内CPU正在处理及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息。

Load Average的值应该小于CPU个数X核数X0.7,Load Average会有3个状态平均值,分别是1分钟、5分钟和15分钟平均Load。如果1分钟平均出现大于CPU个数X核数的情况,还不需要担心;如果5分钟的平均也是这样,那就要警惕了;15分钟的平均也是这样,就要分析哪里出现问题,防范未然。

转载文章四

在平时的运维工作中,当一台服务器的性能出现问题时,通常会去看当前的CPU使用情况,尤其是看下CPU的负载情况(load average)。对一般的系统来说,根据cpu数量去判断。比如有2颗cup的机器。如果平均负载始终在1.2以下,那么基本不会出现cpu不够用的情况。也就是Load平均要小于Cpu的数量。

对于cpu负载的理解,首先需要搞清楚下面几个问题:

1)系统load高不一定是性能有问题。

因为Load高也许是因为在进行cpu密集型的计算

2)系统Load高不一定是CPU能力问题或数量不够。

因为Load高只是代表需要运行的队列累计过多了。但队列中的任务实际可能是耗Cpu的,也可能是耗i/0奶子其他因素的。

3)系统长期Load高,解决办法不是一味地首先增加CPU

因为Load只是表象,不是实质。增加CPU个别情况下会临时看到Load下降,但治标不治本。

4)在Load average 高的情况下需要鉴别系统瓶颈到底是CPU不足,还是io不够快造成或是内存不足造成的。

===============================================================================================================

要想获得服务器的CPU负载情况,有下面几种命令:

1)w命令

[root@localhost ~]# w

12:12:41 up 167 days, 20:46, 2 users, load average: 0.00, 0.01, 0.05

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

root pts/0 192.168.1.5 10:01 1.00s 0.11s 0.00s w

root pts/2 192.168.1.5 10:19 1:47m 0.04s 0.04s -bash

2)uptime命令(一般首先会根据最后那个15分钟的load负载为准)

[root@localhost ~]# uptime

12:12:55 up 167 days, 20:46, 2 users, load average: 0.00, 0.01, 0.05

3)top命令

[root@localhost ~]# top

top - 12:13:22 up 167 days, 20:47, 2 users, load average: 0.00, 0.01, 0.05

Tasks: 272 total, 1 running, 271 sleeping, 0 stopped, 0 zombie

%Cpu(s): 0.0 us, 0.1 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65759080 total, 58842616 free, 547908 used, 6368556 buff/cache

KiB Swap: 2097148 total, 2097148 free, 0 used. 64264884 avail Mem

…………….

对上面第三行的解释:

us(user cpu time):用户态使用的cpu时间比。该值较高时,说明用户进程消耗的 CPU 时间比较多,比如,如果该值长期超过 50%,则需要对程序算法代码等进行优化

sy(system cpu time):系统态使用的cpu时间比。

ni(user nice cpu time):用做nice加权的进程分配的用户态cpu时间比

id(idle cpu time):空闲的cpu时间比。如果该值持续为0,同时sy是us的两倍,则通常说明系统则面临着 CPU 资源的短缺。

wa(wait):等待使用CPU的时间。

hi(hardware irq):硬中断消耗时间

si(software irq):软中断消耗时间

st(steal time):虚拟机偷取时间

以上解释的这些参数的值加起来是100%。

4)vmstat

[root@localhost ~]# vmstat

procs ———–memory———————swap——-io———system——–cpu—–

r b swpd free buff cache si so bi bo in cs us sy id wa st

3 0 0 1639792 724280 4854236 0 0 4 34 4 0 19 45 35 0 0

解释说明:


procs部分的解释

  • r 列表示运行和等待cpu时间片的进程数,如果长期大于1,说明cpu不足,需要增加cpu。
  • b列表示在等待资源的进程数,比如正在等待I/O、或者内存交换等。

cpu部分的解释

  • us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期大于50%,需要考虑优化用户的程序。
  • sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%,如果us+sy 大于 80%说明可能存在CPU不足。
  • wa 列显示了等待CPU时间的百分比。这里wa的参考值为5%,如果wa超过5%,说明CPU等待严重
  • id 列显示了cpu处在空闲状态的时间百分比

system部分的解释

in 列表示在某一时间间隔中观测到的每秒设备中断数。

cs列表示每秒产生的上下文切换次数,如当 cs 比磁盘 I/O 和网络信息包速率高得多,都应进行进一步调查。


memory部分的解释

swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0,或者比较大,比如超过了100m,只要si、so的值长期为0,系统性能还是正常

free 当前的空闲页面列表中内存数量(k表示)

buff 作为buffer cache的内存数量,一般对块设备的读写才需要缓冲。

cache: 作为page cache的内存数量,一般作为文件系统的cache,如果cache较大,说明用到cache的文件较多,如果此时IO中bi比较小,说明文件系统效率比较好。


swap部分的解释

si 由内存进入内存交换区数量。

so由内存交换区进入内存数量。


IO部分的解释

bi 从块设备读入数据的总量(读磁盘)(每秒kb)。

bo 块设备写入数据的总量(写磁盘)(每秒kb)

5)也可以使用dstat命令查看cpu信息

[root@localhost ~]# dstat

—-total-cpu-usage—- -dsk/total- -net/total- —paging– —system–

usr sys idl wai hiq siq| read writ| recv send| in out | int csw

19 45 35 0 0 0| 30k 265k| 0 0 | 0 0 |9025 12k

9 18 73 0 0 0| 0 144k|2578k 65k| 0 0 |3956 4343

6)可以使用iOStat查看IO负载

[root@localhost ~]# iostat 1 1

Linux 2.6.32-696.16.1.el6.x86_64 (nc-ftp01.kevin.cn) 2017年12月29日 x86_64 (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

19.32 0.00 45.44 0.06 0.26 34.93

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

xvda 14.17 29.94 265.17 63120486 558975100

解释说明:

avg-cpu: 总体cpu使用情况统计信息,对于多核cpu,这里为所有cpu的平均值

%user: 在用户级别运行所使用的CPU的百分比.

%nice: nice操作所使用的CPU的百分比.

%sys: 在系统级别(kernel)运行所使用CPU的百分比.

%iowait: CPU等待硬件I/O时,所占用CPU百分比.

%idle: CPU空闲时间的百分比.

Device段:各磁盘设备的IO统计信息

tps: 每秒钟发送到的I/O请求数.

Blk_read /s: 每秒读取的block数.

Blk_wrtn/s: 每秒写入的block数.

Blk_read: 读入的block总数.

Blk_wrtn: 写入的block总数.

[root@localhost ~]# iostat -x -k -d 1

Linux 2.6.32-696.el6.x86_64 (centos6-vm02) 01/04/2018 x86_64 (4 CPU)

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util

scd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.36 0.36 0.00 0.36 0.00

vda 0.01 0.13 0.04 0.13 0.60 0.89 18.12 0.00 2.78 0.19 3.53 2.55 0.04

dm-0 0.00 0.00 0.04 0.22 0.58 0.88 11.25 0.00 3.27 0.25 3.82 1.61 0.04

dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.13 0.13 0.00 0.04 0.00

dm-2 0.00 0.00 0.00 0.00 0.00 0.00 7.91 0.00 0.19 0.10 5.00 0.16 0.00

解释说明:

rrqm/s: 每秒对该设备的读请求被合并次数,文件系统会对读取同块(block)的请求进行合并

wrqm/s: 每秒对该设备的写请求被合并次数

r/s: 每秒完成的读次数

w/s: 每秒完成的写次数

rkB/s: 每秒读数据量(kB为单位)

wkB/s: 每秒写数据量(kB为单位)

avgrq-sz:平均每次IO操作的数据量(扇区数为单位)

avgqu-sz: 平均等待处理的IO请求队列长度

await: 平均每次IO请求等待时间(包括等待时间和处理时间,毫秒为单位)

svctm: 平均每次IO请求的处理时间(毫秒为单位)

%util: 采用周期内用于IO操作的时间比率,即IO队列非空的时间比率

如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。

idle小于70% IO压力就较大了,一般读取速度有较多的wait。

同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

(2)简单说下CPU负载和CPU利用率的区别

1)CPU利用率:显示的是程序在运行期间实时占用的CPU百分比

2)CPU负载:显示的是一段时间内正在使用和等待使用CPU的平均任务数。

CPU利用率高,并不意味着负载就一定大。

举例来说:

如果有一个程序它需要一直使用CPU的运算功能,那么此时CPU的使用率可能达到100%,但是CPU的工作负载则是趋近于”1”,因为CPU仅负责一个工作!

如果同时执行这样的程序两个呢?CPU的使用率还是100%,但是工作负载则变成2了。所以也就是说,当CPU的工作负载越大,代表CPU必须要在不同的工作之间

进行频繁的工作切换。

————————下面通过一个电话亭打电话的比喻来说明这两者之间的区别————————

某公用电话亭,有一个人在打电话,四个人在等待,每人限定使用电话一分钟,若有人一分钟之内没有打完电话,只能挂掉电话去排队,等待下一轮。

电话在这里就相当于CPU,而正在或等待打电话的人就相当于任务数。

在电话亭使用过程中,肯定会有人打完电话走掉,有人没有打完电话而选择重新排队,更会有新增的人在这儿排队,这个人数的变化就相当于任务数的增减。

为了统计平均负载情况,我们5分钟统计一次人数,并在第1、5、15分钟的时候对统计情况取平均值,从而形成第1、5、15分钟的平均负载。

有的人拿起电话就打,一直打完1分钟,而有的人可能前三十秒在找电话号码,或者在犹豫要不要打,后三十秒才真正在打电话。如果把电话看作CPU,人数看

作任务,我们就说前一个人(任务)的CPU利用率高,后一个人(任务)的CPU利用率低。当然, CPU并不会在前三十秒工作,后三十秒歇着,只是说,有的程

序涉及到大量的计算,所以CPU利用率就高,而有的程序牵涉到计算的部分很少,CPU利用率自然就低。但无论CPU的利用率是高是低,跟后面有多少任务在排队

没有必然关系。

(3)load average相关梳理(一分钟,五分钟,十五分钟的平均CPU负载,最重要的指标是最后一个数字,即前15分钟的平均CPU负载,这个数字越小越好。所谓CPU负载指的是一段时间内任务队列的长度,通俗的讲,就是一段时间内一共有多少任务在使用或等待使用CPU。(当前的”负载值除以cpu核数”就是cpu的利用率))

load average表示的是系统的平均负荷,即CPU的Load。

它所包含的信息不是CPU的使用率状况,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息。

它包括3个数字,分别表示系统在1、5、15分钟内进程队列中的平均进程数量(即处理的进程情况),

原则上来说这3个数字越小越好,数字越小表示服务器的工作量越小,系统负荷比较轻

当CPU完全空闲的时候,平均负荷为0(即load average的值为0);当CPU工作量饱和的时候,平均负荷为1。

这里需要注意的是:

load average这个输出值,这三个值的大小一般不能大于系统逻辑CPU的个数

比如一台服务器有4个逻辑CPU,如果load average的三个值长期大于4时,说明CPU很繁忙,负载很高,可能会影响系统性能;

但是偶尔大于4时,倒不用担心,一般不会影响系统性能。

相反,如果load average的输出值小于CPU的个数,则表示CPU还有空闲,比如本例中的输出,CPU是比较空闲的。

————-load average举例理解—————

判断系统负荷是否过重,必须理解load average的真正含义。假设当前我的一台服务器只有一个CPU,所有的运算都必须由这个CPU来完成。

不妨把这个CPU想象成一座大桥,桥上只有一根车道,所有车辆都必须从这根车道上通过(很显然,这座桥只能单向通行)。

1)系统负荷为0,意味着大桥上一辆车也没有。

2)系统负荷为0.5,意味着大桥一半的路段有车。

3)系统负荷为1.0,意味着大桥的所有路段都有车,也就是说大桥已经”满”了。但是必须注意的是,直到此时大桥还是能顺畅通行的。

4)系统负荷为1.7,意味着车辆太多了,大桥已经被占满了(100%),后面等着上桥的车辆为桥面车辆的70%。

以此类推,系统负荷2.0,意味着等待上桥的车辆与桥面的车辆一样多;

系统负荷3.0,意味着等待上桥的车辆是桥面车辆的2倍。

总之,当系统负荷大于1,后面的车辆就必须等待了;系统负荷越大,过桥就必须等得越久。

CPU的系统负荷,基本上等同于上面的类比。大桥的通行能力,就是CPU的最大工作量;桥梁上的车辆,就是一个个等待CPU处理的进程(process)。

如果CPU每分钟最多处理100个进程,那么:

系统负荷0.2,意味着CPU在这1分钟里只处理20个进程;

系统负荷1.0,意味着CPU在这1分钟 里正好处理100个进程;

系统负荷1.7,意味着除了CPU正在处理的100个进程以外,还有70个进程正排队等着CPU处理。

为了服务器顺畅运行,系统负荷最好不要超过1.0,这样就没有进程需要等待了,所有进程都能第一时间得到处理。

很显然,1.0是一个关键值,超过这个值,系统就不在最佳状态了,就需要动手干预了。

——–1.0是系统负荷的理想值吗?———–

不一定,系统管理员往往会留一点余地,当这个值达到0.7,就应当引起注意了。

以往经验是这样的:

当系统负荷持续大于0.7,必须开始调查了,问题出在哪里,防止情况恶化。

当系统负荷持续大于1.0,必须动手寻找解决办法,把这个值降下来。

当系统负荷达到5.0,就表明系统有很严重的问题,长时间没有响应,或者接近死机了。觉不能让系统达到这个值。

上面,假设我的这台服务器只有1个CPU。如果它装了2个CPU,就意味着服务器的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。

还是用大桥来类比,两个CPU就意味着大桥有两根车道了,通车能力翻倍了。

所以,2个CPU表明系统负荷可以达到2.0,此时每个CPU都达到100%的工作量。推广开来,n个CPU的服务器,可接受的系统负荷最大为n.0。

———至于load average是多少才算理想,这个有争议,各有各的说法———

个人比较赞同CPU负载小于等于”内核数乘以0.5-0.7”算是一种理想状态。

比如4核CPU的服务器,理想负载是小于等于2,最好不要超过2.8,否则性能多少会受影响。

不管某个CPU的性能有多好,1秒钟能处理多少任务,可以认为它无关紧要,虽然事实并非如此。

在评估CPU负载时,只以5分钟为单位做统计任务队列长度。如果每隔5分钟统计的时候,发现任务队列长度都是1,那么CPU负载就为1。

假如现在某台服务器只有一个单核的CPU,负载一直为1,意味着没有任务在排队,还不错。

但是这台服务器是双核CPU,等于是有4个内核,每个内核的负载为1的话,总负载为4。这就是说,如果这台服务器的CPU负载长期保持在4左右,还可以接受。

但是每个内核的负载为1,并不能算是一种理想状态!这意味着服务器的CPU一直很忙,不得清闲。

———–load average返回三个平均值应该参考哪个值?————

如果只有1分钟的系统负荷大于1.0,其他两个时间段都小于1.0,这表明只是暂时现象,问题不大。

如果15分钟内,平均系统负荷大于1.0(调整CPU核心数之后),表明问题持续存在,不是暂时现象。

所以应该主要观察”15分钟系统负荷”,将它作为服务器正常运行的指标。

———-如何来降低服务器的CPU负载?————–

最简单办法的是更换性能更好的服务器,不要想着仅仅提高CPU的性能,那没有用,CPU要发挥出它最好的性能还需要其它软硬件的配合。

在服务器其它方面配置合理的情况下,CPU数量和CPU核心数(即内核数)都会影响到CPU负载,因为任务最终是要分配到CPU核心去处理的。两块CPU要比一块

CPU好,双核要比单核好。因此,需要记住的是:除去CPU性能上的差异,CPU负载是基于内核数来计算的。有一个说法是”有多少内核,即有多少负载”。

相关阅读

准确率,召回率,mAP(mean average precision)解释

准确率Precision 召回率Recall 其实这个翻译相当蛋疼。。。 recall最合理的翻译应该是 查全率 而Precision的最合理的翻译应该是

dumps,loads与dump,load的区别

可以把dumps和loads对比来看 json.dumps() 是将python的dict数据类型转换为json字符串 json.loads() 是将json字符串转换为dict

location reload页面实现跳转和刷新

  1 history.go(0)2 location.reload()3 location=location4 location.assign(location)5 document.execCommand('Refresh')6

[Excel]Excel函数和用法(6)——按照多个指定条件计数,

语法:COUNTIFS(criteria_range1, criteria1, criteria_range2, criteria2, …) 例如,统计A列性别为男的,年龄在5-13之间的,姓A的数量:

ajaxfileupload使用中的问题

1,报错,<token 类似的错误。 这个是数据返回时的报错。 修改: uploadHttpData: function( r, type ) { var data = !type;

分享到:

栏目导航

推荐阅读

热门阅读