`npm uninstall`挂起（或非常缓慢）而没有明显的活动

Question

我一直发现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-fs步骤停顿了一段时间（约30秒）。 我在具有8 GB内存，Node v0.12.2和npm 2.7.4的四核Intel i5上运行Ubuntu 14.04 LTS。

有谁知道问题可能在哪里或如何进一步排除故障？

（顺便说一句，我不确定这是否是适用于工具问题的StackExchange网站，所以如果不是，请建议否则！）

---

编辑：我根据下面@dekkard的回答使用strace侦查； 以下是发生减速的区域的摘录（以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,和任何后续输出之间epoll_wait(5, 3秒钟的停顿。

Answer 1

供以后参考，根本问题是以下两个方面的结合：

1. 节点rimraf模块（使用npm和许多其他包）通过第一试图删除一个目录，并且仅读出其内容，如果操作rmdir有错误ENOTEMPTY （见在此行rimraf源 ）。

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

最终结果是rimraf和依赖它的程序包会缓慢地爬网AFS卷，至少在我的机器上…虽然似乎有操作系统优化可以至少在击中文件服务器之前使某些命令错误（例如， http） ：//milek.blogspot.com/2014/01/mkdir-performance.html ），基于上述日志，我系统上的rmdir似乎没有发生。

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

Answer 2

我建议您找到npm uninstall的PID并使用strace或ltrace附加到它：

strace -c -p <PID>

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

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

另外，您可以过滤要跟踪的呼叫（即文件，网络，信号等）。

更新：

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

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