分类 技术 下的文章

服务器日志是一个由服务器创建并经常更新、用于抓取特定服务和应用的所有活动信息的日志文件。当你的应用或者服务出现问题时这个文件就会非常有用。从日志文件中你可以获取所有关于该问题的信息,例如基于警告或者错误信息它什么时候开始表现不正常。

LNAV(Log file Navigator)是 Linux 下一个基于控制台的高级日志文件查看器。它和其它文件查看器,例如 cat、more、tail 等,完成相同的任务,但有很多普通文件查看器没有的增强功能(尤其是它自带多种颜色和易于阅读的格式)。

它能在解压多个压缩日志文件(zip、gzip、bzip)的同时把它们合并到一起进行导航。基于消息的时间戳,lnav 能把多个日志文件合并到一个视图(Single Log Review),从而避免打开多个窗口。左边的颜色栏帮助显示消息所属的文件。

警告和错误的数量以(黄色和红色)高亮显示,因此我们能够很轻易地看到问题出现在哪里。它会自动加载新的日志行。

它按照消息时间戳排序显示所有文件的日志消息。顶部和底部的状态栏会告诉你位于哪个日志文件。如果你想按特定的模式查找,只需要在搜索弹窗中输入就会即时显示。

内建的日志消息解析器会自动从每一行中发现和提取详细信息。

当你用一个普通文件查看器打开一个日志文件时,它会用纯文本格式显示所有信息(如果用更直白的话说的话:纯白——黑底白字),这样很难去发现和理解哪里有警告或错误信息。为了克服这种情况,快速找到警告和错误信息来解决问题, lnav 是一个入手可用的更好的解决方案。

大部分常见的 Linux 日志文件都放在 /var/log/

lnav 自动检测以下日志格式

  • Common Web Access Log format(普通 web 访问日志格式)
  • CUPS page\_log
  • Syslog
  • Glog
  • VMware ESXi/vCenter 日志
  • dpkg.log
  • uwsgi
  • “Generic” – 以时间戳开始的任何消息
  • Strace
  • sudo
  • gzib & bizp

lnav 高级功能

  • 单一日志视图 - 基于消息时间戳,所有日志文件内容都会被合并到一个单一视图
  • 自动日志格式检测 - lnav 支持大部分日志格式
  • 过滤器 - 能进行基于正则表达式的过滤
  • 时间线视图
  • 适宜打印视图(Pretty-Print)
  • 使用 SQL 查询日志
  • 自动数据抽取
  • 实时操作
  • 语法高亮
  • Tab 补全
  • 当你查看相同文件集时可以自动保存和恢复会话信息。
  • Headless 模式

如何在 Linux 中安装 lnav

大部分发行版(Debian、Ubuntu、Mint、Fedora、suse、openSUSE、Arch Linux、Manjaro、Mageia 等等)默认都有 lnav 软件包,在软件包管理器的帮助下,我们可以很轻易地从发行版官方仓库中安装它。对于 CentOS/RHEL 我们需要启用 EPEL 仓库

[在 Debian/Ubuntu/LinuxMint 上安装 lnav]
$ sudo apt-get install lnav

[在 RHEL/CentOS 上安装 lnav]
$ sudo yum install lnav

[在 Fedora 上安装 lnav]
$ sudo dnf install lnav

[在 openSUSE 上安装 lnav]
$ sudo zypper install lnav

[在 Mageia 上安装 lnav]
$ sudo urpmi lnav

[在基于 Arch Linux 的系统上安装 lnav]
$ yaourt -S lnav

如果你的发行版没有 lnav 软件包,别担心,开发者提供了 .rpm.deb 安装包,因此我们可以轻易安装。确保你从 开发者 github 页面 下载最新版本的安装包。

[在 Debian/Ubuntu/LinuxMint 上安装 lnav]
$ sudo wget https://github.com/tstack/lnav/releases/download/v0.8.1/lnav_0.8.1_amd64.deb
$ sudo dpkg -i lnav_0.8.1_amd64.deb

[在 RHEL/CentOS 上安装 lnav]
$ sudo yum install https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

[在 Fedora 上安装 lnav]
$ sudo dnf install https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

[在 openSUSE 上安装 lnav]
$ sudo zypper install https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

[在 Mageia 上安装 lnav]
$ sudo rpm -ivh https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

不带参数运行 lnav

默认情况下你不带参数运行 lnav 时它会打开 syslog 文件。

# lnav

使用 lnav 查看特定日志文件

要用 lnav 查看特定的日志文件,在 lnav 命令后面添加日志文件路径。例如我们想看 /var/log/dpkg.log 日志文件。

# lnav /var/log/dpkg.log

用 lnav 查看多个日志文件

要用 lnav 查看多个日志文件,在 lnav 命令后面逐个添加日志文件路径,用一个空格隔开。例如我们想查看 /var/log/dpkg.log/var/log/kern.log 日志文件。

左边的颜色栏帮助显示消息所属的文件。另外顶部状态栏还会显示当前日志文件的名称。为了显示多个日志文件,大部分应用经常会打开多个窗口、或者在窗口中水平或竖直切分,但 lnav 使用不同的方式(它基于日期组合在同一个窗口显示多个日志文件)。

# lnav /var/log/dpkg.log /var/log/kern.log

使用 lnav 查看压缩的日志文件

要查看并同时解压被压缩的日志文件(zip、gzip、bzip),在 lnav 命令后面添加 -r 选项。

# lnav -r /var/log/Xorg.0.log.old.gz

直方图视图

首先运行 lnav 然后按 i 键切换到/出直方图视图。

查看日志解析器结果

首先运行 lnav 然后按 p 键打开显示日志解析器结果。

语法高亮

你可以搜索任何给定的字符串,它会在屏幕上高亮显示。首先运行 lnav 然后按 / 键并输入你想查找的字符串。为了测试,我搜索字符串 Default,看下面的截图。

Tab 补全

命令窗口支持大部分操作的 tab 补全。例如,在进行搜索时,你可以使用 tab 补全屏幕上显示的单词,而不需要复制粘贴。为了测试,我搜索字符串 /var/log/Xorg,看下面的截图。


via: http://www.2daygeek.com/install-and-use-advanced-log-file-viewer-navigator-lnav-in-linux/

作者:Magesh Maruthamuthu 译者:ictlyh 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Inxi 最初是为控制台和 IRC(网络中继聊天)开发的一个强大且优秀的命令行系统信息脚本。可以使用它获取用户的硬件和系统信息,它也用于调试或者社区技术支持工具。

使用 Inxi 可以很容易的获取所有的硬件信息:硬盘、声卡、显卡、网卡、CPU 和 RAM 等。同时也能够获取大量的操作系统信息,比如硬件驱动、Xorg 、桌面环境、内核、GCC 版本,进程,开机时间和内存等信息。

运行在命令行和 IRC 上的 Inxi 输出略有不同,IRC 上会有一些可供用户使用的默认过滤器和颜色选项。支持的 IRC 客户端有:BitchX、Gaim/Pidgin、ircII、Irssi、 Konversation、 Kopete、 KSirc、 KVIrc、 Weechat 和 Xchat 以及其它的一些客户端,它们具有展示内置或外部 Inxi 输出的能力。

在 Linux 系统上安装 Inxi

大多数主流 Linux 发行版的仓库中都有 Inxi ,包括大多数 BSD 系统。

$ sudo apt-get install inxi   [On Debian/Ubuntu/Linux Mint]
$ sudo yum install inxi       [On CentOs/RHEL/Fedora]
$ sudo dnf install inxi       [On Fedora 22+]

在使用 Inxi 之前,用下面的命令查看 Inxi 所有依赖和推荐的应用,以及各种目录,并显示需要安装哪些包来支持给定的功能。

$ inxi --recommends 

Inxi 的输出:

