Linux arping 命令介紹

arping 命令是用于發(fā)送 ARP 請求到一個相鄰主機的工具，arping 使用 ARP 數(shù)據(jù)包，通過 ping 命令檢查設(shè)備上的硬件地址。能夠測試一個 IP 地址是否在網(wǎng)絡(luò)上已經(jīng)被使用，并能夠獲取更多設(shè)備信息。功能類似于 ping 命令

安裝部署：

root@uk8s:~# arping

找不到命令 “arping”，但可以通過以下軟件包安裝它：

apt install iputils-arping # version 3:20190709-3ubuntu1, or

apt install arping # version 2.20-1

root@uk8s:~# apt install arping

正在讀取軟件包列表... 完成

正在分析軟件包的依賴關(guān)系樹... 完成

正在讀取狀態(tài)信息... 完成

將會同時安裝下列軟件：

libnet1

下列【新】軟件包將被安裝：

arping libnet1

升級了 0 個軟件包，新安裝了 2 個軟件包，要卸載 0 個軟件包，有 6 個軟件包未被升級。

需要下載 71.5 kB 的歸檔。

解壓縮后會消耗 236 kB 的額外空間。

您希望繼續(xù)執(zhí)行嗎？ [Y/n] y

獲取:1 http://mirrors.aliyun.com/ubuntu focal/main amd64 libnet1 amd64 1.1.6+dfsg-3.1build1 [43.3 kB]

獲取:2 http://mirrors.aliyun.com/ubuntu focal/universe amd64 arping amd64 2.20-1 [28.2 kB]

已下載 71.5 kB，耗時 1秒 (117 kB/s)

正在選中未選擇的軟件包 libnet1:amd64。

(正在讀取數(shù)據(jù)庫 ... 系統(tǒng)當(dāng)前共安裝有 124998 個文件和目錄。)

準(zhǔn)備解壓 .../libnet1_1.1.6+dfsg-3.1build1_amd64.deb ...

正在解壓 libnet1:amd64 (1.1.6+dfsg-3.1build1) ...

正在選中未選擇的軟件包 arping。

準(zhǔn)備解壓 .../arping_2.20-1_amd64.deb ...

正在解壓 arping (2.20-1) ...

正在設(shè)置 libnet1:amd64 (1.1.6+dfsg-3.1build1) ...

正在設(shè)置 arping (2.20-1) ...

正在處理用于 man-db (2.10.2-1) 的觸發(fā)器 ...

正在處理用于 libc-bin (2.35-0ubuntu3.8) 的觸發(fā)器 ...

Scanning processes...

Scanning linux images...

Running kernel seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

常用選項

• -b：用于發(fā)送以太網(wǎng)廣播幀（FFFFFFFFFFFF）。arping 一開始使用廣播地址，在收到響應(yīng)后就使用 unicast 地址

命令使用：

root@uk8s:~# arping

ARPing 2.20, by Thomas Habets <thomas@habets.se>

usage: arping [ -0aAbdDeFpPqrRuUv ] [ -w <sec> ] [ -W <sec> ] [ -S <host/ip> ]

[ -T <host/ip ] [ -s <MAC> ] [ -t <MAC> ] [ -c <count> ]

[ -C <count> ] [ -i <interface> ] [ -m <type> ] [ -g <group> ]

[ -V <vlan> ] [ -Q <priority> ] <host/ip/MAC | -B>

For complete usage info, use --help or check the manpage.

root@uk8s:~# arping -c 3 www.baidu.com

arping: lookup dev: No matching interface found using getifaddrs().

arping: Unable to automatically find interface to use. Is it on the local LAN?

arping: Use -i to manually specify interface. Guessing interface ens33.

ARPING 183.2.172.185

Timeout

Timeout

Timeout

--- 183.2.172.185 statistics ---

3 packets transmitted, 0 packets received, 100% unanswered (0 extra)

root@uk8s:~# arping -D 192.168.10.18

.........^C 100% packet loss (0 extra)

root@uk8s:~# arping -D 192.168.10.16

!!!!!!!^C 0% packet loss (0 extra)

