Posted on | In

参考文章

查看使用库源码

Command+B，就可以很方便的跳转到源码里的类，方法，函数，变量的定义。

让你的代码 PEP8

Command+Option+L，一键 pep8 走起

安装库

1
PyCharm->Preferences->Project:xxx->Project Interpreter->点击+

查找文件，类， 方法

查找文件：Command + Shift + O

查找类：Command + O

查找打开最近编辑过的文件：Ctrl+Shift+E

万能搜索：连续按两下 Shitf键可以搜索文件名、类名、方法名，还可以搜索目录名，搜索目录的技巧是在在关键字前面加斜杠/。

文件内容查找

全局内存查找快捷键为Ctrl + Shift + F。当前文件查找快捷键为Ctrl + F。

快速选择代码块

在需要选择某个函数的时候，只需要把光标放在最前面，然后点击 Command + Option + Shift + ]，就可以选择对当前代码块, 使用 Command + /注释。

快速插入常用代码

Command + J

展开/收缩代码

Command + Shift + -符号 来收缩代码

展示多个页面

鼠标放到当前导航处的文件名，然后右键 Split Vertically 或者 Split Horizontally就可以啦。

函数调用层级可视化

选择函数，control+option+H

实时显示文档和函数参数

通过快捷键 F1 可以调出光标处函数文档，Command+P 可以显示出光标处函数参数。

历史性粘贴板

如果你是Mac用户，一定熟悉 Alfred， Alfred是一款历史粘贴板神器，它缓存了过去一段时间的复制的内容，在 Pycharm 中可通过Ctrl + Shift + V可访问历史粘贴板。

任意位置换行

无论你的光标处在何位置，你都可以通过快捷键Shfit + Enter另起一行，这样无需把光标移到末尾去操作。

Posted on | In

CPU性能指标

性能工具

  • 从CPU性能指标出发，当你查看到性能指标时，可以明确知道使用哪个性能工具。
  • 如果已经安装性能工具，要知道工具可以提供哪些指标。

快速定位CPU问题

Posted on | In

例子说明

  • 比如订了一份外卖，你跟配送员预定了，让他送到了以后给你打电话，这样你不用站在家门口一直干等着他什么时候到。你可以在这个时间里去做别的事情。在这里“打电话”其实就是一个中断，没接到电话的时候，你可以做其他事情；只有接到了电话(也就是发送了中断)，你才要进入另外一个动作：取外卖。
  • 在这个例子你可以发现：中断其实是一种异步的事件处理机制，可以提高系统的并发处理能力。
  • 由于中断处理程序会打断其他进程的运行，所以，为了减少对正常进程运行调度的影响，中断处理程序就需要尽可能快地运行。特别的，中断处理程序在响应中断时，还会临时关闭中断。这就会导致上一次中断处理完成之前，其他中断都不能响应，也就是说中断可能有丢失。
  • 比如你订了2份外卖，第一份外卖到了，此时接到电话一直在商量发票的问题，结果第二个外卖到了以后由于占线无法拨通你的电话。所以你就错过了第二份外卖(中断丢失)。

理解软中断

  • 实际上为了解决中断处理程序执行过长或者中断丢失的问题，Linux将中断处理过程分成了两个阶段，也就是上半部和下半部：

    • 上半部用来快速处理中断，它在中断禁止模式下运行，主要处理跟硬件紧密相关的或时间敏感的工作。
    • 下半部用来延迟处理上半部未完成的工作，通常以内核线程的方式运行。

  • 比如说前面取外卖的例子，上半部就是你接听到电话，告诉配送员你已经知道，挂掉电话后当面商量。下半部才是取外卖的动作。这样第一个配送员不会占用你太多时间，第二个配送员过来时，照样可以打通你的电话。

  • 又比如网卡接收到数据包以后，会通过硬件中断的方式，通知内核有新的数据到了，这时，内核就应该调用中断处理程序来响应它。那么这里的上半部就是把网卡的数据读到内存中，然后更新一下硬件寄存器的状态，最后再发送一个软中断信号，通知下半部做进一步处理。
  • 实际上，上半部会打断CPU正在执行的任务，然后即可执行中断处理程序。而下半部以内核线程的方式执行，并且每个CPU都对应一个软中断内核线程，名字为ksofitirqd/CPU编号，比如1号CPU对应的软中断内核线程的名字就是ksoftirqd/1