inxi will now begin checking for the programs it needs to operate. First a check of the main languages and tools
inxi uses. Python is only for debugging data collection.
---------------------------------------------------------------------------
Bash version: 4.3.42(1)-release
Gawk version: 4.1.3,
Sed version: 
Sudo version: 1.8.16
Python version: 2.7.12
---------------------------------------------------------------------------
Test One: Required System Directories (Linux Only).
If one of these system directories is missing, inxi cannot operate:
/proc....................................................................... Present
/sys........................................................................ Present
All the  directories are present.
---------------------------------------------------------------------------
Test Two: Required Core Applications.
If one of these applications is missing, inxi cannot operate:
df (info: partition data)................................................... /bin/df
gawk (info: core tool)...................................................... /usr/bin/gawk
grep (info: string search).................................................. /bin/grep
lspci (info: hardware data)................................................. /usr/bin/lspci
ps (info: process data)..................................................... /bin/ps
readlink.................................................................... /bin/readlink
sed (info: string replace).................................................. /bin/sed
tr (info: character replace)................................................ /usr/bin/tr
uname (info: kernel data)................................................... /bin/uname
wc (info: word character count)............................................. /usr/bin/wc
All the  applications are present.
---------------------------------------------------------------------------
Test Three: Script Recommends for Graphics Features.
NOTE: If you do not use X these do not matter (like a headless server). Otherwise, if one of these applications
is missing, inxi will have incomplete output:
glxinfo (info: -G glx info)................................................. /usr/bin/glxinfo
xdpyinfo (info: -G multi screen resolution)................................. /usr/bin/xdpyinfo
xprop (info: -S desktop data)............................................... /usr/bin/xprop
xrandr (info: -G single screen resolution).................................. /usr/bin/xrandr
All the  applications are present.
---------------------------------------------------------------------------
Test Four: Script Recommends for Remaining Features.
If one of these applications is missing, inxi will have incomplete output:
dig (info: -i first wlan ip default test)................................... /usr/bin/dig
dmidecode (info: -M if no sys machine data; -m memory)...................... /usr/sbin/dmidecode
file (info: -o unmounted file system)....................................... /usr/bin/file
hciconfig (info: -n -i bluetooth data)...................................... /bin/hciconfig
hddtemp (info: -Dx show hdd temp)........................................... /usr/sbin/hddtemp
ifconfig (info: -i ip lan-deprecated)....................................... /sbin/ifconfig
ip (info: -i ip lan)........................................................ /sbin/ip
sensors (info: -s sensors output)........................................... /usr/bin/sensors
strings (info: -I sysvinit version)......................................... /usr/bin/strings
lsusb (info: -A usb audio;-N usb networking)................................ /usr/bin/lsusb
modinfo (info: -Ax,-Nx module version)...................................... /sbin/modinfo
runlevel (info: -I runlevel)................................................ /sbin/runlevel
sudo (info: -Dx hddtemp-user;-o file-user).................................. /usr/bin/sudo
uptime (info: -I uptime (check which package owns Debian)).................. /usr/bin/uptime
All the  applications are present.
---------------------------------------------------------------------------
Test Five: Script Recommends for Remaining Features.
One of these downloaders needed for options -i/-w/-W (-U/-! [11-15], if supported):
wget (info: -i wan ip;-w/-W;-U/-! [11-15] (if supported))................... /usr/bin/wget
curl (info: -i wan ip;-w/-W;-U/-! [11-15] (if supported))................... /usr/bin/curl
All the  applications are present.
---------------------------------------------------------------------------
Test Six: System Directories for Various Information.
(Unless otherwise noted, these are for GNU/Linux systems)
If one of these directories is missing, inxi may have incomplete output:
/sys/class/dmi/id (info: -M system, motherboard, bios)...................... Present
/dev (info: -l,-u,-o,-p,-P,-D disk partition data).......................... Present
/dev/disk/by-label (info: -l,-o,-p,-P partition labels)..................... Present
/dev/disk/by-uuid (info: -u,-o,-p,-P partition uuid)........................ Present
All the  directories are present.
---------------------------------------------------------------------------
Test Seven: System Files for Various Information.
(Unless otherwise noted, these are for GNU/Linux systems)
If one of these files is missing, inxi may have incomplete output:
/proc/asound/cards (info: -A sound card data)............................... Present
/proc/asound/version (info: -A ALSA data)................................... Present
/proc/cpuinfo (info: -C cpu data)........................................... Present
/etc/lsb-release (info: -S distro version data [deprecated])................ Present
/proc/mdstat (info: -R mdraid data)......................................... Present
/proc/meminfo (info: -I memory data)........................................ Present
/etc/os-release (info: -S distro version data).............................. Present
/proc/partitions (info: -p,-P partitions data).............................. Present
/proc/modules (info: -G module data)........................................ Present
/proc/mounts (info: -P,-p partition advanced data).......................... Present
/var/run/dmesg.boot (info: -D,-d disk data [BSD only])...................... Missing
/proc/scsi/scsi (info: -D Advanced hard disk data [used rarely])............ Present
/var/log/Xorg.0.log (info: -G graphics driver load status).................. Present
The following files are missing from your system:
File: /var/run/dmesg.boot
---------------------------------------------------------------------------
All tests completed.

Inxi 工具的基本用法

用下面的基本用法获取系统和硬件的详细信息。

获取 Linux 系统信息

Inix 不加任何选项就能输出下面的信息:CPU 、内核、开机时长、内存大小、硬盘大小、进程数、登录终端以及 Inxi 版本。

$ inxi
CPU~Dual core Intel Core i5-4210U (-HT-MCP-) speed/max~2164/2700 MHz Kernel~4.4.0-21-generic x86_64 Up~3:15 Mem~3122.0/7879.9MB HDD~1000.2GB(20.0% used) Procs~234 Client~Shell inxi~2.2.35

获取内核和发行版本信息

使用 Inxi 的 -S 选项查看本机系统信息(主机名、内核信息、桌面环境和发行版):

$ inxi -S
System: Host: TecMint Kernel: 4.4.0-21-generic x86_64 (64 bit) Desktop: Cinnamon 3.0.7
Distro: Linux Mint 18 Sarah

获取电脑机型

使用 -M 选项查看机型(笔记本/台式机)、产品 ID 、机器版本、主板、制造商和 BIOS 等信息:

$ inxi -M
Machine:   System: LENOVO (portable) product: 20354 v: Lenovo Z50-70
Mobo: LENOVO model: Lancer 5A5 v: 31900059WIN Bios: LENOVO v: 9BCN26WW date: 07/31/2014

获取 CPU 及主频信息

使用 -C 选项查看完整的 CPU 信息,包括每核 CPU 的频率及可用的最大主频。

$ inxi -C
CPU:       Dual core Intel Core i5-4210U (-HT-MCP-) cache: 3072 KB 
clock speeds: max: 2700 MHz 1: 1942 MHz 2: 1968 MHz 3: 1734 MHz 4: 1710 MHz

获取显卡信息

使用 -G 选项查看显卡信息,包括显卡类型、显示服务器、系统分辨率、GLX 渲染器和 GLX 版本等等(LCTT 译注: GLX 是一个 X 窗口系统的 OpenGL 扩展)。

$ inxi -G
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
Card-2: NVIDIA GM108M [GeForce 840M]
Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: [email protected]
GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 11.2.0

获取声卡信息

使用 -A 选项查看声卡信息:

$ inxi -A
Audio:     Card-1 Intel 8 Series HD Audio Controller driver: snd_hda_intel Sound: ALSA v: k4.4.0-21-generic
Card-2 Intel Haswell-ULT HD Audio Controller driver: snd_hda_intel

获取网卡信息

使用 -N 选项查看网卡信息:

$ inxi -N
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be

获取硬盘信息

使用 -D 选项查看硬盘信息(大小、ID、型号):

$ inxi -D
Drives:    HDD Total Size: 1000.2GB (20.0% used) ID-1: /dev/sda model: ST1000LM024_HN size: 1000.2GB

获取简要的系统信息

使用 -b 选项显示上述信息的简要系统信息:

