标签: kernel

我们正在尝试构建一个需要内核源代码的软件，而不仅仅是头文件。所以我们通过centos src rpm 下载了内核源码。

但是缺少 autoconf.h。

我们尝试了

• 将 .config 放在适当的位置（从 /boot 复制）。

• 跑 make oldconfig

那么什么是创建 autoconf.h 文件呢？我们真的必须构建内核吗？

如任务管理器中所示，我的 CPU 上的内核时间异常高。

有什么方法可以解决这个问题？

为什么这两个命令返回不同的结果？

lsmod | wc -l
100

ls /sys/module | wc -l
138

我在“Linux Debian-70-wheezy-64-minimal 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64”上收到此错误：

Message from syslogd@hostname at Feb 14 02:54:51 ...
kernel:[81927.464687] Uhhuh. NMI received for unknown reason 31 on CPU 3.

Message from syslogd@hostname at Feb 14 02:54:51 ...
kernel:[81927.464743] Do you have a strange power saving mode enabled?

Message from syslogd@hostname at Feb 14 02:54:51 ...
kernel:[81927.464791] Dazed and confused, but trying to continue

收到此信息后，服务器会重新启动。

我在其他一些网站上读到它与 CPU 环聊有关？但它们不是有用的资源。

我运行一个主要的媒体上传/下载站点，我注意到这些：

由于文件大小过大，这是严重的还是背景噪音，我是否可以向 /etc/sysctl.conf 添加任何调整以改进和防止问题？

[8822139.804040] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired)
[8822140.944041] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired)
[8822143.224052] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired)
[8822147.776079] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired)
[8822156.896049] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired)
[8822175.136049] TCP: Peer 177.47.116.196:53829/80 unexpectedly shrunk window 2513116350:2513136117 (repaired)
[8900596.808027] TCP: Peer 101.109.227.138:56284/80 unexpectedly shrunk window 1388148754:1388196670 (repaired)
[8900598.444020] TCP: Peer 101.109.227.138:56284/80 unexpectedly shrunk window 1388148754:1388196670 (repaired)
[8914737.204037] TCP: Peer 2.238.243.60:63238/80 …

Ubuntu 12.04

我试图更好地了解 TCP 在未收到目的地收到的确认时将尝试重新传输数据包的次数。阅读tcp 手册页后，似乎很明显这是由 sysctl tcp_retries1 控制的：

tcp_retries1 (integer; default: 3)
           The number of times TCP will attempt to retransmit a  packet  on
           an  established connection normally, without the extra effort of
           getting the network layers involved.  Once we exceed this number
           of retransmits, we first have the network layer update the route
           if possible before each new retransmit.  The default is the  RFC
           specified minimum of 3.

我的系统设置为默认值 3：

# cat /proc/sys/net/ipv4/tcp_retries1 
3

为了对此进行测试，我通过 ssh …

在将系统从一台服务器移动到另一台服务器后，我正在尝试修复我的系统。它与通过网络启动的内核完美配合，但不能从磁盘启动。

重新安装 CentOS 6.6 内核显示此错误：

grubby fatal error: unable to find a suitable template

我的 /boot/grub/grub.conf 文件看起来不错：

default=0
timeout=5
    title linux centos6_64
    kernel /vmlinuz-2.6.32-504.8.1.el6.x86_64 root=/dev/sda3  ro crashkernel=auto SYSFONT=latarcyrheb-sun16 LANG=pl_PL.UTF-8 KEYTABLE=pl
    root (hd0,1)
    initrd /initramfs-2.6.32-504.8.1.el6.x86_64.img

所有文件都已就位：

    ls -l /boot
razem 24645
-rw-r--r-- 1 root root   106312 01-28 22:40 config-2.6.32-504.8.1.el6.x86_64
drwxr-xr-x 3 root root     1024 2011-07-08  efi
drwxr-xr-x 2 root root     1024 03-06 13:44 grub
-rw------- 1 root root 18227613 03-06 13:44 initramfs-2.6.32-504.8.1.el6.x86_64.img
-rw-r--r-- 1 root root   200245 01-28 22:41 symvers-2.6.32-504.8.1.el6.x86_64.gz
-rw-r--r-- …

如果我使用我的机器 [Ubuntu 16.04 64 位，内核 4.4] 一段时间，QEMU 需要删除内核缓存，否则，它将无法分配 RAM。

为什么会发生？

这是一个示例运行：

~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          15050        5427        3690          56        5931        4803
Swap:             0           0           0

~$ sudo qemu-system-x86_64 -m 10240 # and other options
qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory

~$ echo 3 | sudo tee /proc/sys/vm/drop_caches
3

~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          15050        1799        9446          56        3803        9414
Swap:             0           0           0

~$ sudo …

我最近了解了 FreeBSD 的accept_filter套接字选项，它可以允许工作进程避免上下文切换，例如，等待直到收到完整的 HTTP 请求accf_http：

这是一个放置在套接字上的过滤器，该套接字将使用 accept() 接收传入的 HTTP 连接。

它阻止应用程序通过 accept() 接收连接的描述符，直到内核缓冲了完整的 HTTP/1.0 或 HTTP/1.1 HEAD 或 GET 请求。

如果收到的不是 HTTP/1.0 或 HTTP/1.1 HEAD 或 GET 请求，内核将允许应用程序通过 accept() 接收连接描述符。

accf_http 的效用使得服务器在执行请求的初始解析之前不必多次上下文切换。这通过将预分叉服务器（如 Apache）中的活动进程保持在较低水平并减少需要由接口（如 select()、poll() 或基于 kevent() 的服务器。

我的直觉是，在现代硬件上，通过高速连接（电缆调制解调器/DSL 速度或更好）向客户端提供流量，这可能是一种微优化。鉴于它accf_http不能用于 HTTPS 或 HTTP/2 连接并且accf_data只等待第一个字节，我在这里看不到太多优势。也许他们会保存一两个上下文切换？

是否有任何最近的（可能是 2015 年之后？）关于 FreeBSDaccept_filter实际可以提高多少性能或吞吐量/并发性的基准测试？

我执行了命令 apt autoremove 但这些文件夹仍然存在。

正如命令“du -h -x --max-depth=1 /usr/lib | sort -hr | head -n 10”向我展示的那样，它们目前每个都使用了近 1G：

858M    /usr/lib/modules
823M    /usr/lib/x86_64-linux-gnu

我该如何清理这个？谢谢。