Home » Computer » Software » OS » Archive by category "Linux" (Page 3)

Ubuntu 18.04 LTS Minimal Image 的大小

看到「RFC: Ubuntu 18.04 LTS Minimal Images」這篇,在蒐集將來要出的 Ubuntu 18.04 LTS Minimal Image 的意見...

The Ubuntu Minimal Image is the smallest base upon which a user can apt install any package in the Ubuntu archive.

雖然應該還會有改變,不過以目前的版本來看,可以看出壓縮前後兩種版本都比 16.04 小了不少:

對需要這些 image 的人來說 (像是當作 Docker 的 base image),小一點操作起來也比較開心...

Amazon EC2 的可用頻寬提昇

AWSJeff Barr 宣佈了有 ENAEC2 instance 的頻寬提升到 25Gbps:「The Floodgates Are Open – Increased Network Bandwidth for EC2 Instances」。

分成三種,第一種是對 S3 的頻寬提昇:

EC2 to S3 – Traffic to and from Amazon Simple Storage Service (S3) can now take advantage of up to 25 Gbps of bandwidth. Previously, traffic of this type had access to 5 Gbps of bandwidth. This will be of benefit to applications that access large amounts of data in S3 or that make use of S3 for backup and restore.

第二種是 EC2 對 EC2 (內網):

EC2 to EC2 – Traffic to and from EC2 instances in the same or different Availability Zones within a region can now take advantage of up to 5 Gbps of bandwidth for single-flow traffic, or 25 Gbps of bandwidth for multi-flow traffic (a flow represents a single, point-to-point network connection) by using private IPv4 or IPv6 addresses, as described here.

第三種也是 EC2 對 EC2,但是是在同一個 Cluster Placement Group:

EC2 to EC2 (Cluster Placement Group) – Traffic to and from EC2 instances within a cluster placement group can continue to take advantage of up to 10 Gbps of lower-latency bandwidth for single-flow traffic, or 25 Gbps of lower-latency bandwidth for multi-flow traffic.

有 ENA 的有這些,好像沒看到 CentOS

ENA-enabled AMIs are available for Amazon Linux, Ubuntu 14.04 & 16.04, RHEL 7.4, SLES 12, and Windows Server (2008 R2, 2012, 2012 R2, and 2016). The FreeBSD AMI in AWS Marketplace is also ENA-enabled, as is VMware Cloud on AWS.

Ubuntu 18.04 將從 Wayland 換回 Xorg...

在「Ubuntu 18.04 LTS is Switching back to Xorg」這邊看到 Ubuntu 18.04 將要從 Wayland 換回 Xorg 的消息,只能說不意外 XDDD

Ubuntu 官方的說明在「Bionic Beaver 18.04 LTS to use Xorg by default」這邊,文章裡面給了三個理由:

  • Screen sharing in software like WebRTC services, Google Hangouts, Skype, etc works well under Xorg.
  • Remote Desktop control for example RDP & VNC works well under Xorg.
  • Recoverability from Shell crashes is less dramatic under Xorg.

講白了就是還有一堆東西有問題,看起來在 17.10 導入 Wayland 後沒搞定:

17.10, released in October 2017, ships with the Wayland based graphics server as the default and the Xorg based equivalent is available as an option from the login screen.

在 18.04 預設會用 Xorg,但系統內還是會有 Wayland 讓使用者可以選:

The Wayland session will still be available, pre-installed, for people to use, but for our ‘out of the box’ users the Ubuntu experience needs to be stable and provide the features they have come to expect and use in daily life and Xorg is the best choice here, at least for 18.04 LTS, but for 18.10 we will re-evaluate Wayland as the default.

再測個兩年吧 XD

針對 Ubuntu 16.04 + PPPoE 時,OpenNTPD 的 -s 不會在啟動時直接校正的問題 workaround...

發現機器時間跟標準時間差了 40 秒左右,結果有些服務因為會看雙方時間,就不讓我跑... XDDD

