精华内容
下载资源
问答
  • 1.如何判断CPU、内存、磁盘的瓶颈? CPU瓶颈 1) 查看CPU利用率。... 如果us,sy高于这个指标可以判断CPU有瓶颈  使用top查看  查看运行队列  每个CPU都会维持一个运行队列,理想情况下,调度器会不断让...

    1.如何判断CPU、内存、磁盘的瓶颈?

    CPU瓶颈

     

    1) 查看CPU利用率。建议CPU指标如下

      a) User Time:65%~70%

      b) System Time:30%~35%

      c) Idle:0%~5%

      如果us,sy高于这个指标可以判断CPU有瓶颈

      使用top查看

      查看运行队列

      每个CPU都会维持一个运行队列,理想情况下,调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。如果CPU过载,就会出现调度器跟不上系统的要求,导致可运行的进程会填满队列。队列愈大,程序执行时间就愈长。“load”用来表示运行队列,用top 命令我们可以看到CPU一分钟,5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。超过 1.00,那么说明CPU已经超出负荷,交通严重的拥堵。

      使用top或者uptime查看

      查看上下文切换

      每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。

      使用vmstat查看cs

     

    结论

    检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.

      确定CPU 利用率中user/system比例维持在70/30

      当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级

      当I/O 处理得到增长,CPU 范畴的应用处理将受到影响

      ps:对于JAVA应用,CPU瓶颈可以通过jprofiler监控分析

    内存瓶颈

      1.查看利用率(free)

      used:已使用多大。

      free:可用有多少。

      Shared:多个进程共享的内存总额。

      Buffers/cached:磁盘缓存的大小。

      2.查看页交换,swap交换(po,pi,so,si),磁盘IO(vmstat)

      si: 每秒从交换区写到内存的大小

      so: 每秒写入交换区的内存大小

      page in :分页(Page)从磁盘重新回到内存的过程被称作Page-In

      page out : 分页(Page)写入磁盘的过程被称作Page-Out

      另外在进行页交换的时候,会产生磁盘IO,还需注意bi,bo

      Bo 磁盘块页面从内存到文件或交换设备的总额

      Bi 磁盘块页面从文件或交换设备到内存的总额

      3.page fault(pidstat -r,sar -B )

      minflt/s: 每秒次缺页错误次数(minor page faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数

      majflt/s: 每秒主缺页错误次数(major page faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page fault为major page fault,一般在内存使用紧张时产生

      其中sar -B中fault/s表示每秒钟minflt,majflt的和。

     

    结论

      监控虚拟内存性能由以下几个部分组成:

      1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).

      2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.

      3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.

      zee:

      如果用做缓冲区(buff)和快速缓存(Cache)的物理内存不断地增加,而空闲的物理内存(free)不断地减少,证明系统中运行的进程正在不断地消耗物理内存。

      已经使用的虚拟内存(swpd)不断增加,而且存在着大量的页面交换(si和so),证明物理内存已经不能满足系统需求,系统必须把物理内存的页面交换到磁盘中去。

      由此可以得到这样的结论:该主机上的物理内存已经不能满足系统运行的需要,内存已成为该系统性能的一个瓶颈。

      ps:对于java程序,内存瓶颈可以通过heap dump后使用mat分析

     

    磁盘瓶颈

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

      另外还需要注意iowait这个值,iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。

      监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.

      ps:磁盘瓶颈可以通过pidstat -d 定位程序

     

    2.如何理解CPU、内存、磁盘的关系?

      这些子系统之间关系是彼此联系,相互彼此依赖的

      1.对于进程来说,数据是存放在内存中的,进程的运行需要使用CPU,进程读写数据需要跟磁盘打交道。

      2.当内存不足时需要跟磁盘进行页(page)交换,swap交换,从而产生磁盘IO。po,so释放物理内存,pi,si增加物理内存使用。交换分页的过程需要占用cpu时间。 (内存占用过高)

      3.当磁盘IO负载过高时,需要监控swap和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈。磁盘的相当慢的,当iowait 增长,表示CPU花费大量的时间在等待磁盘IO,此时CPU Bound的应用处理将受到影响(磁盘IO过高)

      3.如何理解paging in / paging out ?

      在Linux内存管理中,主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上,把活动页面保留在内存中供进程使用。交换技术是将整个进程,而不是部分页面,全部交换到磁盘上。

      分页(Page)写入磁盘的过程被称作Page-Out,分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时,但发现此分页不在物理内存中(因为已经被Page-Out了),此时就发生了分页错误(Page Fault)。

      当系统内核发现可运行内存变少时,就会通过Page-Out来释放一部分物理内存。经管Page-Out不是经常发生,但是如果Page-out频繁不断的发生,直到当内核管理分页的时间超过运行程式的时间时,系统效能会急剧下降。这时的系统已经运行非常慢或进入暂停状态,这种状态亦被称作thrashing(颠簸)。

      可以通过vmstat -s 查看 paged in/out 数量

      4.如何监控操作系统的资源?

      CPU监控:top(利用率), uptime(运行队列数), vmstat(上下文切换数), jprofile(方法占用cpu时间百分比)

      内存监控:top, free(利用率), vmstat(page和swap交换), pidstat -r和sar -B(page fault), jmap -heap(堆dump), mat和jprofiler(查看对象)

      磁盘监控:iostat(%util), top(iowait%), pidstat -d

      网络监控:netstat(连接数), nethogs(流量), wireshark和tcpdump(抓包)

      JVM监控:jstat(gc), jmap(堆dump), jstack(线程dump), jprofiler和visualvm(剖析工具)

      nmon(长时间全局收集数据)

      5.如何理解上下文切换(context switch)?

      每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度。即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。

      vmstat其中cs那一列

      7.如何理解磁盘IO?

      磁盘IO速度是非常慢的,linux内核就是要尽量降低IO

      内存不足时会进行页交换,产生磁盘IO

      CPU Bound类型应用,当磁盘IO过多,iowait过大时会影响性能。

     

    展开全文
  • CPU 负载和 CPU 使用率 这两个从一定程度上都可以反映一台机器的繁忙程度。 CPU 使用率反映的是当前 CPU 的繁忙程度,忽高忽低的原因在于占用 CPU 处理时间的进程可能处于 IO 等待状态但却还未释放进入wait。 ...
    CPU 负载和 CPU 使用率

    这两个从一定程度上都可以反映一台机器的繁忙程度。

    CPU 使用率反映的是当前 CPU 的繁忙程度,忽高忽低的原因在于占用 CPU 处理时间的进程可能处于 IO 等待状态但却还未释放进入wait。

    平均负载(load average)是指某段时间内占用 CPU 时间的进程和等待 CPU 时间的进程数,这里等待 CPU 时间的进程是指等待被唤醒的进程,不包括处于wait状态进程。

    以上分析可以看出,一台机器很有可能处于低 CPU 使用率高负载的情况,因此看机器的繁忙程度应该结合两者,从实际的使用情况观察,自己的一台双核志强 2.8GHZ,2G 内存的机器在平均负载到 50 左右, CPU 使用率才接近 100%(应用有不少 IO 操作),这种情况下应用还算流畅,实际访问延迟不是很高。因此在 CPU 还空闲的情况下,如何提高 IO 响应是减少负载的关键,很多人认为负载到几十了机器就非常繁忙了,我倒觉得如果这个时候 CPU 使用率比较低,则负载高可能不能很好说明问题,一旦 CPU 处理的进程处理完后,那些等待的进程也能立刻得到响应,这种情况下应该优化 IO 读写速度。真到 CPU 使用率一直 90% 以上,即使平均负载只有个位数(比如某一个进程一直在运算),那机器其实也已经繁忙了~

    其实,在前面的文章中,也有写到 CPU 使用率低负载高,原因分析 CPU 使用率低,但是 load 很高,load 很高的可能是IO

    CPU 负载的一个类比

    判断系统负荷是否过重,必须理解 load average 的真正含义。下面,我根据”Understanding Linux CPU Load”这篇文章,尝试用最通俗的语言,解释这个问题。

    首先,假设最简单的情况,你的电脑只有一个 CPU ,所有的运算都必须由这个 CPU 来完成。

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

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

    系统负荷为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是一个关键值,超过这个值,系统就不在最佳状态了,你要动手干预了。

    CPU 负载-多处理器

    上面,我们假设你的电脑只有1个 CPU 。如果你的电脑装了2个 CPU ,会发生什么情况呢?

    2个 CPU ,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。还是用大桥来类比,两个 CPU 就意味着大桥有两根车道了,通车能力翻倍了。

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

    CPU 负载-多核处理器

    芯片厂商往往在一个 CPU 内部,包含多个 CPU 核心,这被称为多核 CPU 。

    在系统负荷方面,多核 CPU 与多 CPU 效果类似,所以考虑系统负荷的时候,必须考虑这台电脑有几个 CPU 、每个 CPU 有几个核心。然后,把系统负荷除以总的核心数,只要每个核心的负荷不超过1.0,就表明电脑正常运行。

    怎么知道电脑有多少个 CPU 核心呢?

    cat /proc/cpuinfo命令,可以查看 CPU 信息。grep -c 'model name' /proc/cpuinfo命令,直接返回 CPU 的总核心数。

    系统负荷的经验法则

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

    不一定,系统管理员往往会留一点余地,当这个值达到0.7,就应当引起注意了。经验法则是这样的:

    • 当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。
    • 当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。
    • 当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应,或者接近死机了。你不应该让系统达到这个值。

    对于我的机器,有24个core,那么,load多少合适呢?

    [root@lpf]# grep -c 'model name' /proc/cpuinfo
    24

    答案是:

    [root@lpf]# echo "0.7*24" | bc
    16.8
    最佳观察时长

    最后一个问题,”load average” 一共返回三个平均值—-1分钟系统负荷、5分钟系统负荷,15分钟系统负荷,—-应该参考哪个值?

    • 如果只有1分钟的系统负荷大于1.0,其他两个时间段都小于1.0,这表明只是暂时现象,问题不大。
    • 如果15分钟内,平均系统负荷大于1.0(调整 CPU 核心数之后),表明问题持续存在,不是暂时现象。
    • 所以,你应该主要观察”15分钟系统负荷”,将它作为电脑正常运行的指标。







    来源:https://www.cnblogs.com/muahao/p/6492665.html

    展开全文
  • 在stackoverflow上一个非常有名的问题:[为什么处理有序数组要比非有序数组快?]( https://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array),可见...

    分支预测

    在stackoverflow上有一个非常有名的问题: 为什么处理有序数组要比非有序数组快,可见分支预测对代码运行效率有非常大的影响。

    现代CPU都支持分支预测(branch prediction)和指令流水线(instruction pipeline),这两个结合可以极大提高CPU效率。对于像简单的if跳转,CPU是可以比较好地做分支预测的。但是对于switch跳转,CPU则没有太多的办法。switch本质上是据索引,从地址数组里取地址再跳转。

    要提高代码执行效率,一个重要的原则就是尽量避免CPU把流水线清空,那么提高分支预测的成功率就非常重要。

    那么对于代码里,如果某个switch分支概率很高,是否可以考虑代码层面帮CPU把判断提前,来提高代码执行效率呢?

    Dubbo里ChannelEventRunnable的switch判断

    ChannelEventRunnable里有一个switch来判断channel state,然后做对应的逻辑:查看

    一个channel建立起来之后,超过99.9%情况它的state都是ChannelState.RECEIVED,那么可以考虑把这个判断提前。

    benchmark验证

    下面通过jmh来验证下:

    public class TestBenchMarks {
        public enum ChannelState {
            CONNECTED, DISCONNECTED, SENT, RECEIVED, CAUGHT
        }
    
        @State(Scope.Benchmark)
        public static class ExecutionPlan {
            @Param({ "1000000" })
            public int size;
            public ChannelState[] states = null;
    
            @Setup
            public void setUp() {
                ChannelState[] values = ChannelState.values();
                states = new ChannelState[size];
                Random random = new Random(new Date().getTime());
                for (int i = 0; i < size; i++) {
                    int nextInt = random.nextInt(1000000);
                    if (nextInt > 100) {
                        states[i] = ChannelState.RECEIVED;
                    } else {
                        states[i] = values[nextInt % values.length];
                    }
                }
            }
        }
    
        @Fork(value = 5)
        @Benchmark
        @BenchmarkMode(Mode.Throughput)
        public void benchSiwtch(ExecutionPlan plan, Blackhole bh) {
            int result = 0;
            for (int i = 0; i < plan.size; ++i) {
                switch (plan.states[i]) {
                case CONNECTED:
                    result += ChannelState.CONNECTED.ordinal();
                    break;
                case DISCONNECTED:
                    result += ChannelState.DISCONNECTED.ordinal();
                    break;
                case SENT:
                    result += ChannelState.SENT.ordinal();
                    break;
                case RECEIVED:
                    result += ChannelState.RECEIVED.ordinal();
                    break;
                case CAUGHT:
                    result += ChannelState.CAUGHT.ordinal();
                    break;
                }
            }
            bh.consume(result);
        }
    
        @Fork(value = 5)
        @Benchmark
        @BenchmarkMode(Mode.Throughput)
        public void benchIfAndSwitch(ExecutionPlan plan, Blackhole bh) {
            int result = 0;
            for (int i = 0; i < plan.size; ++i) {
                ChannelState state = plan.states[i];
                if (state == ChannelState.RECEIVED) {
                    result += ChannelState.RECEIVED.ordinal();
                } else {
                    switch (state) {
                    case CONNECTED:
                        result += ChannelState.CONNECTED.ordinal();
                        break;
                    case SENT:
                        result += ChannelState.SENT.ordinal();
                        break;
                    case DISCONNECTED:
                        result += ChannelState.DISCONNECTED.ordinal();
                        break;
                    case CAUGHT:
                        result += ChannelState.CAUGHT.ordinal();
                        break;
                    }
                }
            }
            bh.consume(result);
        }
    }
    • benchSiwtch里是纯switch判断
    • benchIfAndSwitch 里用一个if提前判断state是否ChannelState.RECEIVED

    benchmark结果是:

    Result "io.github.hengyunabc.jmh.TestBenchMarks.benchSiwtch":
      576.745 ±(99.9%) 6.806 ops/s [Average]
      (min, avg, max) = (490.348, 576.745, 618.360), stdev = 20.066
      CI (99.9%): [569.939, 583.550] (assumes normal distribution)
    
    
    # Run complete. Total time: 00:06:48
    
    Benchmark                         (size)   Mode  Cnt     Score    Error  Units
    TestBenchMarks.benchIfAndSwitch  1000000  thrpt  100  1535.867 ± 61.212  ops/s
    TestBenchMarks.benchSiwtch       1000000  thrpt  100   576.745 ±  6.806  ops/s

    可以看到提前if判断的确提高了代码效率,这种技巧可以放在性能要求严格的地方。

    Benchmark代码:https://github.com/hengyunabc/jmh-demo

    总结

    • switch对于CPU来说难以做分支预测
    • 某些switch条件如果概率比较高,可以考虑单独提前if判断,充分利用CPU的分支预测机制
    展开全文
  • 如何判断CPU是大端还是小端模式

    千次阅读 2018-01-18 16:59:25
    在各种体系的计算机中通常采用的字节存储机制主要两种: Big-Endian和Little-Endian,即大端模式和小端模式。 Big-Endian和Little-Endian的定义如下: 1) Little-Endian:就是低位字节排放在内存的低地址端,...

    一、概念及详解

    在各种体系的计算机中通常采用的字节存储机制主要有两种: Big-EndianLittle-Endian,即大端模式和小端模式。

    Big-Endian和Little-Endian的定义如下:

    1) Little-Endian:就是低位字节排放在内存的低地址端,高位字节排放在内存的高地址端。
    2) Big-Endian:就是高位字节排放在内存的低地址端,低位字节排放在内存的高地址端。

    举一个例子,比如16进制数字0x12345678在内存中的表示形式为:

    大端小端没有谁优谁劣,各自优势便是对方劣势:

    小端模式 :强制转换数据不需要调整字节内容,1、2、4字节的存储方式一样。
    大端模式 :符号位的判定固定为第一个字节,容易判断正负。

    为什么会有大小端模式之分呢?

    这是因为在计算机系统中,我们是以字节为单位的,每个地址单元都对应着一个字节,一个字节为8bit。但是在C语言中除了8bit的char之外,还有16bit的short型,32bit的long型(要看具体的编译器),另外,对于位数大于8位的处理器,例如16位或者32位的处理器,由于寄存器宽度大于一个字节,那么必然存在着一个如何将多个字节安排的问题。因此就导致了大端存储模式和小端存储模式。

    例如一个16bit的short型x,在内存中的地址为0x0010,x的值为0x1122,那么0x11为高字节,0x22为低字节。对于大端模式,就将0x11放在低地址中,即0x0010中,0x22放在高地址中,即0x0011中。小端模式,刚好相反。我们常用的x86结构是小端模式,而KEIL C51则为大端模式。很多的ARM,DSP都为小端模式。有些ARM处理器还可以由硬件来选择是大端模式还是小端模式。

    如何判断机器的字节序

    int i=1;   
    char *p=(char *)&i;   
    if(*p == 1)     
        printf("小端模式"); 
    else // (*p == 0)
        printf("大端模式");

    或者使用联合体union:

    //return 1 : little-endian
    //       0 : big-endian
    int checkCPUendian()
    {
        union {
            unsigned int a;
            unsigned char b; 
        } c;
    
        c.a = 1;
        return (c.b == 1); 
    }

    因为联合体union的存放顺序是所有成员都从低地址开始存放,利用该特性就可以轻松地获得了CPU对内存采用Little-endian还是Big-endian模式读写。

    常见的字节序

    一般操作系统都是小端,而通讯协议是大端的。

    常见CPU的字节序

    大小端 CPU
    Big Endian PowerPC、IBM、Sun
    Little Endian x86、DEC

    ARM既可以工作在大端模式,也可以工作在小端模式。

    常见文件的字节序

    文件格式 大小端
    Adobe PS Big Endian
    BMP Little Endian
    DXF(AutoCAD) Variable
    GIF Little Endian
    JPEG Big Endian
    MacPaint Big Endian
    RTF Little Endian

    另外,Java和所有的网络通讯协议都是使用Big-Endian的编码。

    大端小端的转换方法

    #define BigtoLittle16(A)                 ((((uint16)(A) & 0xff00) >> 8) | \
                                             (((uint16)(A) & 0x00ff) << 8))
    
    
    #define BigtoLittle32(A)                 ((((uint32)(A) & 0xff000000) >> 24) | \
                                             (((uint32)(A) & 0x00ff0000) >> 8) | \
                                             (((uint32)(A) & 0x0000ff00) << 8) | \
                                             (((uint32)(A) & 0x000000ff) << 24))

    参考资料

    展开全文
  • 用于快速排查Java的CPU性能问题

    千次阅读 2017-08-17 20:37:49
    show-busy-java-threads.sh 用于快速排查Java的CPU性能问题(top us值过高),自动查出运行的Java进程中消耗CPU多的线程,并打印出其线程栈,从而确定导致性能问题的方法调用...top命令找出有问题Java进程及线程id:
  • 判断CPU是大端还是小端

    万次阅读 2009-04-21 11:35:00
    一、如何判断CPU是大端还是小端?明白大端和小端的区别,实现起来就非常简单:#include int main(){ union ut{ short s; char c[2]; }u; if(sizeof(short) == 2) { u.s = 0x0102; if(u.c[0] == 1 && u.c[1] ...
  • Linux C++ 程序占cpu%问题排查

    千次阅读 2019-04-19 17:01:09
    Linux C++ 程序占cpu%问题排查 缘起 对一个服务(room_status_server)进行了一些优化,并顺便修改了部分配置文件,重启后用top命令观察,发现该程序cpu几乎占到了100%。 初步判断 发现这个问题后,想到前两天还...
  • 关于单线程和多CPU问题

    千次阅读 2016-10-10 23:23:07
    关于单线程和CPU问题
  • CPU100%问题排查

    千次阅读 2018-06-15 13:52:22
    CPU100%问题排查 功能问题,通过日志,单步调试相对比较好定位。 性能问题,例如线上服务器CPU100%,如何找到相关服务,如何定位问题代码,更考验技术人的功底。 题目 某服务器上部署了若干tomcat实例,即若干...
  • 线上java程序CPU占用过高问题排查

    万次阅读 多人点赞 2017-09-18 16:01:55
    工作中负责的一个项目是使用iReport+JasperReport实现的一个打印系统。...个JasperReport的转换任务内存占用特别高,当新对象需要分配内存时就会内存不够了,于是GC线程就不断GC,占用CPU。 导致系统CPU占用超高。
  • 判断CPU存储字节大小端的两个程序

    千次阅读 2012-05-09 22:10:19
    最近看了有关CPU处理字节的大小端存储方式以及网络传输中相关字节端顺序的问题,想起曾经也在编程中遇到过此类问题,只是当时没有引起重视,在编程顺利的情况下也就想当然的过去了,因此必要作以下总结。...
  • cpu100% 问题排查

    千次阅读 2018-07-20 08:43:42
    首先登录到服务器使用top命令确认服务器的具体情况,根据具体情况再进行分析判断。 通过观察load average,以及负载评判标准(8核),可以确认服务器存在负载较高的情况; 观察各个进程资源使用情况,可以看出...
  • 1. 如何判断CPU高? 很多操作系统的命令可以看出来,比如ps -elf,iostat, vmstat, top/topas, 2. 收集数据 CPU高分为usr高和sys高,前者表示系统在执行应用代码,一般需要应用(比如Db2)来查原因。后者...
  • 判断Linux进程在哪个CPU核运行的方法

    万次阅读 2018-09-05 22:01:32
    问题一个Linux进程运行在多核处理器系统上,如何查看该进程运行在哪个CPU上? 方法一: 如果一个进程使用taskset命令明确的被固定(Pinned)到CPU的特定内核上,你可以使用taskset命令找出被固定的CPU内核: ...
  • 交换机CPU使用率高问题定位

    千次阅读 2020-05-23 23:01:23
    报文冲击导致的CPU使用率高问题 CPU使用率高问题信息采集 诊断工具 display cpu-usage [ slot x ] display cpu-defend statistics 对于报文冲击导致CPU高的情形,可进一步通过cpu-defend统计查询功能确认具体的...
  • Linux C中判断cpu大小端序的几种方法

    千次阅读 2019-03-24 13:32:04
    在网络编程中,处理协议时,经常会遇到大小端序的问题,处理出错就会得到错误的结果。 一般而言,x86和arm处理器使用小端序,而PowerPC使用大端序,在网络中传输的字节使用大端序。 作为程序员,需要根据工程标准,...
  • 两个CPU核分配任务问题

    千次阅读 2017-08-06 11:32:52
    两个CPU核分配任务问题: 给定n(0~N)个任务work,每个任务i=0~n-1都各自需要处理的时间needTime[i] =1~1000(ms)。另外两个CPU核(核A、核B)处理这些任务,将n个任务分配给两个CPU核,求这两个核处理完所有...
  •  关于大端小端名词的由来,一个有趣的故事,来自于Jonathan Swift的《格利佛游记》:Lilliput和Blefuscu这两个强国在过去的36个月中一直在苦战。战争的原因:大家都知道,吃鸡蛋的时候,原始的方法是打破鸡蛋较大...
  • 相关内容的科普放在最前面: 笔记本CPU和台式机CPU区别: ...CPU怎么选:(待更新) ...CPU种类这么多,什么区别? 我知道这是很重要的东西,可是他是怎么做的,为什么中国造不出? 我们如何选择CPU? 当你阅读完
  • Strace诊断CPU跑高问题

    千次阅读 2018-05-03 11:41:20
    Strace诊断CPU跑高问题手把手教你用Strace诊断问题早些年,如果你知道个 strace 命令,就很牛了,而现在大家基本都知道 strace 了,如果你遇到性能问题求助别人,十有八九会建议你用 strace 挂上去看看,不过当你...
  • CPU load过高问题排查

    千次阅读 2019-03-04 09:58:10
    CPU load过高问题排查load average的概念cpu load高的排查思路一般经验数据库系统load高的一般原因判别和处理load高问题 load average的概念 top命令中load average显示的是最近1分钟、5分钟和15分钟的系统平均负载...
  • 解决CPU风扇转速为“0”的问题

    千次阅读 2012-10-25 16:03:54
    故障问题:一台计算机,在主板CMOS的“PC Health Status”项下查看CPU风扇转速为“0”。  故障处理:一般情况下,在CMOS中显示CPU风扇转速为“0”以下原因: 1. CPU风扇电源线没有插在主板的CPU Fan 插针上,...
  • CPU负载查看方法: 使用vmstat查看系统维度的CPU负载 使用top查看进程维度的CPU负载 https://blog.csdn.net/lufeisan/article/details/53150971 使用 vmstat 查看系统纬度的 CPU 负载: 可以通过 vmstat 从...
  • linux诊断CPU软中断问题

    千次阅读 2014-09-24 13:20:25
    前些天发现XEN虚拟机上的Nginx服务器存在一个问题:软中断过高,而且大部分都集中在同一个CPU,一旦系统繁忙,此CPU就会成为木桶的短板。   在问题服务器上运行「top」命令可以很明显看到「si」存在异样...
  • 快速判断主板与cpu兼容性

    千次阅读 2013-07-03 09:27:03
    一块性能十分强劲的CPU,如果没有一块做工扎实、用料足的好主板搭配,不但无法完全发挥出处理器的性能,还会造成系统的极不稳定。因此,我们在攒机时,不单单要考虑选择一块性能出色的处理器,在主板的选购上也要...
  • 如何判断BIOS设置是否开启CPU虚拟化功能? 右击任务栏空白处,单击快捷菜单中“任务管理器“,找到“性能”选项卡,看“虚拟化:已启用” 还是 “虚拟化:已禁用”。参见下图: 若看到“虚拟化:已启用”,说明...
  • CPU上涨100%的问题排查

    千次阅读 2015-07-13 20:19:26
    因为本次改动只对深圳有效,而其他两地的CPU也增长,那么可以确认是一年中其他修改导致了CPU的增长。 排查CPU增长情况的工具首先是TOP命令查看占用CPU最多的是哪几个进程,毫无疑问就是我的SPP服务的几个worker进
  • CPU与内存频率匹配问题

    千次阅读 2013-11-18 16:18:14
    关于内存与CPU搭配的问题,是电脑爱好者最关心的问题之一。怎样搭配?在网上成百上千篇文章,把人给看得眼花缭乱,如果不仔细分析判断,很难辨别哪个是正确的,哪个是错误的。据我分析,形成这种局面的原因多种...
  • 一个Tomcat高CPU占用问题的定位

    千次阅读 2018-03-30 09:04:02
    前段时间项目(交接过来的)发布了一个大的版本以后,IDC机器CPU不时会突然飙升,而且是“根本停不下来”的样子,一上去了就是100%。想来也纳闷,虽然发了版本,但没有太耗CPU的功能,不应该会让CPU一下子从20%左右...
  • 最近在处理虚拟摄像头搭配高德AR导航时,出现了一些内存和cpu问题,这里做个初步记录,后面再完善 1.)开一个hal3的后台录相、预览app,再开一个高德AR导航虚拟摄像头。这时cpu消耗最高达到了600%以上, AR导航界面...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 298,626
精华内容 119,450
关键字:

如何判断cpu有问题