$ inxi -b 
System:    Host: TecMint Kernel: 4.4.0-21-generic x86_64 (64 bit) Desktop: Cinnamon 3.0.7
Distro: Linux Mint 18 Sarah
Machine:   System: LENOVO (portable) product: 20354 v: Lenovo Z50-70
Mobo: LENOVO model: Lancer 5A5 v: 31900059WIN Bios: LENOVO v: 9BCN26WW date: 07/31/2014
CPU:       Dual core Intel Core i5-4210U (-HT-MCP-) speed/max: 2018/2700 MHz
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
Card-2: NVIDIA GM108M [GeForce 840M]
Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: [email protected]
GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 11.2.0
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be
Drives:    HDD Total Size: 1000.2GB (20.0% used)
Info:      Processes: 233 Uptime: 3:23 Memory: 3137.5/7879.9MB Client: Shell (bash) inxi: 2.2.35  

获取硬盘分区信息

使用 -p 选项输出完整的硬盘分区信息,包括每个分区的分区大小、已用空间、可用空间、文件系统以及文件系统类型。

$ inxi -p
Partition: ID-1: / size: 324G used: 183G (60%) fs: ext4 dev: /dev/sda10
ID-2: swap-1 size: 4.00GB used: 0.00GB (0%) fs: swap dev: /dev/sda9

获取完整的 Linux 系统信息

使用 -F 选项查看可以完整的 Inxi 输出(安全起见比如网络 IP 地址信息没有显示,下面的示例只显示部分输出信息):

$ inxi -F 
System:    Host: TecMint Kernel: 4.4.0-21-generic x86_64 (64 bit) Desktop: Cinnamon 3.0.7
Distro: Linux Mint 18 Sarah
Machine:   System: LENOVO (portable) product: 20354 v: Lenovo Z50-70
Mobo: LENOVO model: Lancer 5A5 v: 31900059WIN Bios: LENOVO v: 9BCN26WW date: 07/31/2014
CPU:       Dual core Intel Core i5-4210U (-HT-MCP-) cache: 3072 KB 
clock speeds: max: 2700 MHz 1: 1716 MHz 2: 1764 MHz 3: 1776 MHz 4: 1800 MHz
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
Card-2: NVIDIA GM108M [GeForce 840M]
Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: [email protected]
GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 11.2.0
Audio:     Card-1 Intel 8 Series HD Audio Controller driver: snd_hda_intel Sound: ALSA v: k4.4.0-21-generic
Card-2 Intel Haswell-ULT HD Audio Controller driver: snd_hda_intel
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
IF: enp1s0 state: up speed: 100 Mbps duplex: full mac: 28:d2:44:eb:bd:98
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be
IF: wlp2s0 state: down mac: 38:b1:db:7c:78:c7
Drives:    HDD Total Size: 1000.2GB (20.0% used) ID-1: /dev/sda model: ST1000LM024_HN size: 1000.2GB
Partition: ID-1: / size: 324G used: 183G (60%) fs: ext4 dev: /dev/sda10
ID-2: swap-1 size: 4.00GB used: 0.00GB (0%) fs: swap dev: /dev/sda9
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 56.0C mobo: N/A
Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 234 Uptime: 3:26 Memory: 3188.9/7879.9MB Client: Shell (bash) inxi: 2.2.35 

使用 Inxi 工具监控 Linux 系统

下面是监控 Linux 系统进程、开机时间和内存的几个选项的使用方法。

监控 Linux 进程的内存使用

使用下面的命令查看进程数、开机时间和内存使用情况:

$ inxi -I
Info:      Processes: 232 Uptime: 3:35 Memory: 3256.3/7879.9MB Client: Shell (bash) inxi: 2.2.35 

监控进程占用的 CPU 和内存资源

Inxi 默认显示 前 5 个最消耗 CPU 和内存的进程-t 选项和 c 选项一起使用查看前 5 个最消耗 CPU 资源的进程,查看最消耗内存的进程使用 -t 选项和 m 选项; -t选项 和 cm 选项一起使用显示前 5 个最消耗 CPU 和内存资源的进程。

----------------- Linux CPU Usage ----------------- 
$ inxi -t c 
Processes: CPU: % used - top 5 active
1: cpu: 53.7% command: plugin-container pid: 3066
2: cpu: 20.0% command: java pid: 1527
3: cpu: 19.7% command: firefox pid: 3018
4: cpu: 4.6% command: Xorg pid: 2114
5: cpu: 3.0% command: cinnamon pid: 2835
----------------- Linux Memoery Usage ----------------- 
$ inxi -t m
Processes: Memory: MB / % used - Used/Total: 3212.5/7879.9MB - top 5 active
1: mem: 980.51MB (12.4%) command: plugin-container pid: 3066
2: mem: 508.96MB (6.4%) command: java pid: 1527
3: mem: 507.89MB (6.4%) command: firefox pid: 3018
4: mem: 244.05MB (3.0%) command: chrome pid: 7405
5: mem: 211.46MB (2.6%) command: chrome pid: 6146
----------------- Linux CPU and Memory Usage ----------------- 
$ inxi -t cm
Processes: CPU: % used - top 5 active
1: cpu: 53.7% command: plugin-container pid: 3066
2: cpu: 20.0% command: java pid: 1527
3: cpu: 19.7% command: firefox pid: 3018
4: cpu: 4.6% command: Xorg pid: 2114
5: cpu: 3.0% command: cinnamon pid: 2835
Memory: MB / % used - Used/Total: 3223.6/7879.9MB - top 5 active
1: mem: 991.93MB (12.5%) command: plugin-container pid: 3066
2: mem: 508.96MB (6.4%) command: java pid: 1527
3: mem: 507.86MB (6.4%) command: firefox pid: 3018
4: mem: 244.45MB (3.1%) command: chrome pid: 7405
5: mem: 211.68MB (2.6%) command: chrome pid: 6146

可以在选项 cm 后跟一个整数(在 1-20 之间)设置显示多少个进程,下面的命令显示了前 10 个最消耗 CPU 和内存的进程:

$ inxi -t cm10
Processes: CPU: % used - top 10 active
1: cpu: 53.4% command: plugin-container pid: 3066
2: cpu: 19.8% command: java pid: 1527
3: cpu: 19.5% command: firefox pid: 3018
4: cpu: 4.5% command: Xorg pid: 2114
5: cpu: 3.0% command: cinnamon pid: 2835
6: cpu: 2.8% command: chrome pid: 7405
7: cpu: 1.1% command: pulseaudio pid: 2733
8: cpu: 1.0% command: soffice.bin pid: 7799
9: cpu: 0.9% command: chrome pid: 5763
10: cpu: 0.5% command: chrome pid: 6179
Memory: MB / % used - Used/Total: 3163.1/7879.9MB - top 10 active
1: mem: 976.82MB (12.3%) command: plugin-container pid: 3066
2: mem: 511.70MB (6.4%) command: java pid: 1527
3: mem: 466.01MB (5.9%) command: firefox pid: 3018
4: mem: 244.40MB (3.1%) command: chrome pid: 7405
5: mem: 203.71MB (2.5%) command: chrome pid: 6146
6: mem: 199.74MB (2.5%) command: chrome pid: 5763
7: mem: 168.30MB (2.1%) command: cinnamon pid: 2835
8: mem: 165.51MB (2.1%) command: soffice.bin pid: 7799
9: mem: 158.91MB (2.0%) command: chrome pid: 6179
10: mem: 151.83MB (1.9%) command: mysqld pid: 1259

监控网络设备

下面的命令会列出网卡信息,包括接口信息、网络频率、mac 地址、网卡状态和网络 IP 等信息。

$ inxi -Nni
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
IF: enp1s0 state: up speed: 100 Mbps duplex: full mac: 28:d2:44:eb:bd:98
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be
IF: wlp2s0 state: down mac: 38:b1:db:7c:78:c7
WAN IP: 111.91.115.195 IF: wlp2s0 ip-v4: N/A
IF: enp1s0 ip-v4: 192.168.0.103

监控 CPU 温度和电脑风扇转速

可以使用 -s 选项监控 配置了传感器的机器 获取温度和风扇转速:

$ inxi -s
Sensors:   System Temperatures: cpu: 53.0C mobo: N/A
Fan Speeds (in rpm): cpu: N/A

用 Linux 查看天气预报

使用 -w 选项查看本地区的天气情况(虽然使用的 API 可能不是很可靠),使用 -W <different_location> 设置另外的地区。

