1

我总是发现npm uninstall要花费很长时间,并且正在尝试进行故障排除。大约 25 分钟前,我开始卸载四个软件包,它似乎停滞不前,没有任何进展,没有明显的 CPU 活动,也没有明显的磁盘活动(使用iotop)。我不知道这个问题可能是什么。

这是日志级别为“傻”的当前输出(匿名):

$ npm uninstall --save-dev -ddd gulp-autoprefixer gulp-sass gulp-sequence gulp-sourcemaps
npm info it worked if it ends with ok
npm verb cli [ '/path/to/home/bin/node-v0.12.2-linux-x64/bin/node',
npm verb cli   '/path/to/home/bin/node-v0.12.2-linux-x64/bin/npm',
npm verb cli   'uninstall',
npm verb cli   '--save-dev',
npm verb cli   '-ddd',
npm verb cli   'gulp-autoprefixer',
npm verb cli   'gulp-sass',
npm verb cli   'gulp-sequence',
npm verb cli   'gulp-sourcemaps' ]
npm info using npm@2.7.4
npm info using node@v0.12.2
npm verb unbuild node_modules/gulp-autoprefixer
npm verb unbuild node_modules/gulp-sass
npm verb unbuild node_modules/gulp-sequence
npm verb unbuild node_modules/gulp-sourcemaps
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-autoprefixer is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-autoprefixer
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-sass is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-sass
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-sequence is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-sequence
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-sourcemaps is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-sourcemaps
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-autoprefixer
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-sass
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-sequence
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-sourcemaps

...自从我启动它后不久,它就一直停在那里。较早的尝试一次删除一个包是可行的,但仍然在vacuum-fsstep 中停滞了一段时间(大约 30 秒)。我在具有 8 GB 内存、Node v0.12.2 和 npm 2.7.4 的四核 Intel i5 上运行 Ubuntu 14.04 LTS。

有谁知道问题可能是什么或如何进一步排除故障?

(顺便说一句,我不确定这是否是解决工具问题的适当 StackExchange 站点,所以如果不是,请另外推荐!)


编辑:我使用strace下面@dekkard 的回答做了一些调查;这是发生减速的区域的摘录(strace -f -t -o out.log npm uninstall -D gobble用作示例):

...
18327 17:00:52 rmdir("/path/to/home/myproject/node_modules/gobble/node_modules/minimatch" <unfinished ...>
18318 17:00:52 read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
18318 17:00:52 epoll_wait(5,  <unfinished ...>
18325 17:00:55 <... rmdir resumed> )    = -1 ENOTEMPTY (Directory not empty)
18325 17:00:55 write(8, "\1\0\0\0\0\0\0\0", 8) = 8
18325 17:00:55 rmdir("/path/to/home/myproject/node_modules/gobble/node_modules/mkdirp" <unfinished ...>
18318 17:00:55 <... epoll_wait resumed> {{EPOLLIN, {u32=8, u64=8}}}, 1024, -1) = 1
18318 17:00:55 read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
18318 17:00:55 epoll_wait(5,  <unfinished ...>
18328 17:00:58 <... rmdir resumed> )    = -1 ENOTEMPTY (Directory not empty)
18328 17:00:58 write(8, "\1\0\0\0\0\0\0\0", 8) = 8
18318 17:00:58 <... epoll_wait resumed> {{EPOLLIN, {u32=8, u64=8}}}, 1024, -1) = 1
18328 17:00:58 rmdir("/path/to/home/myproject/node_modules/gobble/node_modules/promise-map-series" <unfinished ...>
18318 17:00:58 read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
18318 17:00:58 epoll_wait(5,  <unfinished ...>
18326 17:01:01 <... rmdir resumed> )    = -1 ENOTEMPTY (Directory not empty)
18326 17:01:01 write(8, "\1\0\0\0\0\0\0\0", 8) = 8
18318 17:01:01 <... epoll_wait resumed> {{EPOLLIN, {u32=8, u64=8}}}, 1024, -1) = 1
...

在控制台中实时查看时,每个epoll_wait(5,输出和任何后续输出之间都会出现约 3 秒的停顿。想法?

4

2 回答 2

4

为了将来参考,根本问题是以下两件事的结合:

  1. 节点rimraf模块(由npm和许多其他包使用)首先尝试删除目录,并且仅在rmdir错误时读取其内容ENOTEMPTY(参见源代码中的这一行rimraf)。

  2. 我的项目文件夹位于 AFS 卷上,默认情况下,似乎 AFS 文件服务器会限制客户端连续发出太多失败的 RPC(向麻省理工学院学生信息处理委员会的人们致敬,因为他们通过电子邮件指出了这一点)。具体来说,默认设置为连续 10 多个失败的 RPC 设置 3 秒延迟。

最终结果是,rimraf依赖它的包在 AFS 卷上爬行的速度很慢,至少在我的机器上......虽然似乎有操作系统优化,以便在访问文件服务器之前提前至少使一些命令出错(例如http: //milek.blogspot.com/2014/01/mkdir-performance.htmlrmdir )根据上面的日志,在我的系统上似乎没有发生。

我在rimraf这里打开了一个问题:https ://github.com/isaacs/rimraf/issues/73

于 2015-05-18T01:05:06.510 回答
2

我建议找到您的 PID并使用ornpm uninstall附加到它:straceltrace

strace -c -p <PID>

http://linux.die.net/man/1/strace

-c
计算每个系统调用的时间、调用和错误,并在程序退出时报告摘要

此外,您可以过滤跟踪的调用(即文件、网络、信号等)

更新:

18318 17:00:52 epoll_wait(5, <unfinished ...>

您可以尝试向后滚动并找到对epoll_create()返回的epollfd== 5的调用,该调用稍后传递给epoll_wait(). 检查其周围的呼叫可能会提供一些线索。

于 2015-05-13T18:36:57.823 回答