cpu参数

既然买了《现代操作系统》（《Modern Operating System》）这本书，那就好好学习一下吧，这是第一篇读书笔记。 ##第一章 引论 计算机系统总的来说分为软件和硬件，如下图所示。多数计算机有两种运行模式： 内核态和用户态 。 软件中最基础的部分是操作系统 ， 它运行在内核态。操作系统具有对所有硬件的完全访问权限，可以执行机器能够运行的任何指令。 其他软件运行在用户态，只能使用部分机器指令。特别指出，哪些会影响极其的控制或可进行I/O操作的指令，在用户态中的程序是禁止的。 无法直接运行指令，则只能通过操作系统提供的接口来达到目的。 操作系统由硬件进行保护，防止用户试图对其进行修改。 大家都操作过Windows、Linux等操作系统，感觉这是不是就是操作系统？ 这些与用户交互的程序，实际上并不是操作系统的一部分，经它们使用操作系统来完成工作，基于图标的称为图形用户界面（GUI, Graphical User Interface）,我们所用的Windows就是这种，可以看到各种图标； 基于文本的则通常称为shell， 比如我们在Windows中使用cmd命令， 或者在Ubuntu中是Xshell等软件程序。 不过，在嵌入式系统（没有内核态）或解释系统（如基于Java的操作系统，它采用解释方式，而非硬件方式区分组件）， 上述划分的边界是比较模糊的。 1.1 什么是操作系统

/*--> */ /*--> */ 其他 core 的入口 文件： arch/arm64/kernel/head.S secondary_entry ： 在从 bl31 切到 EL1 上的 Linux Kernel 后： 第 595 行，在 el2_setup 中设置 EL1 和 EL0 为小端模式，然后将 w0 设置为 BOOT_CPU_MODE_EL1 ，并返回 第 596 行，记录 boot cpu 的启动模式到 __boot_cpu_mode ，目前是 BOOT_CPU_MODE_EL1 secondary_startup ： 第 604 行， __cpu_setup: 1、 无效本地 tlb 2、 使能 FP/ASIMD 3、 设置 mdscr_el1 ，在 EL0 访问 Debug Communication Channel 寄存器时，陷入 EL1 4、 操作 daif ，使能 debug 中断 5、 设置 pmuserenr_el0 ，当 EL0 访问 PMU 寄存器时会陷入 EL1 6、 填充 mair_el1 ，设置后面要用到的内存属性索引，目前用到了 6 中内存属性： 7、 读取 sctlr_el1 ，修改后存入 x0 ，后面配置 mmu 时会用到 x0 的值： x0= (sctrl_el1 & ~0xfcffffff)|0x34d5d91d ，即将控制大小端的

一、CPU过高分析 1）使用TOP命令查看CPU、内存使用状态可以发现CPU占用主要分为两部分，一部分为系统内核空间占用CPU百分比，一部分为用户空间占用CPU百分比。其中CPU状态中标示id的为空闲CPU百分比。当空闲CPU百分比越低，说明CPU占用率越高。 2）目前针对Linux下java进程占用CPU高的分析手段主要为使用linux命令查出高CPU使用的进程，前分析其是由于进程原因还是系统原因，在分析出为进程消耗过高CPU后列出占用CPU高和占用时间最长的线程并使用jdk自带的jstack工具进行分析CPU使用分析。 jstack命令 通过top命令定位到cpu占用率较高的线程之后，继续使用 jstack pid 命令查看当前java进程的堆栈状态 参数说明： -l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent 的 ownable synchronizers列表. -F 当’jstack [-l] pid’没有相应的时候强制打印栈信息 -m 打印java和native c/c++框架的所有栈信息. -h | -help 打印帮助信息 jstack命令生成的thread dump信息包含了JVM中所有存活的线程，为了分析指定线程，必须找出对应线程的调用栈，应该如何找？在top命令中，已经获取到了占用cpu资源较高的线程pid

