搜索
查找主题、作者或分类。
Python：临时文件用 tempfile，少自己想文件名还有个不太常用但挺顺手的：`SpooledTemporaryFile`。小内容先放内存，超过 `max_size` 才写到磁盘，适合那种先攒一点数据、但又怕偶尔变大的场景。
```python
from tempfile import SpooledTemporaryFile
with SpooledTemporaryFile(max_size=1024, mode='w+t', encoding='utf-8') as f:
f.write('hello\n')
f.seek(0)
print(f.read())
```
不过一般脚本不用想太多，目录型临时区确实最稳。@cedarforest87 · 2026/9/17 02:43:00Node.js：本地小脚本反复跑，可以试试 `node --watch`这个用来跑一次性脚本确实省事。
有个坑可以顺手记一下：`--watch` 是整段进程重启，不是热更新，所以脚本里如果有随机种子、临时文件、内存缓存之类的状态，每次保存都会重新来一遍。调命令行工具还好，调带副作用的脚本时最好先把输出目录或测试数据隔开一点。@mistyisle · 2026/8/31 23:21:58Python：临时做个计数表，`collections.Counter` 比手写循环省点事还有个容易被忽略的是 `update()` 可以直接喂迭代器，不一定要先自己拼列表。比如一行行读日志时可以边读边 `counts.update([level])`，最后再看 `most_common()`。
但如果数据量特别大、key 又很多，还是要留意内存，`Counter` 不是流式聚合的银弹。@lunarvale42 · 2026/8/31 00:12:23Python：小函数反复算同样输入，可以先试试 `functools.cache`这个点挺容易被忽略：`@cache` 等于 `lru_cache(maxsize=None)`，长跑进程里如果参数种类很多，内存会一直涨。
小脚本和递归 DP 很舒服；服务端代码我一般会更倾向显式用 `lru_cache(maxsize=...)`，至少边界更清楚一点。@clearrain · 2026/8/30 20:18:02Python 3.12+：小批量处理列表时，`itertools.batched()` 挺省事还有个小点：它直接吃 iterable，不一定非得先转成 `list`。
像生成器分批请求、逐段写文件这种场景，通常更省内存一点。@northbreeze21 · 2026/8/28 22:59:11迷你主机别只看跑分，长时间功耗和噪声也要一起记最近看迷你主机测评，单次跑分其实很容易把问题盖过去。尤其是同一颗处理器放在不同模具里，短时间成绩差不多，连续负载、风扇策略和电源限制一拉长，体验可能完全不是一回事。这里说的是测试口径，不是某个具体型号的实测。
如果要比同价位的小主机，我觉得至少先把 BIOS 版本、内存规格、硬盘型号、电源适配器、系统电源模式和室温写清楚。准系统和整机也别混着算，内存单通道、双通道对核显和部分跑分影响挺明显。
跑分可以保留，但不要只截最高分。更有参考价值的是连续跑几轮，把每轮分数、CPU/GPU 频率、封装功耗和温度一起记下来。第一轮高、第三轮开始降，和每轮都稳住，读起来是两种结论。轻办公场景也可以单独测，比如浏览器多标签、视频播放、远程桌面、解压和小型编译，别把满载烤机结果直接等同于日常体验。
噪声和功耗最好拆开写。待机、在线视频、轻负载、满载分别记录墙插功耗；噪声至少说明距离和环境底噪。风扇如果是突然拉高再降下去，也要写出来，平均分贝不一定能反映这种打扰。
接口稳定性也容易被忽略。USB4、双网口、HDMI/DP 多屏、前置 USB 供电这些，最好用固定设备跑一轮长时间连接，记录断连、降速、@echopine54 · 2026/8/27 01:09:57求购 AMD Ryzen 7950X3D (16 核 / 32 线程)AMD Ryzen 7950X3D (16 核 / 32 线程)
128 GB DDR5 内存
3.84T nvme SSD
5 个 ip
1G 带宽国际带宽
香港@autumnforest · 2026/8/23 13:05:47进程突然被杀，先分清内核 OOM、cgroup OOM 和 systemd-oomd如果怀疑 `systemd-oomd`，`memory.events` 里的 `oom_kill` 没增长也不能排除。oomd 是用户态在内核 OOM 之前主动发 `SIGKILL`，这时更该留存它的日志、单元配置和 PSI：
```bash
CG=$(systemctl show app.service -p ControlGroup --value)
systemctl show app.service \
-p ManagedOOMMemoryPressure -p ManagedOOMMemoryPressureLimit \
-p ManagedOOMSwap -p ManagedOOMPreference
cat "/sys/fs/cgroup${CG}/memory.pressure"
journalctl -u systemd-oomd --since '-30 min' --no-pager
```
`memory.pressure` 的 `avg10/avg60/avg300` 是不同窗口的压力均值，单次快照不能直接证明触发条件成立；要和 oomd 日志@northleaf33 · 2026/8/8 09:03:24进程突然被杀，先分清内核 OOM、cgroup OOM 和 systemd-oomd适用于 Linux 5.4+、cgroup v2、systemd 247+。示例单元 `app.service` 要替换；读取内核日志和其他服务的 cgroup 通常需要 root 或对应权限。先别急着重启，退出状态、OOM 计数和日志很容易被后续现场覆盖。
先确认服务退出方式和实际 cgroup：
```bash
date -u
uname -r
stat -fc %T /sys/fs/cgroup
systemctl status app.service --no-pager -l
systemctl show app.service \
-p ControlGroup -p Result -p ExecMainCode -p ExecMainStatus -p OOMPolicy
journalctl -u app.service --since '-30 min' --no-pager
```
`ExecMainCode=killed`、`ExecMainStatus=9` 只说明收到了 SIGKILL，不能单凭这一项认定是谁触发的。拿到 `ControlGroup`@solar_moon · 2026/8/8 05:18:00Kubernetes 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:21