查看软中断

  • /proc/softirqs提供了软中断的运行情况。
  • /proc/interrupts提供了硬中断的运行情况。
1
2
3
4
5
6
7
8
9
10
11
12
$ cat /proc/softirqs
                    CPU0       CPU1
          HI:          0          0
       TIMER:     811613    1972736
      NET_TX:         49          7
      NET_RX:    1136736    1506885
       BLOCK:          0          0
    IRQ_POLL:          0          0
     TASKLET:     304787       3691
       SCHED:     689718    1897539
     HRTIMER:          0          0
         RCU:    1330771    1354737
  • 在查看/proc/softirqs文件内容时，特别要注意：
    • 第一列内容为中断的类型，可以看到有10种类型的中软断，分别对应不同的工作类型，比如NET_RX表示网络接收中断, NET_TX表示网络发送中断。
    • 第二列为中断在CPU上的累计次数。一般同一种类型的软中断，在每个CPU的累计次数相差不大，在同一个数量级，比如NET_RX。

Posted on | In

技术人的思考进阶

互联网技术是一个很奇妙的世界，时不时探索未知领域，让你充满期待。打开你的谷歌浏览器，浏览着国外的官方英文文献，听着有旋律的键盘和鼠标声，瞬时觉得是一种美好的享受。

我想做技术太久始终会有其瓶颈，就像瓶子里的水，始终会装满，难以突破它固有的容量。瓶子外的世界其实很广阔，有很多机会。当然，夯实的技术基础还是很必要的，所以先踏实的在大型互联网公司做几年，掌握一定的技术基础。在此之上才能谈技术瓶颈问题。

关于技术变现的问题，的确值得思考。有大咖会出各种专业培训视频，会出版自己的书籍，会有自己的博客和公众号。这都是技术知识变现的最直接方式。当然，也有自己写互联网产品来出售，并负责售后的大神。做为高级工程师或资深工程师的你，我想会有很多方式变现。但，技术外的世界，我们也需要多花时间去经营。

依托技术优势，广交优秀人才，坦诚的交流。倘若能遇到一伙踏实的创业团队，敢于打破现有思维，挖掘新的机遇，打造有ideal的产品，何尝不是一次美好的事。

古人云：吾日三省吾身，着实很有道理。每一天都是的亲身经历，经历后的感悟应及时思考，并转化为文字进行记录。这样才能算积累，积累到一定程度，我相信你会有新的收获。

人的财富和技能应该呈不断上升的趋势，在坚持之时，也应适当高瞻远瞩，发展瓶外技能，比如创造第二桶金，成为健身达人。倘若发现在走下坡路，应及时调整自己，无论是身体还是技能。

在回家的高铁上，可以好好的休息和思考一下，很享受。不过用手机码字的体验的确让人奔溃。

顺便打个广告，欢迎光顾我的个人博客, 目前写的东西质量还有待提升，多包涵，欢迎交流～。

Posted on | In
  • 关于防火墙的数据流向规则和概念老是忘，所谓好记性不如烂笔头。所以今天特此来记一记。

iptable表与链

  • 链是规则或者策略的集合，一般默认有如下5种链：
链名 作用
INPUT 处理流入网卡的数据包
OUTPUT 处理流出网卡的数据包
FORWARD 处理转发的数据包
POSTROUTING 在进行路由选择后处理数据包
PREROUTING 在进行路由选择前处理数据包
  • 表是上述链的集合，具体是代表一类功能。
表名 作用
raw 对数据包进行状态跟踪
mangle 为数据设置标记
nat 修改数据中的源、目的IP或者端口
filter 过滤数据包或者对数据包进行处理

  • 表和链的结构如下：
    请在这里输入图片描述

  • 匹配顺序:

类型 顺序
表 raw -> mangle -> nat -> filter
链 链内规则按顺序以此检查，匹配到规则后停止继续往下匹配
  • 数据匹配流程图
    请在这里输入图片描述

Posted on | In

FreeBSD

  • 使用系统自带的geli命令对/home/test加密
  • 要将/mnt挂载点独立一个分区出来，以免手动调整分区
  • 如果是aws，则把数据盘EBS挂载到/home/test