$ inxi -w
Weather:   Conditions: 93 F (34 C) - smoke Time: February 20, 1:38 PM IST
$ inxi -W Mumbai,India
Weather:   Conditions: 93 F (34 C) - smoke Time: February 20, 1:38 PM IST
$ inxi -W Nairobi,Kenya
Weather:   Conditions: 70 F (21 C) - Mostly Cloudy Time: February 20, 11:08 AM EAT

查看所有的 Linux 仓库信息

另外,可以使用 -r 选项查看一个 Linux 发行版的仓库信息:

$ inxi -r 
Repos:     Active apt sources in file: /etc/apt/sources.list.d/dawidd0811-neofetch-xenial.list
deb http://ppa.launchpad.net/dawidd0811/neofetch/ubuntu xenial main
deb-src http://ppa.launchpad.net/dawidd0811/neofetch/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/dhor-myway-xenial.list
deb http://ppa.launchpad.net/dhor/myway/ubuntu xenial main
deb-src http://ppa.launchpad.net/dhor/myway/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/official-package-repositories.list
deb http://packages.linuxmint.com sarah main upstream import backport
deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu/ xenial partner
Active apt sources in file: /etc/apt/sources.list.d/qbittorrent-team-qbittorrent-stable-xenial.list
deb http://ppa.launchpad.net/qbittorrent-team/qbittorrent-stable/ubuntu xenial main
deb-src http://ppa.launchpad.net/qbittorrent-team/qbittorrent-stable/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/slgobinath-safeeyes-xenial.list
deb http://ppa.launchpad.net/slgobinath/safeeyes/ubuntu xenial main
deb-src http://ppa.launchpad.net/slgobinath/safeeyes/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/snwh-pulp-xenial.list
deb http://ppa.launchpad.net/snwh/pulp/ubuntu xenial main
deb-src http://ppa.launchpad.net/snwh/pulp/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/twodopeshaggy-jarun-xenial.list
deb http://ppa.launchpad.net/twodopeshaggy/jarun/ubuntu xenial main
deb-src http://ppa.launchpad.net/twodopeshaggy/jarun/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/ubuntu-mozilla-security-ppa-xenial.list
deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu xenial main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu xenial main

下面是查看 Inxi 的安装版本、快速帮助和打开 man 主页的方法,以及更多的 Inxi 使用细节。

$ inxi -v   #显示版本信息
$ inxi -h   #快速帮助
$ man inxi  #打开 man 主页

浏览 Inxi 的官方 GitHub 主页 https://github.com/smxi/inxi 查看更多的信息。

Inxi 是一个功能强大的获取硬件和系统信息的命令行工具。这也是我使用过的最好的 获取硬件和系统信息的命令行工具 之一。

写下你的评论。如果你知道其他的像 Inxi 这样的工具,我们很高兴和你一起讨论。


作者简介:

Aaron Kili 是一个 Linux 和 F.O.S.S 的狂热爱好者,即任的 Linux 系统管理员,web 开发者,TecMint 网站的专栏作者,他喜欢使用计算机工作,并且乐于分享计算机技术。


via: http://www.tecmint.com/inxi-command-to-find-linux-system-information/

作者:Aaron Kili 译者:vim-kakali 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这是一篇用屏幕截图解释如何在 AWS EC2 Linux 服务器上打开端口的教程。它能帮助你管理 EC2 服务器上特定端口的服务。

AWS(即 Amazon Web Services)不是 IT 世界中的新术语了。它是亚马逊提供的云服务平台。它的免费帐户能为你提供一年的有限免费服务。这是尝试新技术而不用花费金钱的最好的方式之一。

AWS 提供服务器计算作为他们的服务之一,他们称之为 EC(弹性计算)。使用它可以构建我们的 Linux 服务器。我们已经看到了如何在 AWS 上设置免费的 Linux 服务器了。

默认情况下,所有基于 EC2 的 Linux 服务器都只打开 22 端口,即 SSH 服务端口(允许所有 IP 的入站连接)。因此,如果你托管了任何特定端口的服务,则要为你的服务器在 AWS 防火墙上打开相应端口。

同样它的 1 到 65535 的端口是打开的(对于所有出站流量)。如果你想改变这个,你可以使用下面的方法编辑出站规则。

在 AWS 上为你的服务器设置防火墙规则很容易。你能够在几秒钟内为你的服务器打开端口。我将用截图指导你如何打开 EC2 服务器的端口。

步骤 1 :

登录 AWS 帐户并进入 EC2 管理控制台。进入 “网络及安全” Network & Security 菜单下的 安全组 Security Groups ,如下高亮显示:

AWS EC2 management console

AWS EC2 管理控制台

步骤 2 :

安全组 Security Groups 中选择你的 EC2 服务器,并在 行动 Actions 菜单下选择 编辑入站规则 Edit inbound rules

AWS inbound rules

AWS 入站规则菜单

步骤 3:

现在你会看到入站规则窗口。你可以在此处添加/编辑/删除入站规则。这有几个如 http、nfs 等列在下拉菜单中,它们可以为你自动填充端口。如果你有自定义服务和端口,你也可以定义它。

AWS add inbound rule

AWS 添加入站规则

比如,如果你想要打开 80 端口,你需要选择:

  • 类型:http
  • 协议:TCP
  • 端口范围:80
  • 源:任何来源:打开 80 端口接受来自“任何IP(0.0.0.0/0)”的请求;我的 IP:那么它会自动填充你当前的公共互联网 IP

步骤 4:

就是这样了。保存完毕后,你的服务器入站 80 端口将会打开!你可以通过 telnet 到 EC2 服务器公共域名的 80 端口来检验(可以在 EC2 服务器详细信息中找到)。

你也可以在 ping.eu 等网站上检验。


同样的方式可以编辑出站规则,这些更改都是即时生效的。


via: http://kerneltalks.com/virtualization/how-to-open-port-on-aws-ec2-linux-server/

作者:Shrikant Lavhate 译者:geekpi 校对:jasminepeng

本文由 LCTT 原创编译,Linux中国 荣誉推出

一些 Fedora 用户把大部分甚至是所有时间花费在了命令行终端上。 终端可让您访问整个系统,以及数以千计的强大的实用程序。 但是,它默认情况下一次只显示一个命令行会话。 即使有一个大的终端窗口,整个窗口也只会显示一个会话。 这浪费了空间,特别是在大型显示器和高分辨率的笔记本电脑屏幕上。 但是,如果你可以将终端分成多个会话呢? 这正是 tmux 最方便的地方,或者说不可或缺的。

安装并启动 tmux

tmux 应用程序的名称来源于 终端 terminal 复用器 muxer 多路复用器 multiplexer 。 换句话说,它可以将您的单终端会话分成多个会话。 它管理窗口和窗格:

  • 窗口 window 是一个单一的视图 - 也就是终端中显示的各种东西。
  • 窗格 pane 是该视图的一部分,通常是一个终端会话。

开始前,请在系统上安装 tmux 应用程序。 你需要为您的用户帐户设置 sudo 权限(如果需要,请查看本文获取相关说明)。

sudo dnf -y install tmux

运行 tmux程序:

tmux

状态栏

首先,似乎什么也没有发生,除了出现在终端的底部的状态栏:

Start of tmux session

底部栏显示:

  • [0] – 这是 tmux 服务器创建的第一个会话。编号从 0 开始。tmux 服务器会跟踪所有的会话确认其是否存活。
  • 0:testuser@scarlett:~ – 有关该会话的第一个窗口的信息。编号从 0 开始。这表示窗口的活动窗格中的终端归主机名 scarletttestuser 用户所有。当前目录是 ~ (家目录)。
  • * – 显示你目前在此窗口中。
  • “scarlett.internal.fri” – 你正在使用的 tmux 服务器的主机名。
  • 此外,还会显示该特定主机上的日期和时间。

当你向会话中添加更多窗口和窗格时,信息栏将随之改变。

tmux 基础知识

把你的终端窗口拉伸到最大。现在让我们尝试一些简单的命令来创建更多的窗格。默认情况下,所有的命令都以 Ctrl+b 开头。

  • Ctrl+b, " 水平分割当前单个窗格。 现在窗口中有两个命令行窗格,一个在顶部,一个在底部。请注意,底部的新窗格是活动窗格。
  • Ctrl+b, % 垂直分割当前单个窗格。 现在你的窗口中有三个命令行窗格,右下角的窗格是活动窗格。

