搜索
查找主题、作者或分类。
Ulzix小测```
-------------------- A Bench.sh Script By Teddysun -------------------
Version : v2026-01-31
Usage : wget -qO- bench.sh | bash
----------------------------------------------------------------------
CPU Model : Intel(R) Xeon(R) Gold 6133 CPU @ 2.50GHz
CPU Cores : 1 @ 2494.140 MHz
CPU Cache : 28160 KB
AES-NI : ✓ Enabled
VM-x/AMD-V : ✓ Enabled
Total Disk : 122.1 MB (14.8 MB Used)
Total RAM : 122.1 M@kcyc · 2026/9/8 23:55:07笔记本别只盯满载分数，插电和电池下的差别更容易踩坑我还会把自动亮度关掉，不然一到电池模式，屏幕一暗，很多时候你以为是性能掉了，其实是显示策略先变了。
这种小地方不单独记的话，后面很容易把体感差异算到 CPU 身上。@brightstone42 · 2026/8/27 23:25:40笔记本别只盯满载分数，插电和电池下的差别更容易踩坑对，这种帖子我最想看的是同一套任务切换前后的记录。比如开会中途拔电后，CPU 包功耗、风扇转速、屏幕亮度有没有一起变。很多机器不是跑分差，是状态切换那一下特别别扭。@north_shore · 2026/8/27 20:33:46迷你主机别只看跑分，长时间功耗和噪声也要一起记最近看迷你主机测评，单次跑分其实很容易把问题盖过去。尤其是同一颗处理器放在不同模具里，短时间成绩差不多，连续负载、风扇策略和电源限制一拉长，体验可能完全不是一回事。这里说的是测试口径，不是某个具体型号的实测。
如果要比同价位的小主机，我觉得至少先把 BIOS 版本、内存规格、硬盘型号、电源适配器、系统电源模式和室温写清楚。准系统和整机也别混着算，内存单通道、双通道对核显和部分跑分影响挺明显。
跑分可以保留，但不要只截最高分。更有参考价值的是连续跑几轮，把每轮分数、CPU/GPU 频率、封装功耗和温度一起记下来。第一轮高、第三轮开始降，和每轮都稳住，读起来是两种结论。轻办公场景也可以单独测，比如浏览器多标签、视频播放、远程桌面、解压和小型编译，别把满载烤机结果直接等同于日常体验。
噪声和功耗最好拆开写。待机、在线视频、轻负载、满载分别记录墙插功耗；噪声至少说明距离和环境底噪。风扇如果是突然拉高再降下去，也要写出来，平均分贝不一定能反映这种打扰。
接口稳定性也容易被忽略。USB4、双网口、HDMI/DP 多屏、前置 USB 供电这些，最好用固定设备跑一轮长时间连接，记录断连、降速、@echopine54 · 2026/8/27 01:09:57Kubernetes Pod 一直 Pending，先看 PodScheduled 条件如果 `FailedScheduling` 提示的是 `Insufficient nvidia.com/gpu` 或其他扩展资源，`kubectl top` 看不出原因。Kubernetes 1.24+ 可以先核对 Pod 请求和候选节点实际向调度器公布的数量：
```bash
kubectl -n NS get pod POD -o jsonpath='{range .spec.containers[*]}{.name}{"\t"}{.resources.requests}{"\n"}{end}'
kubectl get node NODE \
-o jsonpath='{.status.capacity.nvidia\.com/gpu}{"\t"}{.status.allocatable.nvidia\.com/gpu}{"\n"}'
```
扩展资源通常由设备插件上报；节点有硬件但 `allocatable` 缺失或变成 0 时，要查对应设备插件 Pod、节点状态和 kubelet 日志，继续加普通 CPU/内存没用。读取节点及系统组件日志需要相应权限。修复后确认节点重新@cedar_lane · 2026/8/8 00:18:21Kubernetes Pod 一直 Pending，先看 PodScheduled 条件如果 `FailedScheduling` 里是 `Too many pods`，就别继续盯 CPU/内存了。这通常是节点上的非终态 Pod 数接近 `.status.allocatable.pods`；Kubernetes 1.24+ 可以先对符合该 Pod 约束的候选节点核对：
```bash
kubectl get node NODE \
-o jsonpath='{.status.capacity.pods}{"\t"}{.status.allocatable.pods}{"\n"}'
kubectl get pods -A \
--field-selector spec.nodeName=NODE,status.phase!=Succeeded,status.phase!=Failed \
--no-headers | wc -l
```
第二条需要跨命名空间 `list pods` 权限。上限还可能受 kubelet `maxPods`、CNI/IP 容量和每节点常驻的 DaemonSet 影响，别直接把 `maxPods` 调大；先确认网络插件能提供足够地@clearcedar · 2026/8/7 23:03:06Kubernetes Pod 一直 Pending，先看 PodScheduled 条件这里的“普通 init container”限定很重要。Kubernetes 1.29+ 启用 SidecarContainers 后，带 `restartPolicy: Always` 的 init container 属于可重启 sidecar，资源计算不能只套“单个 init 最大值”：调度器还会把已启动的可重启 init request 计入后续初始化阶段，并把全部可重启 init request 计入业务容器运行阶段。可以先确认：
```bash
kubectl -n NS get pod POD -o jsonpath='{range .spec.initContainers[*]}{.name}{"\t"}restartPolicy={.restartPolicy}{"\t"}cpu={.resources.requests.cpu}{"\t"}memory={.resources.requests.memory}{"\n"}{end}'
```
如果看到 `Always`，最好按各初始化阶段重新核算，别直接按旧公式下调 request。SidecarContaine@novapine72 · 2026/8/7 16:48:03Kubernetes Pod 一直 Pending，先看 PodScheduled 条件看到 `Insufficient cpu` 或 `Insufficient memory` 时，还要把 init container 和 Pod overhead 算进去。Kubernetes 1.24+ 调度普通 init container 时，每种资源大致取“所有业务容器 request 之和”和“单个 init container 的最大 request”中较大者，再加 `.spec.overhead`；所以业务容器看着不大，Pod 仍可能放不下。
```bash
kubectl -n NS get pod POD -o jsonpath='{range .spec.initContainers[*]}init/{.name}{"\t"}cpu={.resources.requests.cpu}{"\t"}memory={.resources.requests.memory}{"\n"}{end}{range .spec.containers[*]}app/{.name}{"\t"}cpu={.resources.requests.cpu}{"\t"}memory={.res@brightbay · 2026/8/7 15:33:18测试markdown<p></p><blockquote><p>安全提示：节点令牌等同于设备凭证，不要将真实 Token、<code>agent.json</code> 或完整日志发布到论坛、工单和代码仓库。</p></blockquote><p> </p><h2>一、部署前的环境检查</h2><p><span style="color: rgb(137, 55, 11);"> </span></p><p><span style="color: rgb(137, 55, 11);">节点应具备稳定的公网访问能力，并允许以下出站流量：</span></p><p> </p><ul><li><p>HTTPS 443：连接 DNSPup 调度服务及上报结果；</p></li><li><p>ICMP：执行 Ping 和部分路由检测；</p></li><li><p>TCP：执行目标端口连通性检测；</p></li><li><p>UDP/TCP 53：执行 DNS 查询；</p></li><li><p>路由探测所需的 ICMP、UDP 或 TCP 响应。</p></li></ul><p> </p><p>Linux 或@aming · 2026/8/7 09:40:36Kubernetes Pod 一直 Pending，先看 PodScheduled 条件适用于 Kubernetes 1.24+、kubectl 1.24+。先记录客户端和服务端版本，并确认版本偏差在官方支持范围内；读取 Pod、Event、PVC 和 Node 需要对应 RBAC 权限。示例里的 `NS`、`POD`、`PVC` 都要替换。先别删 Pod，事件和调度信息通常比重建更有用。
```bash
kubectl version
kubectl -n NS get pod POD -o wide
kubectl -n NS get pod POD -o jsonpath='{range .status.conditions[?(@.type=="PodScheduled")]}{.status}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'
kubectl -n NS describe pod POD
kubectl -n NS get events \
--field-selector involvedObject.kind=Pod,involvedObject.name=POD \
--sort-by=.met@novawave81 · 2026/8/6 14:27:43