首次创建加密盘

  1. aws的话先创建分区，记得先umount原来分区

  • AWS：用gpart创建分区

    1
    2
    3
    4
    # gpart create -s gpt xbd1
    xbd1 created
    # gpart add -t freebsd-ufs xbd1
    xbd1p1 added

  • 安装： 先将原本的/mnt umount

    1
    2
    3
    4
    5
    # df -ah
    /dev/mfid0p7        9.7G    164k    8.9G     0%    /home
    /dev/mfid0p8        518G     52k    477G     0%    /mnt

       # umount /mnt

  1. 创建口令

    1
    2
    3
    #geli init -s 4096 /dev/mfid0p8
    Enter new passphrase:
    Reenter new passphrase:

  2. 将口令与分区关联

    1
    2
    #geli attach /dev/mfid0p8
    Enter passphrase:

    完成后，将生成/dev/mfid0p8.eli设备

  3. 创建新文件系统并挂载

    1
    2
    #newfs -b 16384 -U /dev/mfid0p8.eli
    #mkdir /home/test && mount /dev/mfid0p8.eli /home/test

重启系统后恢复加密盘

  1. 将口令与分区关联

    1
    2
    #geli attach /dev/mfid0p8
    Enter passphrase:

    完成后，将生成/dev/mfid0p8.eli设备

  2. 挂载加密盘

    1
    #mount /dev/mfid0p8.eli /home/test

Debian

  • 采用cryptsetup（可能需要aptitude install cryptsetup）对/home/test加密,注意要将/mnt挂载点独立一个分区出来.

首次创建加密盘

  1. 先将原本的/mnt umount

    1
    2
    3
    4
    #df -ah
    /dev/sda7             9.9G  151M  9.2G   2% /home
    /dev/sda8             177G  189M  168G   1% /mnt
    #umount /mnt

  2. 格式化加密盘

    1
    2
    3
    4
    5
    6
    7
    8
    9
    #cryptsetup luksFormat /dev/sda8
    WARNING!
    ========
    This will overwrite data on /dev/sdb1 irrevocably.

    Are you sure? (Type uppercase yes): YES
    Enter LUKS passphrase:
    Verify passphrase:
    Command successful.

  3. 使用cryptsetup luksOpen命令打开加密分区.

    1
    2
    3
    4
    # cryptsetup luksOpen /dev/sda8 private
    Enter LUKS passphrase:
    key slot 0 unlocked.
    Command successful.

    完成后，生成/dev/mapper/private 设备

  4. 格式化设备并挂载

    1
    2
    3
    #mkfs.ext4 /dev/mapper/private
    #mkdir /home/test
    #mount /dev/mapper/private /home/test

5.编辑｀/etc/fstab｀，去掉对应条目

重启系统后恢复加密盘

  1. 使用cryptsetup luksOpen命令打开加密分区.

    1
    2
    3
    4
    # cryptsetup luksOpen /dev/sda8 private
    Enter LUKS passphrase:
    key slot 0 unlocked.
    Command successful.

    完成后，生成/dev/mapper/private 设备

  2. 挂载

    1
    #mount /dev/mapper/private /home/test

Posted on | Edited on | In

节拍率

  • 为了维护CPU时间，Linux通过事先定义的节拍率(内核中表示HZ)来触发时间中断，并使用全局变量Jiffies来记录开机以后的节拍次数。每发生一次时间中断，jiffies的值就加1.

  • 节拍率HZ是内核的可配置参数，可以设置为100、250、1000等。而用户空间的节拍率USER_HZ固定为100，你可以通过/boot/config内核选项来查看。

    1
    grep 'CONFIG_HZ' /boot/config-$(uname -r)

  • 以下展示率各个CPU的节拍率，一般性能分析工具给出的都是间隔一段时间的平均CPU使用率，比如top是每隔3秒的平均值，PS使用的是整个进程的生命周期。

    1
    2
    3
    4
    5
    6
    # 只保留各个 CPU 的数据
    $ cat /proc/stat | grep ^cpu
    # 第一行表示的是所有CPU的累加，其他则是不同场景下CPU的累加节拍数，单位是USER_HZ(1/100秒)
    cpu  280580 7407 286084 172900810 83602 0 583 0 0 0
    cpu0 144745 4181 176701 86423902 52076 0 301 0 0 0
    cpu1 135834 3226 109383 86476907 31525 0 282 0 0 0

