V2EX › felix021 的所有回复 › 第 8 页 / 共 43 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 4 5 6 7 8 9 10 11 12 13 ... 43

❮

❯

2020 年 5 月 5 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (2)

@teawithlife 正经的语言都会实现相应的逻辑(用 madvise 通知系统可以回收不再用的页面)，否则无法支撑需要长时间运行的任务。不够正经的，比如 php，你看 php fpm 的配置里面有个 max_requests，处理 n 个任务后就重启一次，避免占着茅坑不拉屎。

2020 年 5 月 5 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (2)

@teawithlife 不是，文中说了，free/delete 以后得空洞，会被 madvise 调用通知 os，对应的 page 是可以回收的，建议再看一遍~

2020 年 5 月 3 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@scnace 嗯，我也发现了，我的 mbp 的 M 键最近不灵光，打字挺痛苦。。。

2020 年 5 月 2 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@xupefei 确实“有用”读起来更通顺一点

2020 年 5 月 2 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@cabing 定位不同，书本通常都很枯燥，而且需要大量基础概念的铺垫（需要循序渐进）

2020 年 5 月 2 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@lsj8924 OS 的话题就有点大了，进程调度，设备管理等，这篇关注点还是在内存上。

2020 年 5 月 2 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@aneureka 勉强按一周一篇……翻译相对好点，相比自己写，不那么费脑

2020 年 5 月 2 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@msg7086 查了下，stackoverflow 上说“Windows will allow a program to allocate more (virtual) memory than there is RAM on the machine, but ONLY if there is enough free disk space to be able to back the virtual memory requested by the program by disk if necessary.”，也就是仅限于 RAM + 虚拟内存

2020 年 5 月 2 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@xupefei 原文是 powerful，意思是有了 overcommit 以后，很难遇到返回 null 的情况了。

2020 年 5 月 2 日

回复了 felix021 创建的主题 › 程序员 › [译] Ｃ程序员该知道的内存知识 (1)

@cy476571989 我比较喜欢这种逐字逐句的翻译，自己琢磨用词，和背后的梗

2020 年 4 月 30 日

回复了 yukiloh 创建的主题 › MySQL › 有什么学习数据库的好资源吗

sqlzoo.net

2020 年 4 月 29 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@Cyshall

__libc_free()
_int_free()
heap_trim()
shrink_heap()
__madvise ((char *) h + new_size, diff, MADV_DONTNEED)

2020 年 4 月 29 日

回复了 sl0000 创建的主题 › C++ › C++ 之 new 函数疑问，你们也有这种情况吗？

@dearmymy pragma pack(1) 还是要慎用，可能会导致性能问题

2020 年 4 月 28 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@sariya 不是很准确。

比如某个页面 A 对应的地址空间是 0x66660000，被 madvise(free)标记了，如果 A 尚未被 kernel 回收，且进程需要写入 0x66660000，就可以继续用 A ；如果进程需要写入其他新的地址空间，应该还是需要重新分配的（这是我的推测，没验证过）。

对于另一个进程，新申请页面的时候，如果 OS 有可用的，那么优先用可用的，效率更高，不够的时候，再去回收 A 。

2020 年 4 月 28 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@sariya 对于其他进程，肯定是优先分配已经回收的页面；对于该进程，如果写入的是没被回收页面，那就不用额外分配。

2020 年 4 月 28 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@wangxiyu191 看起来 pglazyfree 是可以延迟回收的页面，pglazyfreed 是可以延迟回收且回收了的页面

2020 年 4 月 28 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@noogler67 哈哈哈天下文章一大抄，但我抄的有放参考链接了

2020 年 4 月 28 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@nuk 这是 jemalloc 的锅（我们这边还有因为 jemalloc 的其他 bug 导致 core 的 case ），glibc 也用 madv_dontneed 的；另外气球只是用来验证，不是用来解决问题的。