在项目中发现经常有这种需求,需要加载一些大的固定的格式化数据,比如对战中的一些技能数据,物品等。这些数据都是只读数据,并且可能会比较大,目前来看大约有上万条复杂数据,如果serialize的话,纯文本有20M左右。尝试过直接放一个array在php文件里,结果发现require这个文件很耗时,可能会花费几十ms的时间,并且这个时候io很重,因为需要加载几十m数据到内存;另外去调研了一下sqlite,这个东西还算比较靠谱,但问题在于,比如写操作函数,使用起来很不爽;于是就产生了自己写一个扩展的想法。于是折腾之旅就此展开。
一开始想的是,直接在MINIT里调用zend_execute_script方法来加载一个php文件,返回一个zval来存储到全局变量里。结果后来仔细一琢磨发现根本就是妄想。原因在于MINIT的时候php的vm还没初始化完,不可能让你调用zend_execute_script方法,并且这个方法也不会返回一个zval,要想拿到zval必须从EG中去拿,很麻烦。
于是转换思路,尝试用unserialize/serialize,结果发现,php_var_unserialize在MINIT阶段果然是可以调用的。于是开搞,调用这个方法得到一个zval,然后存在全局变量里,在get方法里返回这个zval。写完之后,在测试的时候杯具的发现,只要调用就会core呀。于是查文档,自己思考,最终发现PHP_RSHUTDOWN_FUNCTION函数里会将所有非pealloc分配的的变量给清除。因此在MINIT阶段还正常的数据,到了Request阶段已经被free了。
于是再查文档,发现php里提供了pealloc这类函数来提供persistent的数据分配。于是再转换思路,将全局变量里的hashtable用pealloc来分配,并且将hastable设置成persistent的(谢天谢地php的hashtable还要存代码和vm,因此有这个功能)。但是杯具的是php_unserialize只会返回一个zval,你根本无法控制它是否是persistent的。没办法,只能调用zend_hash_copy来做了。写完之后再测试,发现还是core,这就不明白了,为啥呢?中午吃饭的时候,突然想到,可能是浅拷贝的问题,zend_hash_copy提供了一个copy函数而我没有设置它。再加上深拷贝函数之后再测试,发现果然可以用了,使用起来很清爽。 www.2cto.com
接下来进行测试发现,内存使用率不能忍,一个20m的数据文件加载到内存,需要大约100m左右的内存,如果有100个php-cgi进程,那就多要10G内存,这根本不能忍。于是设想,可以用共享内存来解决这个问题,反正这部分数据只要能读就行了。php-cgi的主进程负责MINIT操作,子进程只要读这部分数据就行了。但是很麻烦的是,php里没提供任何让用户维护内存的接口,于是只能一个函数一个函数的扒了。
仔细看了一下php的hashtable实现,发现比较复杂,而且关键用到了realloc函数,这个太让人无语了,总不能我也写一个内存管理吧。目前只用共享内存实现了一个简单的线程分配内存的函数,从共享内存上依次往后分配空间。但是还好,这部分功能是resize功能根本不需要。因为我的目标是将php_var_unserialize里得到的zval拷贝到共享内存而已,而大小我明显已经知道了。并且也不需要updatea功能,因为是全新的copy。最终弄完之后,发现可以使用了,内存使用率果然降了。
接下来进行压力测试,突然发现又开始core了,这根本不能忍呀,为啥呀?根据core文件,发现是里面的hashtable的refcount降到0了。于是各种测试,发现单线程情况下是ok的,只有多线程大压力情况下会挂。于是想到refcount是会被修改的,而且多线程修改的话,必须可能被改乱。那怎么办呢?总不能加锁吧。
后来仔细想了一下,突然想到只要我每次在返回这个zval里将顶层的zval的refcount修改为大于php-cgi进程数的值,那即使会被改乱也没啥问题,因为根本不会改到0。于是修改了之后再测试,发现果然靠谱了。
到此,整个问题基本解决。但是还有另外一个问题,在重启Php-cgi时还是会core,原因是,当时把正在使用的一些变量给强制写成0了。其实共享内存的正确用法是,一个进程来写,另外的进程来读,但是我这个应用里将共享内存当做绝对地址在使用,因此不可能在一个地方写,在其他地方读,除非shmat里的第二个参数修改为固定值,但是这个就需要对进程的地址分配有充分的了解,知道哪些内存根本不可能被使用。不过这个应该还好,因为Php-cgi进程有内存上限,所以应该可以找到一块内存在php-cgi运行过程中无法被用到的。不过具体的情况得接下来具体研究一下。
作者 无心云