CPU使用率高如何定位？

  • 通过top、ps、pidstat定位具体是哪个进程的CPU高，是内核态还是用户态占用高。那如果找到了哪个进程占用CPU高，那如何定位到是哪个函数占用CPU高呢？

  • 我们一般不建议直接在线上环境使用GDB或者STRACE命令，毕竟会临时中断程序，那么我们可以使用perf命令来分析，工具安装：

    1
    2
    #perf工具安装
    sudo apt install linux-tools-common

  • perf top命令类似于top，它能够实时显示占用CPU时钟最多的函数或者指令，用来查找热点函数，如下界面：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    $ perf top
    Samples: 833  of event 'cpu-clock', Event count (approx.): 97742399
    Overhead  Shared Object       Symbol
       7.28%  perf                [.] 0x00000000001f78a4
       4.72%  [kernel]            [k] vsnprintf
       4.32%  [kernel]            [k] module_get_kallsym
       3.65%  [kernel]            [k] _raw_spin_unlock_irqrestore

    #如果采用太少，比如几十个的话，参考意义不大。
    #第一行包含三个数据，分别是采样数(Samples)、事件类型(event)、时间总数量(Event count)，这个例子中perf总共采集了833个CPU时钟事件、总事件数则为97742399。
    #第一列Overhead：代表该符合的性能事件在所有采用中的比例，用百分比表示。
    #第二列Shared：该函数或者指令所在的动态共享对象，如内核、进程名、动态链接库名、内核模块等。
    #第三列Object：动态共享对象的类型，比如[.]代表用户空间的可执行程序或者动态链接库，而[k]则表示内核空间。
    #第四列Symbol：符号名，也就是函数名，当函数名未知时，用十六进制的地址表示。

  • perf top不能离线分析，我们可以使用perf record top -g -p pid来进行采用，-g参数开启调用关系采用，在report中按方向键选中并回车可看到调用关系。

    1
    2
    3
    4
    $ perf record # 按 Ctrl+C 终止采样
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.452 MB perf.data (6093 samples) ]
    $ perf report # 展示类似于 perf top 的报告

如果找不到哪个进程CPU使用率高？

  • 碰到无法解释的CPU使用率情况时，首先要想到有可能是短时应用导致的问题，比如有下面2情况：
    • 应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过top等工具不容易发现。
    • 应用本身在不停地奔溃重启，而启动过程地资源初始化，很可能会占用相当多地CPU。
  • 对于这种情况，我们可以用pstree或者execsnoop找到它们地父进程，再从父进程所在应用入手，排查问题。

小结

  • 用户CPU和Nice CPU高，说明用户态进程占用CPU高，所以重点排查进程的性能问题。
  • 系统CPU高，说明内核态占用CPU高，应重点排查内核线程或者系统调用的性能问题。
  • I/O等待CPU高，说明等待I/O的时间比较长，应该重点排查系统存储是否有瓶颈。
  • 软中断或者硬中断高，说明软中断或者硬中断处理程序占用CPU高，应该重点排查内核的中断服务程序。

Posted on | In

基本概念

  • CPU上下文：即CPU在运行任何程序前所必须依赖的环境，即CPU寄存器和程序计数器。其中CPU寄存器是CPU内置的容量小、但速度极快的内存。而程序计数器则是用来存储CPU正在执行的指令位置、或者即将执行的下一条指令位置。
  • CPU上下文切换：即把前一个任务的CPU上下文（CPU寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。而前一个任务的CPU上下文会存储在系统内核中，并在重新调度是重新加载。
  • CPU上下文切换根据场景可以划分为三类：进程上下文切换、线程上下文切换、中断上下文切换。

进程上下文切换

  • 进程的上下文切换需要保存当前进程的内核状态、CPU寄存器、虚拟内存、栈等，每次进程上下文切换都需要几十纳秒到数微妙的CPU时间，当进程上下文切换次数较多时，很容易造成CPU将大量时间消耗在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间，这就是导致平均负载升高的一个重要原因。
  • 触发进程调度的原因有如下几个：
    • 当某个进程的时间片耗尽，会被系统挂起，切换到其他正在等待CPU的进程运行。
    • 进程在系统资源不足（比如内存不足）时，要等资源满足后才可以运行，这个时候进程会被挂起，并由系统调度其他的进程运行。
    • 进程通过睡眠函数将自己主动挂起。
    • 出现优先级更高的进程运行时，当前进程被挂起，由高优先级进程先运行。
    • 发生硬件中断，CPU上的进程会被中断挂起，转而执行内核中的中断服务程序。