文章目录 授人以鱼不如授人以渔 目的 服务器资源 Tomcat配置优化 Linux环境安装运行Tomcat8 AJP连接 执行器（线程池） 3种运行模式 部署测试用的web项目 查看服务器信息 部署web应用 使用Apache JMeter进行性能测试 下载安装 修改语言 创建接口的测试用例 启动与进行接口测试 查看测试报告 调整Tomcat参数进行优化 禁用AJP连接 设置线程池 最大线程数为150，初始为4 最大线程数为500，初始为50 最大线程数为1000，初始为200 最大线程数为5000，初始为1000 设置最大等待队列数 设置nio2的运行模式 参数说明与最佳实践 执行器参数说明(加粗是重点) 执行器最佳实践 连接器参数说明 通用属性(加粗是重点) 标准实现(加粗是重点) 连接器最佳实践 调整JVM参数进行优化 设置并行垃圾回收器 查看gc日志文件 调整年轻代大小 设置G1垃圾回收器 JVM配置最佳实践 总结 授人以鱼不如授人以渔 本博客的目的不在于给出最佳配置，而是带领开发者，能够从实际情况出发，通过不断的调节tomcat和jvm参数，去发现吞吐量，平均响应时间和错误率等信息的变化，同时根据服务器的cpu和内存等信息，结合接口的业务逻辑，最好是测试使用率最高，并发最大，或者是最重要的接口(比如下单支付接口)，设置最优的tomcat和jvm配置参数。 目的

不论是哪一种语言，并发编程都是一项非常重要的技巧。比如我们上一章用的爬虫，就被广泛用在工业的各个领域。我们每天在各个网站、App上获取的新闻信息，很大一部分都是通过并发编程版本的爬虫获得的。 正确并合理的使用并发编程，无疑会给我们的程序带来极大性能上的提升。今天我们就一起学习Python中的并发编程——Futures。 区分并发和并行 我们在学习并发编程时，常常会听到两个词：并发(Concurrency)和并行(Parallelism)这两个术语。这两者经常一起使用，导致很多人以为他们是一个意思，其实是不对的。 首先要辨别一个误区，在Python中， 并发 并不是只同一时刻上右多个操作(thread或者task)同时进行。相反，在某个特定的时刻上它只允许有一个操作的发生，只不过线程或任务之间会相互切换直到完成，就像下面的图里表达的 在上图中出现了task和thread两种切换顺序的不同方式。分别对应了Python中并发两种形式——threading和asyncio。 对于线程，操作系统知道每个线程的所有信息，因此他会做主在适当的时候做线程切换，这样的好处就是代码容易编写，因为程序员不需要做任何切换操作的处理；但是切换线程的操作，有可能出现在一个语句的执行过程中( 比如X+=1)，这样比较容易出现race condiiton的情况。 而对于asyncio

作者：Kindle君 时间：2017年4月12日。 出处： http://blog.csdn.net/yexiaogu1104/article/details/69055802 声明：版权所有，转载请联系作者并注明出处 本文记录可成功安装TensorFlow的步骤，包括Centos 7 和Windows 10。具体请参考 TensorFlow 。另外，介绍了一下GitHub的使用。最后，跑通了DCGAN的demo。希望和大家一起交流学习！ 1、TensorFlow安装步骤及问题 1.1 linux下使用virtualenv进行安装 步骤 指令 结果或问题 1.通过发出以下命令安装pip和virtualenv： sudo yum install python-py python-devel python-virtualenv 1.yum不能使用 –>>检查python配置路径是否正确。 2.centos下yum中不叫python-dev，而是python-devel. 2.通过发出以下命令创建一个virtualenv环境： sudo virtualenv –system-site-packages /storage/hesiying/hesiying/tensorflow-virtualenv/ 1.注意使用sudo. 2.安装提示： a.New_python_executable