找問題找了半天,發現開機後 ntpdate 會回報找不到伺服器,看起來是網路根本就還沒通就跑起來了:

Jan 25 13:10:30 home ntpdate[757]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1171]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1347]: name server cannot be used: Temporary failure in name resolution (-3)
Jan 25 13:10:30 home ntpdate[1410]: name server cannot be used: Temporary failure in name resolution (-3)

而理論上 與 openntpd 加上 -s 也會做類似的事情,所以這邊就在 /etc/default/openntpd 先加上 -s,讓他開機時強制對時一次,看看能不能解... 結果也是一樣在網路還沒通的時候就跑起來而失敗了:

Jan 25 13:10:45 home ntpd[1457]: no reply received in time, skipping initial time setting

由於這台機器是 HiNet 的 PPPoE,看起來有可能是某些條件沒寫好,造成執行順序不對... 所以就找個 workaround 來解決 @_@

後來找的方法是直接到 /etc/ppp/ip-up.d/ 下放一個 script 實作 workaround,直接在 PPPoE 連上後重跑 openntpd,然後用 hwclock 寫回主機裡,下次開機的時間就會比較準一些了:

#!/bin/sh -e

/usr/sbin/service openntpd restart
/sbin/hwclock -w

不過實際上還是要找看看要怎麼把 PPPoE 掛到 networking 那層行為裡面...

Percona 版本的 MySQL 對於 Meltdown/Spectre 漏洞修復造成的效能損失 (Intel 平台)


PerconaUbuntu 16.04 上測試 MeltdownSpectre 這兩個安全漏洞的修正對於效能的影響。在原文標題就講了結論,為了修正 Meltdown 與 Spectre 兩個安全漏洞,效能的損失很明顯:「20-30% Performance Hit from the Spectre Bug Fix on Ubuntu」。

這邊測的結果發現,在 CPU bound 時的損失大約是 20%~25% (甚至到 30%),而 I/O bound 會輕一些,大約是 15%~20%:

We can see that in CPU-bound workloads the overhead is 20-25%, reaching up to 30% in point select queries. In IO-bound (25G buffer pool) workloads, the observed overhead is 15-20%.

在 comment 的地方 Percona 的人被問到 AMD 平台上效能會損失多少的問題,但因為他們手上目前沒有 AMD 平台的新機器所以不知道會有多少:

I do not have modern AMD servers on my hands right now

理論上 AMD 平台不需要處理 Meltdown 問題,損失應該會少一些,但沒測過也不曉得會是什麼情況... (像是 Spectre 的修正損失會不會比 Intel 還重,這之類的...)

另外補上早些時候的文章,當時 Ubuntu 上的 kernel 只有對 Meltdown 攻擊的修正,當時 Percona 的人也測了一次:「Does the Meltdown Fix Affect Performance for MySQL on Bare Metal?」,看起來對 Meltdown 攻擊的修正對效能的影響不太大,不過文裡有測試到 syscall 的效率的確如同預期掉很多。

Working Set Size (WSS) 的想法

NetflixBrendan Gregg (他比較知名的發明是 Flame Graph) 寫了一篇「How To Measure the Working Set Size on Linux」,他想要量測單位時間內會用到的記憶體區塊大小:

The Working Set Size (WSS) is how much memory an application needs to keep working. Your app may have populated 100 Gbytes of main memory, but only uses 50 Mbytes each second to do its job. That's the working set size. It is used for capacity planning and scalability analysis.

這可以拿來分析這些應用程式是否能夠利用 L1/L2/L3 cache 大幅增加執行速度,於是就可以做成圖,像是這樣:

在 Netflix 這樣人數的公司,需要設計一些有用的指標,另外發展出對應的工具,讓其他人更容易迅速掌握狀況,畢竟不是每個人都有上天下海的能力,遇到狀況可以馬上有頭緒進行 trouble shooting...

Ubuntu 開始更新 Kernel 了...

這波 CPU 安全問題,UbuntuLinux Kernel 的更新計畫 (workaround patch) 放在「Information Leak via speculative execution side channel attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 aka Spectre and Meltdown)」這邊。