Illustration created for “A Journey With Go”, made from the original Go Gopher, created by Renee French.

這篇文章是基于 Go 的 1.13 版本

Go 語言的垃圾收集器 （下文簡稱 GC ）能夠幫助到開發(fā)者，通過自動地釋放掉一些程序中不再需要使用的內(nèi)存。但是，跟蹤并清理掉這些內(nèi)存也可能影響我們程序的性能。Go 語言的 GC 旨在實現(xiàn) 這些目標(biāo)[1] 并且關(guān)注如下幾個問題：

• 當(dāng)程序被終止時，盡可能多的減少在這兩個階段的 STW （的次數(shù)） 。
• 一個 GC 周期的時間要少于 10 毫秒。
• 一次 GC 周期不能占用超過 25% 的 CPU 資源。

這是一些很有挑戰(zhàn)性的目標(biāo)，如果 GC 從我們的程序中了解到足夠多的信息，它就能去解決這些問題。

到達堆閾值

GC 將會關(guān)注的第一個指標(biāo)是堆的使用增長。默認情況下，它將在堆大小加倍時運行。這是一個在循環(huán)中分配內(nèi)存的簡單程序。

func BenchmarkAllocationEveryMs(b *testing.B) {
 // need permanent allocation to clear see when the heap double its size
 var s *[]int
 tmp := make([]int, 1100000, 1100000)
 s = &tmp

 var a *[]int
 for i := 0; i < b.N; i++  {
  tmp := make([]int, 10000, 10000)
  a = &tmp

  time.Sleep(time.Millisecond)
 }
 _ = a
 runtime.KeepAlive(s)
}

追蹤器向我們展示了 GC 什么時候被調(diào)用：

Garbage collector cycles and heap size

一旦堆的大小增加了一倍，內(nèi)存分配器就會觸發(fā)執(zhí)行 GC 。通過設(shè)置 GODEBUG=gctrace=1 ，來打印出若干循環(huán)的信息就能夠證實這一點：

gc 8 @0.251s 0%: 0.004+0.11+0.003 ms clock, 0.036+0/0.10/0.15+0.028 ms cpu, 16->16->8 MB, 17 MB goal, 8 P

gc 9 @0.389s 0%: 0.005+0.11+0.007 ms clock, 0.041+0/0.090/0.11+0.062 ms cpu, 16->16->8 MB, 17 MB goal, 8 P

gc 10 @0.526s 0%: 0.046+0.24+0.014 ms clock, 0.37+0/0.14/0.23+0.11 ms cpu, 16->16->8 MB, 17 MB goal, 8 P

第九個循環(huán)就是我們之前看到的那個循環(huán)，運行在第 389 ms 。有意思的部分是 16->16->8 MB，它展示了在 GC 被調(diào)用前堆使用的內(nèi)存有多大，以及在 GC 執(zhí)行后它們還剩下多少。我們可以清楚地看到，當(dāng)?shù)诎藗€循環(huán)將堆大小減少到 8 MB 時，第九個 GC 周期將在 16 MB 時刻觸發(fā)。

這個閾值的比例由環(huán)境變量 GOGC 決定，默認值為 100 % —— 也就是說，在堆的大小增加了一倍之后，GC 就會被調(diào)用。出于性能原因，并且為了避免經(jīng)常啟動一個循環(huán)，當(dāng)堆的大小低于 4 MB * GOGC 的時候， GC 將不會被執(zhí)行。——當(dāng) GOGC 被設(shè)置為 100 % 時，在堆內(nèi)存低于 4 MB 時 GC 將不會被觸發(fā)。

到達時間閾值

GC 關(guān)注的第二個指標(biāo)是在兩次 GC 之間的時間間隔。如果超過兩分鐘 GC 還未執(zhí)行，那么就會強制啟動一次 GC 循環(huán)。

由 GODEBUG 給出的跟蹤顯示，兩分鐘后會強制啟動一次循環(huán)。

GC forced
gc 15 @121.340s 0%: 0.058+1.2+0.015 ms clock, 0.46+0/2.0/4.1+0.12 ms cpu, 1->1->1 MB, 4 MB goal, 8 P