tmux window with three panes

注意当前窗格周围高亮显示的边框。要浏览所有的窗格,请做以下操作:

  • Ctrl+b,然后点箭头键
  • Ctrl+b, q,数字会短暂的出现在窗格上。在这期间,你可以你想要浏览的窗格上对应的数字。

现在,尝试使用不同的窗格运行不同的命令。例如以下这样的:

  • 在顶部窗格中使用 ls 命令显示目录内容。
  • 在左下角的窗格中使用 vi 命令,编辑一个文本文件。
  • 在右下角的窗格中运行 top 命令监控系统进程。

屏幕将会如下显示:

tmux session with three panes running different commands

到目前为止,这个示例中只是用了一个带多个窗格的窗口。你也可以在会话中运行多个窗口。

  • 为了创建一个新的窗口,请敲Ctrl+b, c 。请注意,状态栏显示当前有两个窗口正在运行。(敏锐的读者会看到上面的截图。)
  • 要移动到上一个窗口,请敲 Ctrl+b, p
  • 要移动到下一个窗口,请敲 Ctrl+b, n
  • 要立即移动到特定的窗口,请敲 Ctrl+b 然后跟上窗口编号。

如果你想知道如何关闭窗格,只需要使用 exitlogout,或者 Ctrl+d 来退出特定的命令行 shell。一旦你关闭了窗口中的所有窗格,那么该窗口也会消失。

脱离和附加

tmux 最强大的功能之一是能够脱离和重新附加到会话。 当你脱离的时候,你可以离开你的窗口和窗格独立运行。 此外,您甚至可以完全注销系统。 然后,您可以登录到同一个系统,重新附加到 tmux 会话,查看您离开时的所有窗口和窗格。 脱离的时候你运行的命令一直保持运行状态。

为了脱离一个会话,请敲 Ctrl+b, d。然后会话消失,你重新返回到一个标准的单一 shell。如果要重新附加到会话中,使用一下命令:

tmux attach-session

当你连接到主机的网络不稳定时,这个功能就像救生员一样有用。如果连接失败,会话中的所有的进程都会继续运行。只要连接恢复了,你就可以恢复正常,就好像什么事情也没有发生一样。

如果这些功能还不够,在每个会话的顶层窗口和窗格中,你可以运行多个会话。你可以列举出这些窗口和窗格,然后通过编号或者名称把他们附加到正确的会话中:

tmux list-sessions

延伸阅读

本文只触及的 tmux 的表面功能。你可以通过其他方式操作会话:

  • 将一个窗格和另一个窗格交换
  • 将窗格移动到另一个窗口中(可以在同一个会话中也可以在不同的会话中)
  • 设定快捷键自动执行你喜欢的命令
  • ~/.tmux.conf 文件中配置你最喜欢的配置项,这样每一个会话都会按照你喜欢的方式呈现

有关所有命令的完整说明,请查看以下参考:


作者简介:

Paul W. Frields 自 1997 年以来一直是 Linux 用户和爱好者,并于 2003 年加入 Fedora 项目,这个项目刚推出不久。他是 Fedora 项目委员会的创始成员,在文档,网站发布,宣传,工具链开发和维护软件方面都有贡献。他于2008 年 2 月至 2010 年 7 月加入 Red Hat,担任 Fedora 项目负责人,并担任 Red Hat 的工程经理。目前他和妻子以及两个孩子居住在弗吉尼亚。


via: https://fedoramagazine.org/use-tmux-more-powerful-terminal/

作者:Paul W. Frields 译者:Flowsnow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这是调试器工作原理系列文章的第一篇,我不确定这个系列会有多少篇文章,会涉及多少话题,但我仍会从这篇基础开始。

这一篇会讲什么

我将为大家展示 Linux 中调试器的主要构成模块 - ptrace 系统调用。这篇文章所有代码都是基于 32 位 Ubuntu 操作系统。值得注意的是,尽管这些代码是平台相关的,将它们移植到其它平台应该并不困难。

缘由

为了理解我们要做什么,让我们先考虑下调试器为了完成调试都需要什么资源。调试器可以开始一个进程并调试这个进程,又或者将自己同某个已经存在的进程关联起来。调试器能够单步执行代码,设定断点并且将程序执行到断点,检查变量的值并追踪堆栈。许多调试器有着更高级的特性,例如在调试器的地址空间内执行表达式或者调用函数,甚至可以在进程执行过程中改变代码并观察效果。

尽管现代的调试器都十分的复杂(我没有检查,但我确信 gdb 的代码行数至少有六位数),但它们的工作的原理却是十分的简单。调试器的基础是操作系统与编译器 / 链接器提供的一些基础服务,其余的部分只是简单的编程而已。

Linux 的调试 - ptrace

Linux 调试器中的瑞士军刀便是 ptrace 系统调用(使用 man 2 ptrace 命令可以了解更多)。这是一种复杂却强大的工具,可以允许一个进程控制另外一个进程并从 内部替换 Peek and poke 被控制进程的内核镜像的值(Peek and poke 在系统编程中是很知名的叫法,指的是直接读写内存内容)。

接下来会深入分析。

执行进程的代码

我将编写一个示例,实现一个在“跟踪”模式下运行的进程。在这个模式下,我们将单步执行进程的代码,就像机器码(汇编代码)被 CPU 执行时一样。我将分段展示、讲解示例代码,在文章的末尾也有完整 c 文件的下载链接,你可以编译、执行或者随心所欲的更改。

更进一步的计划是实现一段代码,这段代码可以创建可执行用户自定义命令的子进程,同时父进程可以跟踪子进程。首先是主函数:

int main(int argc, char** argv)
{
    pid_t child_pid;

    if (argc < 2) {
        fprintf(stderr, "Expected a program name as argument\n");
        return -1;
    }

    child_pid = fork();
    if (child_pid == 0)
        run_target(argv[1]);
    else if (child_pid > 0)
        run_debugger(child_pid);
    else {
        perror("fork");
        return -1;
    }

    return 0;
}

看起来相当的简单:我们用 fork 创建了一个新的子进程(这篇文章假定读者有一定的 Unix/Linux 编程经验。我假定你知道或至少了解 fork、exec 族函数与 Unix 信号)。if 语句的分支执行子进程(这里称之为 “target”),else if 的分支执行父进程(这里称之为 “debugger”)。

下面是 target 进程的代码:

void run_target(const char* programname)
{
    procmsg("target started. will run '%s'\n", programname);

    /* Allow tracing of this process */
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
        perror("ptrace");
        return;
    }

    /* Replace this process's image with the given program */
    execl(programname, programname, 0);
}

这段代码中最值得注意的是 ptrace 调用。在 sys/ptrace.h 中,ptrace 是如下定义的:

long ptrace(enum __ptrace_request request, pid_t pid,
                 void *addr, void *data);

第一个参数是 _request_,这是许多预定义的 PTRACE_* 常量中的一个。第二个参数为请求分配进程 ID。第三个与第四个参数是地址与数据指针,用于操作内存。上面代码段中的 ptrace 调用发起了 PTRACE_TRACEME 请求,这意味着该子进程请求系统内核让其父进程跟踪自己。帮助页面上对于 request 的描述很清楚:

意味着该进程被其父进程跟踪。任何传递给该进程的信号(除了 SIGKILL)都将通过 wait() 方法阻塞该进程并通知其父进程。此外,该进程的之后所有调用 exec() 动作都将导致 SIGTRAP 信号发送到此进程上,使得父进程在新的程序执行前得到取得控制权的机会。如果一个进程并不需要它的的父进程跟踪它,那么这个进程不应该发送这个请求。(pid、addr 与 data 暂且不提)

我高亮了这个例子中我们需要注意的部分。在 ptrace 调用后,run_target 接下来要做的就是通过 execl 传参并调用。如同高亮部分所说明,这将导致系统内核在 execl 创建进程前暂时停止,并向父进程发送信号。

是时候看看父进程做什么了。

