epiphyllum 最近的时间轴更新
epiphyllum

epiphyllum

V2EX 第 679565 号会员,加入于 2024-03-09 22:44:00 +08:00
今日活跃度排名 734
epiphyllum 最近回复了
2 天前
回复了 gegeligegeligo 创建的主题 问与答 找到系统变卡的原因了
按下开机键时电脑有连接电源吗?

(可以试着下载一个 ThrottleStop ,里面的 Limit Reasons 部分会给出粗略的 CPU 受限原因

2 天前
回复了 lslqtz 创建的主题 Telegram tg 号突然没了, 有类似的软件推荐吗
应该要多等几天?(看见有群 u 是大概 7 天解封的)
毕竟 Telegram 他们公司只有不到 50 个员工,但是整个平台有 9 亿用户。

Telegram 在收到申请并审核后有可能不会回邮件直接解封,可以隔一段时间试一下账号能不能登录。


替代的话,除了 tg 和 signal 应该还有 Matrix 和 Discord
44 天前
回复了 kingmo888 创建的主题 Chrome 上不了 v2,才发现 chrome 把插件给删了
@v2tudnew #26
1.
> 你那张图无非是虚拟内存占满了,肯定是崩溃的,我上面已经说了你可以调大页面文件,实际它不会立即写入。
图上并不是虚拟内存占满了。程序要操作系统承诺(commit)大量内存≠进程真的要利用那么多内存(包括物理 RAM 和各种形式的虚拟内存)
例如:


2.
> 这种情况不是和 overcommit 一样的效果,没有 oom-killer 的情况下 Linux 内存占满它就不会崩了?
“Linux 内存占满后会不会崩”我不敢打包票,毕竟哪怕我是神仙我也不能超过物理限制;但这里的多个例子已经展示了 Windows 上物理 RAM 和虚拟内存两个都没占满甚至还有大量空闲的情况下就有进程崩了。overcommit 是灵活的变通手段不是死板杀进程的限制。

3.
> 所以关键的还是 oom-killer 杀死进程,但普通人如何配置哪些进程被杀死?
同上,Linux 出现 oom-killer 是「内存真占满了」的极端情况,Windows 上离极端情况还差得远的时候就开始拒绝内存申请。保不住后台的“小工具”,更不一定能保住高资源占用率的关键应用。
况且能给用户更大的选择权总归是好的。


4.
> 像手机游戏就经常被杀,加大学习成本研究守护方法。

拿移动端来比就没意思了。手机为了便携就必须在硬件规格上妥协(有限得多的电源供应、算力和内存大小),必须在续航能力/流畅度上想办法优化,这是操作系统有意而为之的设计。

以 Android 为例:当年 Android 2.3/4.x/5.x 的年代用户还得自己开黑阈/阻止运行/绿色守护主动关闭杀后台进程,要不然 xx 手机卫士/xx 手机管家/某宝/某些即时通讯软件/xx 手机助手怕是得在手机里闹翻天。
如今 Google 和国产手机厂商都学聪明了,手机硬件配置不断升级的今天,各种 XXUI/XXOS 的后台进程策略反而比当年严格得多。某三字购物软件更是靠“挖 CVE”来给自己提权保活。如今杀后台的可能不是 oom-killer ,更可能是手机自带的“系统管家”和操作系统的电池优化特性。


5.
> 默认 Windows 是所有分区分配页面文件的,自己不调没这个问题。
Windows 并不会默认在所有分区上创建 pagefile.sys 。
@v2tudnew #24

1. overcommit 在这篇帖子的场景下其实恰恰反而可以让操作系统上的进程更稳定,允许程序向操作系统“提交”多于虚拟内存+物理 RAM 大小的内存更像是一种宽恕,而不是严格的限制。
(要不然掌管服务器操作系统半壁江山的 Linux 上若是经常让关键业务和后台进程经常挂掉的话,那老板/员工/客户都得难受了)
(而且 Linux 上 overcommit 、oom 行为、swap/zram 都是有很多选项可以按自己需求灵活调整的)


2. 以 Linux 为例,杀死进程的并不是 overcommit 特性本身,而是 oom-killer 和内存分配失败导致的程序崩溃。

此外,假如真到了像是内存被占满必须得靠 oom-killer 出马杀几个进程祭天的场景,Windows 上“严格的限制”并不一定能保证后台挂着的游戏和大型任务能安稳地运行。
例如我在#16 楼发的截图:在“已提交”紧缺的时候,"System Informer"这种在后台挂着当资源监视器的小工具也会崩溃、Windows 控制面板也逃不过卡死。关键是它们崩溃时物理内存根本没占满甚至还有大量空闲。对于内存释放分配更频繁、空间请求和占用都更多的游戏和大型任务这很可能会更糟,毕竟进程的 Commit Charge 是不会小于实际内存用量的。
@ysc3839 #20
我觉得依赖虚拟内存技术(内存压缩/分页文件/SWAP )本身没问题,毕竟像 提高多任务能力/保留兼容性/压缩硬件成本 之类的好处都能给用户带来实实在在的收益。

问题其实还是操作系统在“依赖虚拟内存”的过程中容易出差错(依赖 SWAP/页面文件时没好好设计导致的),就像这里因为 Windows 缺乏灵活的"overcommit"设计导致了用户的程序在 RAM 仍有空闲的情况下崩溃; 系统没管理好类似"swappiness"这样的参数在当年让 macOS 用户的硬盘被大量异常写入、让 Windows 的分页文件占着大量存储空间却实际只有很一小部分被利用…

但是 Chrome 确实是真的出了名的吃内存(
进程“已提交”的内存超过“页面文件”和物理 RAM 大小的总和时就会出现这种情况(例如下图),这个问题是 Windows NT 的历史遗留问题造成的。
(很难想象 2024 年了 Windows 还在高度依赖虚拟内存,而且为了性能实际被 swap 进磁盘的页面其实很少,实在是浪费磁盘空间)

解决方法:

1. 在任务管理器里面找到“详细信息”选项卡,右键点击列标题区域(例如“名称”列),选择“选择列”。
把“已提交大小”勾上,排查一下哪些进程的已提交大小过高。

2. 还有一种情况是:楼主的系统分区可能空间不足,或者楼主修改了系统的虚拟内存相关设置。
(因为 Windows 默认会自动管理虚拟内存/页面文件的大小。当系统“已提交”大小达到系统提交限制的 90% 时,系统管理的页面文件会自动扩展到物理内存的 3 倍,但不会超过卷大小的 1/8 )

- 如果是这种情况并且磁盘空间足够的话,可以 Win+R 运行`sysdm.cpl`(控制面板->系统属性),修改系统设置让 Windows 多分配些虚拟内存(或者设为系统自动管理)


v2ex 启用了 Encrypted Client Hello 之后理论上一直都可以直连(需要 DNS 和浏览器支持)
https://www.v2ex.com/cdn-cgi/trace
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2084 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 10ms · UTC 07:57 · PVG 15:57 · LAX 23:57 · JFK 02:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.