cpu参数

先来点理论基础 系统crash时，HPUX会尝试将物理内存(core)或是物理内存的部分的映像保存到dump设备上，这个dump设备是预先定义好的。然后，在紧接着的操作系统重起过程中，名为savecrash的工具被rc-script自动调用，将内存映像及当前kernel由dump设备拷贝到文件系统中。完成后，你就可以通过调试工具对其进行分析。如下图. Crash事件 - Crash events 一个非正常的系统重起就叫做crash. 有很多原因会导致系统crash; 硬件的不正常工作，软件混乱甚至电源故障。 在一个正确配置的系统中，这些通常会导致一个crash dump被保存下来。操作系统记录每个crash事件的原因，通常每个CPU都会有一个crash事件。同一个CPU有多个事件也是可能的。 共有三种类型的Crash: PANIC, TOC and HPMC : PANIC PANIC类型的crash说明这是由HPUX 操作系统触发的(软件Crash事件). 我们将它分为直接panic与非直接panic(direct and indirect panics). 直接panic是由一个子系统在检测到一个不可恢复的错误时直接调用panic()核心进程，例如: . panic ("wait_for_lock: Already own this lock!"); . panic ("m

对于我们开发来说，我们日常最熟悉的工作就是把客户的需求实现并交付。但是，事情并不是往往就这样结束了，我们还需要后续对上线的系统进行跟踪调查，查看系统的运行情况。为什么呢？一方面，我们需要关注系统在运行过程中的健康问题，是否有异常等等；另一方面我们需要了解系统性能和容量是否能满足用户的日常访问。只有去了解线上系统的运行状况，才能让为后续项目提供参考，及早的调节以避免故障问题。 对于应用系统在线上出现的异常，我们可以通过监控系统的日志扫描或者一些监控api来进行异常监控。比如可以通过应用的监控系统来查看。对于性能方面，我们有哪些性能指标去关注呢，下面列出了几个在监控系统中最常用的性能指标。 PV PV是 Page View的缩写。用户通过浏览器访问页面，对应用服务器产生的每一次请求， 记为一个 PV。淘宝性能测试环境下，将这个概念做了延伸，系统真实处理的一个请求，视 为一个 PV。即，PV的概念也适用于接口。 PV的统计一般可以通过监控埋点或者统计访问日志统计得出。 说到PV还有个特殊的情况，叫PeakPV，指一天中 PV数达到的高峰PV值。 通过一些监控系统，也可以直观看到统计数据。 QPS/TPS QPS/TPS原本含义为：系统每秒能处理的请求/事务的数量，或者说吞吐量。在web应用我们更关注的是web应用每秒能处理的request数量。这个是衡量系统性能的重要指标。 QPS

背景 高性能应用构成了现代网络的支柱。LinkedIn 内部有许多高吞吐量服务来满足每秒成千上万的用户请求。为了获得最佳的用户体验，以低延迟响应这些请求是非常重要的。 例如，我们的用户经常使用的产品是 Feed —— 它是一个不断更新的专业活动和内容的列表。Feed 在 LinkedIn 的系统中随处可见，包括公司页面、学校页面以及最重要的主页资讯信息。基础 Feed 数据平台为我们的经济图谱（会员、公司、群组等）中各种实体的更新建立索引，它必须高吞吐低延迟地实现相关的更新。如下图，LinkedIn Feeds 信息展示： 为了将这些高吞吐量、低延迟类型的 Java 应用程序用于生产，开发人员必须确保在应用程序开发周期的每个阶段都保持一致的性能。确定最佳垃圾收集（Garbage Collection, GC）配置对于实现这些指标至关重要。 这篇博文将通过一系列步骤来明确需求并优化 GC，它的目标读者是对使用系统方法进行 GC 优化来实现应用的高吞吐低延迟目标感兴趣的开发人员。在 LinkedIn 构建下一代 Feed 数据平台的过程中，我们总结了该方法。这些方法包括但不限于以下几点：并发标记清除（Concurrent Mark Sweep，CMS（参考[2]） 和 G1（参考 [3]） 垃圾回收器的 CPU 和内存开销、避免长期存活对象导致的持续 GC、优化 GC

转自： https://mp.weixin.qq.com/s/1XSbEmbIYTfn_UdyNecH6Q Linux 命令好像还真不少，根本原因就是软件多，也有像 ag 这样的命令想替代 grep ,但大多数命令古老而坚挺。不是因为这些软件设计的有多好，原因是一些软件最开始入驻了系统，时间久了，就变成了一种约定，这种习惯改变代价太大，就像把所有键盘的 L 和 F 换一下一样。 这片文章假定你已经了解大多数Linux命令，并了解操作系统的基本元素。如果你现在了解的命令还不足10个，下面的内容就不用看了。除了最基本的东西，本文列出一些对你的面试最常见的最能加分的地方，有些组合可能是你没见过的技巧。但本文仅仅是给出一个大致的轮廓和印象，为以后的专题性考察点作一个序。 本文中出现的所有命令，应该熟记并熟练使用。 几种比较典型的Linux系统 首先对目前的Linux版本有个大体的印象，大体分Desktop版和Server版，已经是百花齐放。 Ubuntu 最常见的Linux个人发行版，一位有情怀的南非富豪，有了钱你也可以这么做 CentOS 最常用Linux服务器发新版，RHEL的开放版本，因版权而生的轮子 Arch 滚动升级，海量二进制包，社区活跃，个人最爱 Gentoo 安装软件需要从源码开始编译，稳定，但用起来会很痛 LFS 从零构建Linux，跟着做一遍

作者 | 肖长军（穹谷）阿里云智能事业群技术专家 导读 ：随着云原生系统的演进，如何保障系统的稳定性受到很大的挑战，混沌工程通过反脆弱思想，对系统注入故障，提前发现系统问题，提升系统的容错能力。ChaosBlade 工具可以通过声明式配置执行混沌实验，简单高效。本文将会重点介绍 ChaosBlade 以及云原生相关的实验场景实践。 ChaosBlade 介绍 ChaosBlade 是阿里巴巴开源的一款遵循混沌实验模型的混沌实验执行工具，具有场景丰富度高、简单易用等特点，而且可以很方便的扩展实验场景，开源后不久就被加入到 CNCF Landspace 中，成为主流的一款混沌工具。 实验场景 目前支持的实验场景如下： 基础资源场景：CPU 负载、内存占用、磁盘 IO 负载、磁盘占用、网络延迟、网络丢包、网络屏蔽、域名不可访问、shell 脚本篡改、杀进程、进程 Hang、机器重启等； 应用服务场景：支持 Java 应用和 C++ 应用内的实验场景。Java 的场景组件丰富，例如支持 Dubbo、RocketMQ、HttpClient、Servlet、Druid等，而且支持编写 Java 或 Groovy 脚本实现复杂的实验场景； 容器服务场景：支持 Kubernetes 和 Docker 服务，包含 node、pod 和 container 三种资源的实验场景，例如 Pod 网络延迟

tomcat 的Connector配置如下 <</span>Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443"maxThreads="800" acceptCount="1000"/> 其中最后两个参数意义如下： maxThreads ：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200 acceptCount ：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100 这两个值如何起作用，请看下面三种情况 情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。 情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。 情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused maxThreads如何配置 一般的服务器操作都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等） 第一种极端情况，如果我们的操作是纯粹的计算，

程序员需要了解的硬核知识之磁盘 https://www.cnblogs.com/cxuanBlog/p/11776310.html 此篇文章是 《程序员需要了解的硬核知识》系列第四篇，历史文章请戳 程序员需要了解的硬核知识之内存 程序员需要了解的硬核知识之CPU 程序员需要了解的硬核知识之二进制 我们大家知道，计算机的五大基础部件是 存储器 、 控制器 、 运算器 、 输入和输出设备 ，其中从存储功能的角度来看，可以把存储器分为 内存 和 磁盘 ，内存我们上面的文章已经介绍过了，那么此篇文章我们来介绍一下磁盘以及内存和磁盘的关系。 认识磁盘 首先，磁盘和内存都具有存储功能，它们都是存储设备。区别在于，内存是通过 电流 来实现存储；磁盘则是通过 磁记录技术 来实现存储。内存是一种高速，造假昂贵的存储设备；而磁盘则是速度较慢、造假低廉的存储设备；电脑断电后，内存中的数据会丢失，而磁盘中的数据可以长久保留。内存是属于 内部存储设备 ，硬盘是属于 外部存储设备 。一般在我们的计算机中，磁盘和内存是相互配合共同作业的。 一般内存指的就是主存（负责存储CPU中运行的程序和数据）；早起的磁盘指的是软磁盘（soft disk，简称软盘），就是下面这个 （2000年的时候我曾经我姑姑家最早的计算机中见到过这个，当时还不知道这是啥，现在知道了。） 如今常用的磁盘是硬磁盘（hard disk，简称硬盘）

AWR报告参数：DB TIME和DB CPU http://blog.itpub.net/12679300/viewspace-1182396/ 一、前言： AWR报告是了解ORACLE运行的一个重要报告，CPU的使用情况是AWR报告的一个重要指标，本文档从单个CPU的维度去解读AWR报告； 二、重要参数介绍： DB Time：Amount of elapsed time (in microseconds) spent performing Database user-level calls. This does not include the elapsed time spent on instance background processes such as PMON. 说明： DB TIME= 所有前台 session 花费在 database 调用上的总和时间 ?注意是前台进程 foreground sessions ?包括 CPU 时间、 IO Time 、和其他一系列非空闲等待时间，别忘了 cpu on queue time 公式：DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue （思考DB TIME的定义为指定的是前台session ） DB CPU：Amount of CPU time (in

Redis的数据回写机制 Redis的数据回写机制分同步和异步两种， 同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。 异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。 个人感觉方法２采用fork主进程的方式很拙劣，但似乎是唯一的方法。内存中的热数据随时可能修改，要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像，这样主进程上就不需要冻结，只要子进程上操作就可以了。 在小内存的进程上做一个fork,不需要太多资源，但当这个进程的内存空间以Ｇ为单位时，fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢？肯定会报内存无法分配的。更可气的是，越是改动频繁的主机上fork也越频繁，fork操作本身的代价恐怕也不会比假死好多少。 找到原因之后，直接修改/etc/sysctl.conf内核参数vm.overcommit_memory= 1 sysctl -p Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。 vm.overcommit_memory = 0：则比较

假设我们只保存了模型的参数(model.state_dict())到文件名为modelparameters.pth, model = Net() 1. cpu -> cpu或者gpu -> gpu: checkpoint = torch.load(‘modelparameters.pth‘) model.load_state_dict(checkpoint) 2. cpu -> gpu 1 torch.load(‘modelparameters.pth‘, map_location = lambda storage , loc : storage . cuda ( 1 )) 3. gpu 1 -> gpu 0 torch . load ( ‘modelparameters.pth‘ , map_location = { ‘cuda:1‘ : ‘cuda:0‘ }) 4. gpu -> cpu torch . load ( ‘modelparameters.pth‘ , map_location = lambda storage , loc : storage ) 原文：https://www.cnblogs.com/qinduanyinghua/p/9311361.html