void run_debugger(pid_t child_pid)
{
    int wait_status;
    unsigned icounter = 0;
    procmsg("debugger started\n");

    /* Wait for child to stop on its first instruction */
    wait(&wait_status);

    while (WIFSTOPPED(wait_status)) {
        icounter++;
        /* Make the child execute another instruction */
        if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {
            perror("ptrace");
            return;
        }

        /* Wait for child to stop on its next instruction */
        wait(&wait_status);
    }

    procmsg("the child executed %u instructions\n", icounter);
}

如前文所述,一旦子进程调用了 exec,子进程会停止并被发送 SIGTRAP 信号。父进程会等待该过程的发生并在第一个 wait() 处等待。一旦上述事件发生了,wait() 便会返回,由于子进程停止了父进程便会收到信号(如果子进程由于信号的发送停止了,WIFSTOPPED 就会返回 true)。

父进程接下来的动作就是整篇文章最需要关注的部分了。父进程会将 PTRACE_SINGLESTEP 与子进程 ID 作为参数调用 ptrace 方法。这就会告诉操作系统,“请恢复子进程,但在它执行下一条指令前阻塞”。周而复始地,父进程等待子进程阻塞,循环继续。当 wait() 中传出的信号不再是子进程的停止信号时,循环终止。在跟踪器(父进程)运行期间,这将会是被跟踪进程(子进程)传递给跟踪器的终止信号(如果子进程终止 WIFEXITED 将返回 true)。

icounter 存储了子进程执行指令的次数。这么看来我们小小的例子也完成了些有用的事情 - 在命令行中指定程序,它将执行该程序并记录它从开始到结束所需要的 cpu 指令数量。接下来就让我们这么做吧。

测试

我编译了下面这个简单的程序并利用跟踪器运行它:

#include <stdio.h>

int main()
{
    printf("Hello, world!\n");
    return 0;
}

令我惊讶的是,跟踪器花了相当长的时间,并报告整个执行过程共有超过 100,000 条指令执行。仅仅是一条输出语句?什么造成了这种情况?答案很有趣(至少你同我一样痴迷与机器/汇编语言)。Linux 的 gcc 默认会动态的将程序与 c 的运行时库动态地链接。这就意味着任何程序运行前的第一件事是需要动态库加载器去查找程序运行所需要的共享库。这些代码的数量很大 - 别忘了我们的跟踪器要跟踪每一条指令,不仅仅是主函数的,而是“整个进程中的指令”。

所以当我将测试程序使用静态编译时(通过比较,可执行文件会多出 500 KB 左右的大小,这部分是 C 运行时库的静态链接),跟踪器提示只有大概 7000 条指令被执行。这个数目仍然不小,但是考虑到在主函数执行前 libc 的初始化以及主函数执行后的清除代码,这个数目已经是相当不错了。此外,printf 也是一个复杂的函数。

仍然不满意的话,我需要的是“可以测试”的东西 - 例如可以完整记录每一个指令运行的程序执行过程。这当然可以通过汇编代码完成。所以我找到了这个版本的 “Hello, world!” 并编译了它。

section    .text
    ; The _start symbol must be declared for the linker (ld)
    global _start

_start:

    ; Prepare arguments for the sys_write system call:
    ;   - eax: system call number (sys_write)
    ;   - ebx: file descriptor (stdout)
    ;   - ecx: pointer to string
    ;   - edx: string length
    mov    edx, len
    mov    ecx, msg
    mov    ebx, 1
    mov    eax, 4

    ; Execute the sys_write system call
    int    0x80

    ; Execute sys_exit
    mov    eax, 1
    int    0x80

section   .data
msg db    'Hello, world!', 0xa
len equ    $ - msg

当然,现在跟踪器提示 7 条指令被执行了,这样一来很容易区分它们。

深入指令流

上面那个汇编语言编写的程序使得我可以向你介绍 ptrace 的另外一个强大的用途 - 详细显示被跟踪进程的状态。下面是 run_debugger 函数的另一个版本:

void run_debugger(pid_t child_pid)
{
    int wait_status;
    unsigned icounter = 0;
    procmsg("debugger started\n");

    /* Wait for child to stop on its first instruction */
    wait(&wait_status);

    while (WIFSTOPPED(wait_status)) {
        icounter++;
        struct user_regs_struct regs;
        ptrace(PTRACE_GETREGS, child_pid, 0, &regs);
        unsigned instr = ptrace(PTRACE_PEEKTEXT, child_pid, regs.eip, 0);

        procmsg("icounter = %u.  EIP = 0x%08x.  instr = 0x%08x\n",
                    icounter, regs.eip, instr);

        /* Make the child execute another instruction */
        if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {
            perror("ptrace");
            return;
        }

        /* Wait for child to stop on its next instruction */
        wait(&wait_status);
    }

    procmsg("the child executed %u instructions\n", icounter);
}

不同仅仅存在于 while 循环的开始几行。这个版本里增加了两个新的 ptrace 调用。第一条将进程的寄存器值读取进了一个结构体中。 sys/user.h 定义有 user_regs_struct。如果你查看头文件,头部的注释这么写到:

/* 这个文件只为了 GDB 而创建
   不用详细的阅读.如果你不知道你在干嘛,
   不要在除了 GDB 以外的任何地方使用此文件  */

不知道你做何感想,但这让我觉得我们找对地方了。回到例子中,一旦我们在 regs 变量中取得了寄存器的值,我们就可以通过将 PTRACE_PEEKTEXT 作为参数、 regs.eip(x86 上的扩展指令指针)作为地址,调用 ptrace ,读取当前进程的当前指令(警告:如同我上面所说,文章很大程度上是平台相关的。我简化了一些设定 - 例如,x86 指令集不需要调整到 4 字节,我的32位 Ubuntu unsigned int 是 4 字节。事实上,许多平台都不需要。从内存中读取指令需要预先安装完整的反汇编器。我们这里没有,但实际的调试器是有的)。下面是新跟踪器所展示出的调试效果:

$ simple_tracer traced_helloworld
[5700] debugger started
[5701] target started. will run 'traced_helloworld'
[5700] icounter = 1\.  EIP = 0x08048080\.  instr = 0x00000eba
[5700] icounter = 2\.  EIP = 0x08048085\.  instr = 0x0490a0b9
[5700] icounter = 3\.  EIP = 0x0804808a.  instr = 0x000001bb
[5700] icounter = 4\.  EIP = 0x0804808f.  instr = 0x000004b8
[5700] icounter = 5\.  EIP = 0x08048094\.  instr = 0x01b880cd
Hello, world!
[5700] icounter = 6\.  EIP = 0x08048096\.  instr = 0x000001b8
[5700] icounter = 7\.  EIP = 0x0804809b.  instr = 0x000080cd
[5700] the child executed 7 instructions

现在,除了 icounter,我们也可以观察到指令指针与它每一步所指向的指令。怎么来判断这个结果对不对呢?使用 objdump -d 处理可执行文件:

$ objdump -d traced_helloworld

traced_helloworld:     file format elf32-i386

Disassembly of section .text:

08048080 <.text>:
 8048080:     ba 0e 00 00 00          mov    $0xe,%edx
 8048085:     b9 a0 90 04 08          mov    $0x80490a0,%ecx
 804808a:     bb 01 00 00 00          mov    $0x1,%ebx
 804808f:     b8 04 00 00 00          mov    $0x4,%eax
 8048094:     cd 80                   int    $0x80
 8048096:     b8 01 00 00 00          mov    $0x1,%eax
 804809b:     cd 80                   int    $0x80

这个结果和我们跟踪器的结果就很容易比较了。

 将跟踪器关联到正在运行的进程

如你所知,调试器也能关联到已经运行的进程。现在你应该不会惊讶,ptrace 通过以 PTRACE_ATTACH 为参数调用也可以完成这个过程。这里我不会展示示例代码,通过上文的示例代码应该很容易实现这个过程。出于学习目的,这里使用的方法更简便(因为我们在子进程刚开始就可以让它停止)。

代码

上文中的简单的跟踪器(更高级的,可以打印指令的版本)的完整c源代码可以在这里找到。它是通过 4.4 版本的 gcc 以 -Wall -pedantic --std=c99 编译的。