线程上下文切换

  • 线程和进程简要区别：
    • 当进程只有一个线程，则进程就等于线程。
    • 当进程拥有多个线程，这些线程会共享相同的虚拟内存和全局变量等资源，这些资源在上下文切换时是不需要修改的。
    • 线程也由自己的私有数据，比如栈和寄存器等，这些在上下文切换时也需要保存。
  • 线程上下文切换的两种情况：
    • 前后两个线程属于不同进程，此时由于资源不共享，所以切换过程和进程上下文切换一致。
    • 前后两个线程属于同个进程，此时因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。同进程内的线程切换要比多进程间的切换消耗更少的资源。

中断上下文切换

  • 跟进程上下文不同，中断上下文切换并不涉及到进程的用户态，所以不需要保存这个进程的虚拟内存、全局变量等用户态资源。只需要内核态中断服务程序执行所需的基本资源，比如CPU寄存器、内核堆栈、硬件中断参数等。
  • 中断上下文切换也需要消耗CPU，所以切换次数过多也会消耗大量的CPU，导致性能降低。

常用工具

  • 查看系统整体的上下文切换情况。

    1
    2
    3
    4
    5
    6
    7
    8
    # 每隔 5 秒输出 1 组数据
    $ vmstat 5
    procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
     0  0      0 7005360  91564 818900    0    0     0     0   25   33  0  0 100  0  0

    #cs(context switch) 是每秒上下文切换的次数。
    #in(interrupt)则是每秒中断的次数。

  • 查看每个进程的详细情况。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    # 每隔 5 秒输出 1 组数据
    $ pidstat -w 5
    Linux 4.15.0 (ubuntu)  09/23/18  _x86_64_  (2 CPU)

    08:18:26      UID       PID   cswch/s nvcswch/s  Command
    08:18:31        0         1      0.20      0.00  systemd
    08:18:31        0         8      5.40      0.00  rcu_sched

    #cswch: 每秒自愿上下文切换的次数。
    #nvcswch: 每秒非自愿上下文切换的次数。

  • 自愿上下文切换：指进程无法获取所需自愿，导致上下文切换。比如：I/O、内存等系统自愿不足时，会发生自愿上下文切换。

  • 非自愿上下文切换：指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如大量进程都在争抢CPU，就容易发生非自愿上下文切换。

总结

  • 无论那种场景的上下文切换，你需要明白：
    • CPU上下文切换是保证Linux系统正常工作的核心功能之一，一般不需要特别关注。
    • 过多的上下文切换会把CPU时间消耗在寄存器、内核栈、虚拟内存等数据的保存和恢复上，从而缩短进程真正的运行时间，导致系统的整体性能下降。

Posted on | In

概念

  • 平均负载是指单位时间内，系统处于可运行状态和不可中断状态(等待CPU或者等待I/O)的平均进程数，也就是平均活跃进程数，它和CPU使用率并没有直接关系,直观上理解就是单位时间内的活跃进程数，但它实际上是活跃进程数的指数衰减平均值。下面解释一下可运行状态和不可中断状态。

    • 可运行状态的进程，是指正在使用CPU或者正在等待CPU的进程，也就是PS命令中看到的R状态的进程。
    • 不可中断状态的进程则是正处于内核态关键流程中的进程，并且不可被打断，比如等待硬件设备的I/O响应，也就是PS命令中看到的D状态进程。

  • 来一个直观的数据理解，比如平均负载为2时，意味着：

    • 在只有2个CPU的系统上，代表所有的CPU都刚好被完全用完。
    • 在4个CPU的系统上，意味着CPU有50%的空闲。
    • 在只有1个CPU的系统中，意味着有一半的进程竞争不大CPU。

相关工具

  • 下面展示一下排查CPU负载时常用工具：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    # 查看哪颗CPU占用高，-P ALL 表示监控所有CPU，后面数字 5 表示间隔 5 秒后输出一组数据
    $ mpstat -P ALL 5
    Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU)
    13:30:06     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
    13:30:11     all   50.05    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   49.95
    13:30:11       0    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
    13:30:11       1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

    # 查看具体是哪个进程占用CPU高，间隔 5 秒后输出一组数据
    $ pidstat -u 5 1
    13:37:07      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
    13:37:12        0      2962  100.00    0.00    0.00    0.00  100.00     1  stress

总结

  • 平均负载只是表现了系统整体的负载情况，但是只看平均负载本身，并不能明确是哪里出现了问题，所以还需要关注以下因素：
    • 平均负载高可能是CPU密集型进程导致。
    • 平均负载高并不一定代表CPU利用率高，可能是I/O比较繁忙。
    • 可以是呀mpstat、pidstat工具进一步分析。