我有一个框架,由在多用户环境中用python编写的不同工具组成.
我第一次登录系统并启动一个命令只需要6秒钟就可以显示一些帮助.如果我立即再次发出相同的命令则需要0.1秒.几分钟后,它又恢复到6秒.(短期缓存的证明)
系统位于GPFS上,因此磁盘吞吐量应该没问题,但由于系统中的文件数量较多,访问可能会很少.
strace -e open python tool | wc -l
Run Code Online (Sandbox Code Playgroud)
显示启动工具时正在访问的2154个文件.
strace -e open python tool | grep ENOENT | wc -l
Run Code Online (Sandbox Code Playgroud)
显示1945个丢失的文件正在查找中.(一个非常糟糕的命中/错过率你问我:-)
我有一种预感,即通过向GPFS查询所有这些文件来消耗加载工具所花费的时间过长,并且这些文件被缓存用于下一次调用(在系统或GPFS级别),尽管我不知道如何测试/证明给我看.我没有对系统的root访问权限,我只能写入GPFS和/ tmp.
有可能改善这个python quest for missing files吗?
如何以简单的方式测试这个?(重新安装/ tmp上的所有内容并不简单,因为涉及很多软件包,virtualenv也无济于事(我认为),因为它只是链接gpfs系统上的文件).
一个选项当然是拥有一个可以分叉的守护进程,但这远非"简单",而且是最后的解决方案.
谢谢阅读.
使用imp模块怎么样?特别是有一个函数:imp.find_module(module, path) 这里http://docs.python.org/2.7/library/imp.html
至少这个例子(见下文)减少了 open() 系统调用的数量与简单的“import numpy,scipy”相比:(更新:但看起来不可能通过这种方式显着减少系统调用......)
import imp
import sys
def loadm(name, path):
fp, pathname, description = imp.find_module(name,[path])
try:
_module = imp.load_module(name, fp, pathname, description)
return _module
finally:
# Since we may exit via an exception, close fp explicitly.
if fp:
fp.close()
numpy = loadm("numpy", "/home/username/py-virtual27/lib/python2.7/site-packages/")
scipy = loadm("scipy", "/home/username/py-virtual27/lib/python2.7/site-packages/")
Run Code Online (Sandbox Code Playgroud)
我想你最好还检查你的 PYTHONPATH 是否为空或很小,因为这也会增加加载时间。
| 归档时间: |
|
| 查看次数: |
3346 次 |
| 最近记录: |