结论与计划

诚然,这篇文章并没有涉及很多内容 - 我们距离亲手完成一个实际的调试器还有很长的路要走。但我希望这篇文章至少可以使得调试这件事少一些神秘感。ptrace 是功能多样的系统调用,我们目前只展示了其中的一小部分。

单步调试代码很有用,但也只是在一定程度上有用。上面我通过 C 的 “Hello World!” 做了示例。为了执行主函数,可能需要上万行代码来初始化 C 的运行环境。这并不是很方便。最理想的是在 main 函数入口处放置断点并从断点处开始分步执行。为此,在这个系列的下一篇,我打算展示怎么实现断点。

参考

撰写此文时参考了如下文章:


via: http://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1

作者:Eli Bendersky 译者:YYforymj 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

最近几年中,面向数据的设计已经受到了很多的关注 —— 一种强调内存中数据布局的编程风格,包括如何访问以及将会引发多少的 cache 缺失。由于在内存读取操作中缺失所占的数量级要大于命中的数量级,所以缺失的数量通常是优化的关键标准。这不仅仅关乎那些对性能有要求的 code-data 结构设计的软件,由于缺乏对内存效益的重视而成为软件运行缓慢、膨胀的一个很大因素。

高效缓存数据结构的中心原则是将事情变得平滑和线性。比如,在大部分情况下,存储一个序列元素更倾向于使用普通数组而不是链表 —— 每一次通过指针来查找数据都会为 cache 缺失增加一份风险;而普通数组则可以预先获取,并使得内存系统以最大的效率运行

如果你知道一点内存层级如何运作的知识,下面的内容会是想当然的结果——但是有时候即便它们相当明显,测试一下任不失为一个好主意。几年前 Baptiste Wicht 测试过了 std::vector vs std::list vs std::deque,(后者通常使用分块数组来实现,比如:一个数组的数组)。结果大部分会和你预期的保持一致,但是会存在一些违反直觉的东西。作为实例:在序列链表的中间位置做插入或者移除操作被认为会比数组快,但如果该元素是一个 POD 类型,并且不大于 64 字节或者在 64 字节左右(在一个 cache 流水线内),通过对要操作的元素周围的数组元素进行移位操作要比从头遍历链表来的快。这是由于在遍历链表以及通过指针插入/删除元素的时候可能会导致不少的 cache 缺失,相对而言,数组移位则很少会发生。(对于更大的元素,非 POD 类型,或者你已经有了指向链表元素的指针,此时和预期的一样,链表胜出)

多亏了类似 Baptiste 这样的数据,我们知道了内存布局如何影响序列容器。但是关联容器,比如 hash 表会怎么样呢?已经有了些权威推荐:Chandler Carruth 推荐的带局部探测的开放寻址(此时,我们没必要追踪指针),以及Mike Acton 推荐的在内存中将 value 和 key 隔离(这种情况下,我们可以在每一个 cache 流水线中得到更多的 key), 这可以在我们必须查找多个 key 时提高局部性能。这些想法很有意义,但再一次的说明:测试永远是好习惯,但由于我找不到任何数据,所以只好自己收集了。

测试

我测试了四个不同的 quick-and-dirty 哈希表实现,另外还包括 std::unordered_map 。这五个哈希表都使用了同一个哈希函数 —— Bob Jenkins 的 SpookyHash(64 位哈希值)。(由于哈希函数在这里不是重点,所以我没有测试不同的哈希函数;我同样也没有检测我的分析中的总内存消耗。)实现会通过简短的代码在测试结果表中标注出来。

  • UMstd::unordered_map 。在 VS2012 和 libstdc++-v3 (libstdc++-v3: gcc 和 clang 都会用到这东西)中,UM 是以链表的形式实现,所有的元素都在链表中,bucket 数组中存储了链表的迭代器。VS2012 中,则是一个双链表,每一个 bucket 存储了起始迭代器和结束迭代器;libstdc++ 中,是一个单链表,每一个 bucket 只存储了一个起始迭代器。这两种情况里,链表节点是独立申请和释放的。最大负载因子是 1 。
  • Ch:分离的、链状 bucket 指向一个元素节点的单链表。为了避免分开申请每一个节点,元素节点存储在普通数组池中。未使用的节点保存在一个空闲链表中。最大负载因子是 1。
  • OL:开地址线性探测 —— 每一个 bucket 存储一个 62 bit 的 hash 值,一个 2 bit 的状态值(包括 empty,filled,removed 三个状态),key 和 value 。最大负载因子是 2/3。
  • DO1:“data-oriented 1” —— 和 OL 相似,但是哈希值、状态值和 key、values 分离在两个隔离的平滑数组中。
  • DO2:“data-oriented 2” —— 与 OL 类似,但是哈希/状态,keys 和 values 被分离在 3 个相隔离的平滑数组中。

在我的所有实现中,包括 VS2012 的 UM 实现,默认使用尺寸为 2 的 n 次方。如果超出了最大负载因子,则扩展两倍。在 libstdc++ 中,UM 默认尺寸是一个素数。如果超出了最大负载因子,则扩展为下一个素数大小。但是我不认为这些细节对性能很重要。素数是一种对低 bit 位上没有足够熵的低劣 hash 函数的挽救手段,但是我们正在用的是一个很好的 hash 函数。

OL,DO1 和 DO2 的实现将共同的被称为 OA(open addressing)——稍后我们将发现它们在性能特性上非常相似。在每一个实现中,单元数从 100 K 到 1 M,有效负载(比如:总的 key + value 大小)从 8 到 4 k 字节我为几个不同的操作记了时间。 keys 和 values 永远是 POD 类型,keys 永远是 8 个字节(除了 8 字节的有效负载,此时 key 和 value 都是 4 字节)因为我的目的是为了测试内存影响而不是哈希函数性能,所以我将 key 放在连续的尺寸空间中。每一个测试都会重复 5 遍,然后记录最小的耗时。

测试的操作在这里:

  • Fill:将一个随机的 key 序列插入到表中(key 在序列中是唯一的)。
  • Presized fill:和 Fill 相似,但是在插入之间我们先为所有的 key 保留足够的内存空间,以防止在 fill 过程中 rehash 或者重申请。
  • Lookup:执行 100 k 次随机 key 查找,所有的 key 都在 table 中。
  • Failed lookup: 执行 100 k 次随机 key 查找,所有的 key 都不在 table 中。
  • Remove:从 table 中移除随机选择的半数元素。
  • Destruct:销毁 table 并释放内存。

你可以在这里下载我的测试代码。这些代码只能在 64 机器上编译(包括Windows和Linux)。在 main() 函数顶部附近有一些开关,你可把它们打开或者关掉——如果全开,可能会需要一两个小时才能结束运行。我收集的结果也放在了那个打包文件里的 Excel 表中。(注意: Windows 和 Linux 在不同的 CPU 上跑的,所以时间不具备可比较性)代码也跑了一些单元测试,用来验证所有的 hash 表实现都能运行正确。

我还顺带尝试了附加的两个实现:Ch 中第一个节点存放在 bucket 中而不是 pool 里,二次探测的开放寻址。 这两个都不足以好到可以放在最终的数据里,但是它们的代码仍放在了打包文件里面。

结果

这里有成吨的数据!! 这一节我将详细的讨论一下结果,但是如果你对此不感兴趣,可以直接跳到下一节的总结。

Windows

这是所有的测试的图表结果,使用 Visual Studio 2012 编译,运行于 Windows 8.1 和 Core i7-4710HQ 机器上。

 title=

从左至右是不同的有效负载大小,从上往下是不同的操作(注意:不是所有的Y轴都是相同的比例!)我将为每一个操作总结一下主要趋向。

Fill

在我的 hash 表中,Ch 稍比任何的 OA 变种要好。随着哈希表大小和有效负载的加大,差距也随之变大。我猜测这是由于 Ch 只需要从一个空闲链表中拉取一个元素,然后把它放在 bucket 前面,而 OA 不得不搜索一部分 bucket 来找到一个空位置。所有的 OA 变种的性能表现基本都很相似,当然 DO1 稍微有点优势。