不是所有版本的 kernel 都有更新,像是我之前跑 4.10 發現這次沒在清單內,就換成 linux-image-generic-hwe-16.04-edge 了... 換完後需要再裝 linux-headers-generic-hwe-16.04-edge,然後把舊的 kernel 都清乾淨,最後 nvidia-387 需要重新編過。


Ubuntu 下調整滑鼠的速度...


這時候就得調其他東西了,我是參考「Fix Mouse Sensitivity in Ubuntu 16.04」這邊的說明來調整的。測過 xset 會動後,把檔案丟到 ~/.config/autostart/mouse.desktop 裡面讓他登入後生效:

[Desktop Entry]
Name=Decrease mouse sensitivity
Exec=xset m 1/2 8
Comment[en_US]=Use xset to set mouse params
Comment=Use xset to set mouse params


Linus (又) 不爽了... XD

看得出來 Linus 對於 Intel 的行為很不爽:「Re: Avoid speculative indirect calls in kernel」。

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything


 - these workarounds should have a way to disable them.

Which of the two is it?

那個 possibibilities 應該是 typo,但不知道為什麼看起來很有味道 XDDD

Spectre 與 Meltdown 兩套 CPU 的安全漏洞

The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章,算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看),引用了蠻多資料並且試著說明問題。

而這也使得整個事情迅速發展與擴散超出本來的預期,使得 GoogleProject Zero 提前公開發表了 Spectre 與 Meltdown 這兩套 CPU 安全漏洞。文章非常的長,描述的也比 The Register 那篇還完整:「Reading privileged memory with a side-channel」。

在 Google Project Zero 的文章裡面,把這些漏洞分成三類,剛好依據 CVE 編號分開描述:

  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)

前兩個被稱作 Spectre,由 Google Project Zero、Cyberus Technology 以及 Graz University of Technology 三個團隊獨立發現並且回報原廠。後面這個稱作 Meltdown,由 Google Project Zero 與另外一個團隊獨立發現並且回報原廠。

這兩套 CPU 的安全漏洞都有「官網」,網址不一樣但內容一樣:spectreattack.commeltdownattack.com

影響範圍包括 IntelAMD 以及 ARM,其中 AMD 因為架構不一樣,只有在特定的情況下會中獎 (在使用者自己打開 eBPF JIT 後才會中):

(提到 Variant 1 的情況) If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU.

這次的洞主要試著透過 side channel 資訊讀取記憶體內容 (會有一些條件限制),而痛點在於修正 Meltdown 的方式會有極大的 CPU 效能損失,在 Linux 上對 Meltdown 的修正的資訊可以參考「KAISER: hiding the kernel from user space」這篇,裡面提到:

KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

KAISER 後來改名為 KPTI,查資料的時候可以注意一下。

不過上面提到的是實體機器,在 VM 裡面可以預期會有更多 syscall 與 context switch,於是 Phoronix 測試後發現在 VM 裡效能的損失比實體機器大很多 (還是跟應用有關,主要看應用會產生多少 syscall 與 context switch):「VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches」。

With these VM results so far it's still a far cry from the "30%" performance hit that's been hyped up by some of the Windows publications, etc. It's still highly dependent upon the particular workload and system how much performance may be potentially lost when enabling page table isolation within the kernel.

這對各家 cloud service 不是什麼好消息,如果效能損失這麼大,不太可能直接硬上 KPTI patch... 尤其是 VPS,對於平常就會 oversubscription 的前提下,KPTI 不像是可行的方案。

可以看到各 VPS 都已經發 PR 公告了 (先發個 PR 稿說我們有在注意,但都還沒有提出解法):「CPU Vulnerabilities: Meltdown & Spectre (Linode)」、「A Message About Intel Security Findings (DigitalOcean)」、「Intel CPU Vulnerability Alert (Vultr)」。

現在可以預期會有更多人投入研究,要怎麼樣用比較少的 performance penalty 來抵抗這兩套漏洞,現在也只能先等了...