擅长:python、mysql、java
<p>几乎可以肯定的是,您的内存已经用完了,这会导致操作系统使用<code>SIGABRT</code>进程中止您的内存</p>
<p>一般来说,解决这一问题意味着查看代码是如何使用内存的,在出现故障之前和出现故障时是如何使用内存的。(然而,过量大容量内存使用的实际“泄漏”可能是任意提前的,只有最后一个小的/适当的增量触发错误。)</p>
<p>特别是使用Python和利用Gensim <code>Word2Vec</code>类的<code>node2vec</code>工具时,需要尝试的内容包括:</p>
<p>在尝试过程中,观察Python进程大小的读数</p>
<p>至少在<code>INFO</code>级别启用Python日志记录,以了解导致崩溃的更多信息</p>
<p>此外,请确保:</p>
<ol>
<li>优化你的<code>walks</code>表以<em>而不是</em>组成一个大的内存列表。(Gensim的<code>Word2Vec</code>可以在<em>任何</em>长度的语料库上工作,包括那些比RAM大得多的语料库,只要(a)语料库通过可重写的Python序列从磁盘流式传输;(b)模型中的<em>唯一</em>单词/节点标记的数量可以在RAM中建模。)</li>
<li>确保模型中唯一字(令牌/节点)的数量不需要大于RAM允许的模型。日志输出一旦启用,将在主模型分配(可能失败)发生之前显示所涉及的原始大小。(如果失败,可以:(a)使用具有更多RAM的系统来容纳整个节点集;或者(b)或者使用更高的<code>min_count</code>值来丢弃更不重要的节点。)</li>
</ol>
<p>如果<code>Process finished with exit code 134 (interrupted by signal 6: SIGABRT)</code>错误不涉及Python、Gensim和&<code>Word2Vec</code>,您应该:</p>
<ol>
<li>搜索该错误的发生情况,并结合<em>您的</em>触发情况的更具体细节-创建错误的工具/库和代码行</李>
<li>查看适用于您的情况的常规<em>内存分析</em>工具,以确定代码可能在何处(甚至在最终错误之前很久)消耗几乎所有可用RAM</李>
</ol>