« 有关英语阅读 | 返回首页 | 顿悟? »

极不和谐的 fork 多线程程序

继续前几天的话题。做梦幻西游服务器优化的事情。以往的代码,定期存盘的工作分两个步骤,把 VM 里的动态数据序列化,然后把序列化后的数据写盘。这两个步骤,序列化工作并没有独立在单独线程/进程里做,而是放在主线程的。IO 部分则在一个独立进程中。

序列化任务是个繁琐的过程。非常耗时(相对于 MMORPG 这个需要对用户请求快速反应的环境)。当玩家同时在线人数升高时,一个简便的优化方法是把整个序列化任务分步完成,分摊到多个心跳内。这里虽然有一些数据一致性问题,但也有不同的手段解决。

但是,在线人数达到一定后,序列化过程依然会对系统性能造成较大影响。在做定期存盘时,玩家的输入反应速度明显变大。表现得是游戏服务器周期性的卡。为了缓解这一点,我希望改造系统,把序列化任务分离到独立进程去做。

方法倒是很简单,在定期存盘一刻,调用 fork ,然后在子进程中慢慢的做序列化工作。(可以考虑使用 nice)做完后,再把数据交到 IO 进程写盘。不过鉴于我们前期设计的问题,具体实现中,我需要通过共享内存把序列化结果交还父进程,由父进程送去 IO 进程。

因为 fork 会产生一个内存快照,所以甚至没有数据一致性问题。这应该是一个网络游戏用到的常见模式。

可问题就出在于,经过历史变迁,我们的服务器已经使用了多线程,这使得 fork 子进程的做法变的不那么可靠,需要自己推敲一下。


多进程的多线程程序,听起来多不靠谱。真是闲得淡疼的人才会做此设计。但依旧可以使用万能的推辞:历史造成的。

在 POSIX 标准中,fork 的行为是这样的:复制整个用户空间的数据(通常使用 copy-on-write 的策略,所以可以实现的速度很快)以及所有系统对象,然后仅复制当前线程到子进程。这里:所有父进程中别的线程,到了子进程中都是突然蒸发掉的。

其它线程的突然消失,是一切问题的根源。

我之前从未写过多进程多线程程序,不过公司里有 David Xu 同学(他实现维护着 FreeBSD 的线程库)是这方面的专家,今天跟徐同学讨论了一下午,终于觉得自己搞明白了其中的纠结。嗯,写点东西整理一下思路。

可能产生的最严重的问题是锁的问题。

因为为了性能,大部分系统的锁是实现在用户空间的。所以锁对象会因为 fork 复制到子进程中。

对于锁来说,从 OS 看,每个锁有一个所有者,即最后一次 lock 它的线程。

假设这么一个环境,在 fork 之前,有一个子线程 lock 了某个锁,获得了对锁的所有权。fork 以后,在子进程中,所有的额外线程都人间蒸发了。而锁却被正常复制了,在子进程看来,这个锁没有主人,所以没有任何人可以对它解锁。

当子进程想 lock 这个锁时,不再有任何手段可以解开了。程序发生死锁。

为何,POSIX 指定标准时,会定下这么一个显然不靠谱的规则?允许复制一个完全死掉的锁?答案是历史和性能。因为历史上,把锁实现在用户态是最方便的(今天依旧如此)。背后可能只需要一条原子操作指令即可。大多数 CPU 都支持的。fork 只管用户空间的复制,不会涉及其中的对象细节。

一般的惯例,多线程程序 fork 前,应该由发起 fork 的线程 lock 所有子进程可能用到的锁,fork 后,把它们一一 unlock 。当然,这样的做法就隐含了锁的次序。如果次序和平时不同,那么就会死锁。

不光是显式的使用锁,许多 CRT 函数也会间接的使用。比如 fprintf 这些文件操作。因为对 FILE * 的操作是依靠锁来达到线程安全的。最常见的问题是在子线程里调用 fprintf 写 log 。

除此之外,就是要小心一些不依赖锁的数据一致性问题了。比如若在父进程里另一个线程中操作一个链表,fork 发生时,因为其它线程的突然消失,这个链表就可能会因为只操作了一半而是不完整的数据。不过这一般不会是问题,或者可以归咎于对锁的处理。(多个线程,访问同一块数据。比如一条链表。就是需要加锁的)

最后引用讨论中, David Xu 的话 “POSIX这个问题一直是讨论的热门话题。而且双方立场很清楚,一方是使用者,另外一方是实现者,双方互相指责”


突然想到,lua / java 这些 VM 的实现,是不是可以利用 fork 来缓解 gc 造成的停滞呢?只需要在 gc 时,fork 一份出来做扫描。找到不被引用的垃圾,

Comments

Thank you for your sharing

序列化任务是个繁琐的过程

I met this situation too. After fork(), all thread were disappeard and the thread condition led hang.

This blog is very helpful for me to understand the issue.

Thanks.

1.主线程将增量数据交给新线程(swap,不是复制哦,前提是增量)
2.新线程处理序列化任务
3.新线程将处理结果交给主线程(同样不是复制)
4.主线程提交io操作

在多线程程序里使用fork是比较郁闷的事情;
不只是应用层的锁的问题;
很多C库里的函数调用也会出现死锁线程;
最好的办法是在多线程进程里不是用fork;
如果非使用不可,尽量fork完毕后直接exec,不调用任何其他除了fork之外的函数;
exec可以覆盖内存空间,可以解决所有关于锁的问题;

先fork()后再用pthread,唯一的可移植用法。

考虑再开个线程做序列化

jvm的gc有多线程的策略,而且就是需要在多cpu的条件下,性能能提高

你是想仿redis的策略?

忘了,只有一个进程了,应该可以由新线程提交io操作吧
1.主线程将增量数据交给新线程(swap,不是复制哦,前提是增量)
2.新线程处理序列化任务
3.新线程提交io操作

如果要序列化的数据是按增量记录的,是否可考虑再开个线程做序列化。多线程加多进程想想就恐怖。
1.主线程将增量数据交给新线程(swap,不是复制哦,前提是增量)
2.新线程处理序列化任务
3.新线程将处理结果交给主线程(同样不是复制)
4.主线程提交io操作

可以在子进程的serialize代码中避免使用lock。

为啥不用Erlang/OTP

如果使用MMAP有帮助吗?或者共享内存,有另外一个进程来做持续化。

Post a comment

非这个主题相关的留言请到:留言本