新增了 Linux Numa 笔记和 一个网络问题的 debug 笔记

src/zh/posts/Linux 内核/NUMA Balancing.md

@@ -0,0 +1,84 @@
+---
+title: NUMA Balancing
+
+# cover: /assets/images/cover1.jpg
+
+icon: page
+order: 1
+author: ChiChen
+date: 2023-10-17
+category:
+- 笔记
+- Linux 内核
+tag:
+
+- Linux 内核
+- NUMA
+- 
+sticky: false
+star: false
+footer:
+copyright: 转载请注明出处
+
+---
+
+
+## [numa_balancing in kernel doc](https://www.kernel.org/doc/Documentation/sysctl/kernel.txt)
+
+Enables/disables automatic page fault based NUMA memory
+balancing. Memory is moved automatically to nodes
+that access it often.
+
+Enables/disables automatic NUMA memory balancing. On NUMA machines, there
+is a performance penalty if remote memory is accessed by a CPU. When this
+feature is enabled the kernel samples what task thread is accessing memory
+by periodically unmapping pages and later trapping a page fault. At the
+time of the page fault, it is determined if the data being accessed should
+be migrated to a local memory node.
+
+The unmapping of pages and trapping faults incur additional overhead that
+ideally is offset by improved memory locality but there is no universal
+guarantee. If the target workload is already bound to NUMA nodes then this
+feature should be disabled. Otherwise, if the system overhead from the
+feature is too high then the rate the kernel samples for NUMA hinting
+faults may be controlled by the numa_balancing_scan_period_min_ms,
+numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms,
+numa_balancing_scan_size_mb, and numa_balancing_settle_count sysctls.
+
+---
+>numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms,
+numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb
+
+Automatic NUMA balancing scans tasks address space and unmaps pages to
+detect if pages are properly placed or if the data should be migrated to a
+memory node local to where the task is running.  Every `scan delay` the task
+scans the next `scan size` number of pages in its address space. When the
+end of the address space is reached the scanner restarts from the beginning.
+
+In combination, the `scan delay` and `scan size` determine the scan rate.
+When `scan delay` decreases, the scan rate increases.  The scan delay and
+hence the scan rate of every task is adaptive and depends on historical
+behaviour. If pages are properly placed then the scan delay increases,
+otherwise the scan delay decreases.  The `scan size` is not adaptive but
+the higher the `scan size`, the higher the scan rate.
+
+Higher scan rates incur higher system overhead as page faults must be
+trapped and potentially data must be migrated. However, the higher the scan
+rate, the more quickly a tasks memory is migrated to a local node if the
+workload pattern changes and minimises performance impact due to remote
+memory accesses. These sysctls control the thresholds for scan delays and
+the number of pages scanned.
+
+numa_balancing_scan_period_min_ms is the minimum time in milliseconds to
+scan a tasks virtual memory. It effectively controls the maximum scanning
+rate for each task.
+
+numa_balancing_scan_delay_ms is the starting `scan delay` used for a task
+when it initially forks.
+
+numa_balancing_scan_period_max_ms is the maximum time in milliseconds to
+scan a tasks virtual memory. It effectively controls the minimum scanning
+rate for each task.
+
+numa_balancing_scan_size_mb is how many megabytes worth of pages are
+scanned for a given scan.

src/zh/posts/template.md

@@ -11,7 +11,7 @@ category:
 tag:
     -
 # this page is sticky in article list
-sticky: true
+sticky: false
 # this page will appear in starred articles
 star: false
 footer: 

src/zh/posts/杂谈/Debug杂谈/could not dial endpoint 'orderer-api.127-0-0-1.nip.io.md

@@ -0,0 +1,95 @@
+---
+title: could not dial endpoint 'orderer-api.127-0-0-1.nip.io:8080' 问题解决
+
+# cover: /assets/images/cover1.jpg
+
+icon: page
+order: 1
+author: ChiChen
+date: 2023-10-18
+category:
+- 杂谈
+- 网络问题
+tag:
+
+- Debug
+- 网络问题
+- 
+sticky: false
+star: false
+footer:
+copyright: 转载请注明出处
+
+---
+
+## could not dial endpoint 'orderer-api.127-0-0-1.nip.io:8080'
+
+今天完成区块链实验的时候，在用 `IBM-BlockChain-Platform` vscode 插件完成实验内容的时候，在部署服务到 `Local Docker` 时出现了如下错误
+
+```http
+could not dial endpoint 'orderer-api.127-0-0-1.nip.io:8080'
+```
+
+刚开始的时候一直在想这个域名是什么，看起来是某个服务的端口，但是似乎这个过程中又没有让我登录，不可能不登陆就能访问这种 API 服务的吧。后来上网搜索发现 `.nip.io` 会被 DNS 服务器 rebind 成一个特殊的地址，例如 `hello.192.168.199.12.nip.io` 就会变成 `192.168.199.12` ，那么这个原来的地址理应是 `127.0.0.1` 也就是 `Localhost` ，我ping了一下
+
+``` bash
+ping orderer-api.127-0-0-1.nip.io
+```
+
+发现是能 ping 通的，但是我执行
+
+```bash
+nslookup orderer-api.127-0-0-1.nip.io
+```
+
+却发现输出为
+
+```text
+服务器:  UnKnown
+Address:  198.18.0.2
+
+名称:    orderer-api.127-0-0-1.nip.io
+Address:  198.18.0.147
+```
+
+这 DNS 服务器地址怎么看都不对劲啊，而且解析出来的也不对。为什么 DNS 会出错呢，因为这是在我个人电脑上运行的，我就换到平时实验室的开发环境里试一下，同样运行
+
+```bash
+nslookup orderer-api.127-0-0-1.nip.io
+```
+
+输出却是
+
+```text
+Server:         127.0.0.53
+Address:        127.0.0.53#53
+
+Non-authoritative answer:
+Name:   orderer-api.127-0-0-1.nip.io
+Address: 127.0.0.1
+```
+
+:::info
+127.0.0.53 是 Linux 的 systemd-resolve 机制的一个虚拟 DNS 服务器
+:::
+
+后来我想了一下，这个东西应该跟我 Windows 上开启的 `Clash for Windows` ， 有关系，它可能把这些流量都劫持了，用来做一些域名分流之类的工作，所以就无法实现 `DNS rebind` 了
+
+我只要把 `Clash for Windows` 退出，这个问题就不存在了
+
+```bash
+nslookup orderer-api.127-0-0-1.nip.io
+```
+
+返回
+
+```text
+服务器:  dns.google
+Address:  8.8.8.8
+
+非权威应答:
+名称:    orderer-api.127-0-0-1.nip.io
+Address:  127.0.0.1
+```
+
+不过 `新版本的 Clash Core` 应该解决了这个问题，因为我看到 [这里](https://github.com/Dreamacro/clash/blob/d034a408be42815e98f3aea80be24949946aea83/test/dns_test.go#L40)有针对这种情况的测试用例，不过是两个月前加上的，因为本人用的是 `2022.11` 版本的，所以才出现了这个问题。