一个应用占用CPU很高，除了确实是计算密集型应用之外，通常原因都是出现了死循环。 下面我们将一步步定位问题，详尽的介绍每一步骤的相关知识。 一、通过top命令定位占用cpu高的进程 执行top命令得到以下结果： top命令查询结果 通过上图可以明显看出进程PID41843占用cpu过高，明显存在问题，定位到了进程id。当然如果你想只观察进程PID41843的CPU和内存以及负载情况，可以使用以下命令 top -p 41843 结果如下： top -p 41843命令执行结果 这里顺便解释下上图各个参数的意义，有利于读者更好的排查问题。 1.第一行是任务队列信息 top - 14:06:34 up 537 days, 6 min, 6 users, load average: 0.41, 0.45, 0.43 2.第二行为进程的信息 3.第三行为cpu信息 4.第四、五行为内存信息。 内容如下： 二、通过top命令定位问题进程中每个线程占用cpu情况 通过问题进程中每个线程占用cpu情况使用可以使用如下命令： top -p 41843 -H 查看进程PID41843的每一个线程占用CPU情况，如图。 top -p 41843 -H的执行结果 由上图明显可以发现，线程PID41892CPU占用率最高，接下来定位该线程的代码是否出现异常导致cpu占用过高。 三、通过jstack

# uname -a # 查看内核/操作系统/CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat /proc/cpuinfo # 查看CPU信息 # hostname # 查看计算机名 # lspci -tv # 列出所有PCI设备 # lsusb -tv # 列出所有USB设备 # lsmod # 列出加载的内核模块 # env # 查看环境变量 资源 # free -m # 查看内存使用量和交换区使用量 # df -h # 查看各分区使用情况 # du -sh <目录名> # 查看指定目录的大小 # grep MemTotal /proc/meminfo # 查看内存总量 # grep MemFree /proc/meminfo # 查看空闲内存量 # uptime # 查看系统运行时间、用户数、负载 # cat /proc/loadavg # 查看系统负载 磁盘和分区 # mount | column -t # 查看挂接的分区状态 # fdisk -l # 查看所有分区 # swapon -s # 查看所有交换分区 # hdparm -i /dev/hda # 查看磁盘参数(仅适用于IDE设备) # dmesg | grep IDE # 查看启动时IDE设备检测状况 网络 # ifconfig # 查看所有网络接口的属性 #

问题 1：大量块丢失 (gc lost blocks, gc current/cr lost blocks) 症状 I. AWR 报告中显示有大量块丢失。 II. netstat -s 报告数据包重新组装故障（reassambly failure）和丢失数据包（dropped packets）增加。 解决方案 使用以下文档进行故障排除并解决丢失块问题。该文档描述了症状、可能原因以及解决方案。 Document 563566.1 - gc block lost diagnostics 问题 2：大量 log file sync 等待 症状 I. AWR 报告中显示 log file sync 始终位于 Top 5 等待事件列表中。 II. 平均 log file sync 时间很长（> 20 毫秒）。 III. 平均 log file parallel write 时间很长（> 10 毫秒）。 III. 平均 redo write broadcast ack time 或者 wait for scn ack 时间很长（> 10 毫秒）。 IV. 平均 log file sync 时间很短，但 log file sync 等待次数太多。 背景 用户会话在提交或回退时，会话的重做信息需要由 LGWR 刷新到重做日志文件。用户会话等待“log file sync”的同时，等待 LGWR

——增大/dev/random的熵池。问题的原因是由于熵池不够大，所以增大它是最彻底的方法。 通过 cat /proc/sys/kernel/random/entropy_avail 我们可以查看现在的熵池大小；我们需要找到一种方式来提高这个值就行了。如果你的CPU带有DRNG特性，可以充分利用硬件来提高熵池产生的速度 。通过 cat /proc/cpuinfo | grep rdrand 可以查看自己的CPU是否支持，一般来说Intel的Ivy_Bridge架构的CPU都支持（i3、i5需要注意是否采用该种架构，i7和xeon基本上都支持）；AMD的CPU在2015年以后生成的都支持。（如果你是虚拟机需要开启额外的参数)。如果你的硬件不支持，也没有关系，我们可以让/dev/unrandom来做“熵源”。 Ubuntu apt-get install rng-tools 安装rngd服务（熵服务） service rng-tools start 启动服务 来源： CSDN 作者： Joker_Ye 链接： https://blog.csdn.net/hj7jay/article/details/60127995