在小负载的情况,UM 几乎是所有 hash 表中表现最差的 —— 因为 UM 为每一次的插入申请(内存)付出了沉重的代价。但是在 128 字节的时候,这些 hash 表基本相当,大负载的时候 UM 还赢了点。因为,我所有的实现都需要重新调整元素池的大小,并需要移动大量的元素到新池里面,这一点我几乎无能为力;而 UM 一旦为元素申请了内存后便不需要移动了。注意大负载中图表上夸张的跳步!这更确认了重新调整大小带来的问题。相反,UM 只是线性上升 —— 只需要重新调整 bucket 数组大小。由于没有太多隆起的地方,所以相对有效率。

Presized fill

大致和 Fill 相似,但是图示结果更加的线性光滑,没有太大的跳步(因为不需要 rehash ),所有的实现差距在这一测试中要缩小了些。大负载时 UM 依然稍快于 Ch,问题还是在于重新调整大小上。Ch 仍是稳步少快于 OA 变种,但是 DO1 比其它的 OA 稍有优势。

Lookup

所有的实现都相当的集中。除了最小负载时,DO1 和 OL 稍快,其余情况下 UM 和 DO2 都跑在了前面。(LCTT 译注: 你确定?)真的,我无法描述 UM 在这一步做的多么好。尽管需要遍历链表,但是 UM 还是坚守了面向数据的本性。

顺带一提,查找时间和 hash 表的大小有着很弱的关联,这真的很有意思。 哈希表查找时间期望上是一个常量时间,所以在的渐进视图中,性能不应该依赖于表的大小。但是那是在忽视了 cache 影响的情况下!作为具体的例子,当我们在具有 10 k 条目的表中做 100 k 次查找时,速度会便变快,因为在第一次 10 k - 20 k 次查找后,大部分的表会处在 L3 中。

Failed lookup

相对于成功查找,这里就有点更分散一些。DO1 和 DO2 跑在了前面,但 UM 并没有落下,OL 则是捉襟见肘啊。我猜测,这可能是因为 OL 整体上具有更长的搜索路径,尤其是在失败查询时;内存中,hash 值在 key 和 value 之飘来荡去的找不着出路,我也很受伤啊。DO1 和 DO2 具有相同的搜索长度,但是它们将所有的 hash 值打包在内存中,这使得问题有所缓解。

Remove

DO2 很显然是赢家,但 DO1 也未落下。Ch 则落后,UM 则是差的不是一丁半点(主要是因为每次移除都要释放内存);差距随着负载的增加而拉大。移除操作是唯一不需要接触数据的操作,只需要 hash 值和 key 的帮助,这也是为什么 DO1 和 DO2 在移除操作中的表现大相径庭,而其它测试中却保持一致。(如果你的值不是 POD 类型的,并需要析构,这种差异应该是会消失的。)

Destruct

Ch 除了最小负载,其它的情况都是最快的(最小负载时,约等于 OA 变种)。所有的 OA 变种基本都是相等的。注意,在我的 hash 表中所做的所有析构操作都是释放少量的内存 buffer 。但是 在Windows中,释放内存的消耗和大小成比例关系。(而且,这是一个很显著的开支 —— 申请 ~1 GB 的内存需要 ~100 ms 的时间去释放!)

UM 在析构时是最慢的一个(小负载时,慢的程度可以用数量级来衡量),大负载时依旧是稍慢些。对于 UM 来讲,释放每一个元素而不是释放一组数组真的是一个硬伤。

Linux

我还在装有 Linux Mint 17.1 的 Core i5-4570S 机器上使用 gcc 4.8 和 clang 3.5 来运行了测试。gcc 和 clang 的结果很相像,因此我只展示了 gcc 的;完整的结果集合包含在了代码下载打包文件中,链接在上面。

 title=

大部分结果和 Windows 很相似,因此我只高亮了一些有趣的不同点。

Lookup

这里 DO1 跑在前头,而在 Windows 中 DO2 更快些。(LCTT 译注: 这里原文写错了吧?)同样,UM 和 Ch 落后于其它所有的实现——过多的指针追踪,然而 OA 只需要在内存中线性的移动即可。至于 Windows 和 Linux 结果为何不同,则不是很清楚。UM 同样比 Ch 慢了不少,特别是大负载时,这很奇怪;我期望的是它们可以基本相同。

Failed lookup

UM 再一次落后于其它实现,甚至比 OL 还要慢。我再一次无法理解为何 UM 比 Ch 慢这么多,Linux 和 Windows 的结果为何有着如此大的差距。

Destruct

在我的实现中,小负载的时候,析构的消耗太少了,以至于无法测量;在大负载中,线性增加的比例和创建的虚拟内存页数量相关,而不是申请到的数量?同样,要比 Windows 中的析构快上几个数量级。但是并不是所有的都和 hash 表有关;我们在这里可以看出不同系统和运行时内存系统的表现。貌似,Linux 释放大内存块是要比 Windows 快上不少(或者 Linux 很好的隐藏了开支,或许将释放工作推迟到了进程退出,又或者将工作推给了其它线程或者进程)。

UM 由于要释放每一个元素,所以在所有的负载中都比其它慢上几个数量级。事实上,我将图片做了剪裁,因为 UM 太慢了,以至于破坏了 Y 轴的比例。

总结

好,当我们凝视各种情况下的数据和矛盾的结果时,我们可以得出什么结果呢?我想直接了当的告诉你这些 hash 表变种中有一个打败了其它所有的 hash 表,但是这显然不那么简单。不过我们仍然可以学到一些东西。

首先,在大多数情况下我们“很容易”做的比 std::unordered_map 还要好。我为这些测试所写的所有实现(它们并不复杂;我只花了一两个小时就写完了)要么是符合 unordered_map 要么是在其基础上做的提高,除了大负载(超过128字节)中的插入性能, unordered_map 为每一个节点独立申请存储占了优势。(尽管我没有测试,我同样期望 unordered_map 能在非 POD 类型的负载上取得胜利。)具有指导意义的是,如果你非常关心性能,不要假设你的标准库中的数据结构是高度优化的。它们可能只是在 C++ 标准的一致性上做了优化,但不是性能。:P

其次,如果不管在小负载还是超负载中,若都只用 DO1 (开放寻址,线性探测,hashes/states 和 key/vaules分别处在隔离的普通数组中),那可能不会有啥好表现。这不是最快的插入,但也不坏(还比 unordered_map 快),并且在查找,移除,析构中也很快。你所知道的 —— “面向数据设计”完成了!

注意,我的为这些哈希表做的测试代码远未能用于生产环境——它们只支持 POD 类型,没有拷贝构造函数以及类似的东西,也未检测重复的 key,等等。我将可能尽快的构建一些实际的 hash 表,用于我的实用库中。为了覆盖基础部分,我想我将有两个变种:一个基于 DO1,用于小的,移动时不需要太大开支的负载;另一个用于链接并且避免重新申请和移动元素(就像 unordered_map ),用于大负载或者移动起来需要大开支的负载情况。这应该会给我带来最好的两个世界。

与此同时,我希望你们会有所启迪。最后记住,如果 Chandler Carruth 和 Mike Acton 在数据结构上给你提出些建议,你一定要听。


作者简介:

我是一名图形程序员,目前在西雅图做自由职业者。之前我在 NVIDIA 的 DevTech 软件团队中工作,并在美少女特工队工作室中为 PS3 和 PS4 的 Infamous 系列游戏开发渲染技术。

自 2002 年起,我对图形非常感兴趣,并且已经完成了一系列的工作,包括:雾、大气雾霾、体积照明、水、视觉效果、粒子系统、皮肤和头发阴影、后处理、镜面模型、线性空间渲染、和 GPU 性能测量和优化。

你可以在我的博客了解更多和我有关的事,除了图形,我还对理论物理和程序设计感兴趣。

你可以在 [email protected] 或者在 Twitter(@Reedbeta)/Google+ 上关注我。我也会经常在 StackExchange 上回答计算机图形的问题。


via: http://reedbeta.com/blog/data-oriented-hash-table/

作者:Nathan Reed 译者:sanfusu 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出