需要協(xié)助

GC 主要由兩個主要階段組成：

• 標(biāo)記仍在使用的內(nèi)存
• 清理未標(biāo)記為使用中的內(nèi)存

在標(biāo)記期間，Go 必須確保 GC 標(biāo)記內(nèi)存的速度比新分配內(nèi)存的速度更快。事實是，如果 GC 正在標(biāo)記 4 MB 大小的內(nèi)存，然而同時程序正在分配同樣大小的內(nèi)存，那么 GC 必須在完成后立即觸發(fā)。

為了解決這個問題，Go 在標(biāo)記內(nèi)存的同時會跟蹤新的內(nèi)存分配，并關(guān)注 GC 何時過載。第一步在 GC 觸發(fā)時執(zhí)行，它會首先為每一個處理器準(zhǔn)備一個 處于 sleep 狀態(tài)的 goroutine，等待標(biāo)記階段。

Goroutines for marking phase

跟蹤器能夠顯示出這些 goroutines：

Goroutines for marking phase

當(dāng)這些 Goroutine 生成后， GC 就開始標(biāo)記階段，該階段會檢查哪些變量應(yīng)收集并清除。被標(biāo)記為 GC dedicated 的 goroutines 會運行標(biāo)記，并不會被搶占，然而那些標(biāo)記為 GC idle 的 goroutines 就會去工作，因為他們沒有任何其他事情。可以被搶占。

GC 現(xiàn)在已經(jīng)能夠去標(biāo)記那些不再使用的變量。對于每一個被掃描到的變量，它會增加一個計數(shù)器，以便繼續(xù)跟蹤當(dāng)前的工作并且也能夠獲得剩余工作的快照。當(dāng)一個 Goroutine 在 GC 期間被安排了任務(wù)，Go 將會比較所需要的分配和已經(jīng)掃描到的，以便對比掃描的速度和分配的需求。如果比較的結(jié)果是掃描內(nèi)容較多，那么當(dāng)前的 Goroutine 并不需要去提供幫助。換句話說，如果掃描與分配相比有所欠缺，那么 Go 就會使用 goroutine 來協(xié)助。這有一個圖表來反應(yīng)這個邏輯：

Mark assist based on scanning debt

在我們的示例中，因為掃描 / 分配的差值為負數(shù)，所以 Goroutine 14 被請求工作：

Assistance for marking

CPU 限制

Go 語言 GC 的目標(biāo)之一是不占用 25 % 的 CPU。這就意味著 Go 在標(biāo)記階段不應(yīng)分配超過四分之一的處理器。實際上，這正是我們在前面的示例中所看到的，在八個處理器中只有兩個 Goroutine 被 GC 充分利用：

Dedicated Goroutine for marking phase

正如我們所看到的，其他的 Goroutine 僅在沒有其他事情要做的情況下才會在標(biāo)記階段工作。但是，在 GC 的協(xié)助請求下，Go 程序可能會在高峰時間最終占用超過 25 % 的 CPU ，如 Goroutine 14 所示：

Mark assistance with dedicated goroutines

在我們的示例中，短時間內(nèi)將我們處理器的 37.5 % （八分之三）分配給了標(biāo)記階段。這可能很少見，只有在分配很高的情況下才會發(fā)生。

via：https://medium.com/a-journey-with-go/go-how-does-the-garbage-collector-watch-your-application-dbef99be2c35

作者：Vincent Blanchon[2]譯者：sh1luo[3]校對：lxbwolf[4]

本文由 GCTT[5] 原創(chuàng)編譯，Go 中文網(wǎng)[6] 榮譽推出

參考資料

[1]

這些目標(biāo): https://blog.golang.org/ismmkeynote

[2]

Vincent Blanchon: https://medium.com/@blanchon.vincent

[3]

sh1luo: https://github.com/sh1luo

[4]

lxbwolf: https://github.com/lxbwolf

[5]

GCTT: https://github.com/studygolang/GCTT

[6]

Go 中文網(wǎng): https://studygolang.com/