卡桑德拉死于记忆:杀死过程或牺牲孩子

时间:2018-03-29 15:15:03

标签: cassandra datastax datastax-enterprise cassandra-3.0

我们有一个6节点集群,运行:

  • Cassandra 3.11.0.1900
  • DSE 5.1.5
  • Ubuntu 16.04.4 LTS
  • java-1.8.0-openjdk-amd64

其中一个节点在syslog中消失了以下消息:

  

[1770962.274743]内存不足:杀死进程49468(java)得分893或   牺牲孩子[1770962.299330]被杀的过程49468(java)   total-vm:1156754248kB,anon-rss:46906424kB,file-rss:176871432kB

节点上禁用交换,/proc/sys/vm/overcommit_memory设置为0.请注意,当/proc/sys/vm/overcommit_memory也设置为1时会发生这种情况。

不幸的是,Cassandra system.log中没有相关的错误消息(我们正在进行级别调试)。

关于可能导致此行为的任何想法?

1 个答案:

答案 0 :(得分:1)

看到此问题尚未得到解答,因此认为应该得到解答。这不是DSE / Cassandra的问题,而是可能意味着您根本没有足够的内存来运行主机上的内容。当OOM杀手获得一个进程时,通常它将杀死最大的进程。通常,在这种情况下使用DSE可能意味着您可能将import pandas as pd # read your example df = pd.read_csv( io.StringIO( r"""emp_id,col1,col2,col3 1234,abc|de,2020|2011,89 5639,ma,2010|2019,90""" ) ) # split and expand the column with pipe sign # expanded_col1 and expanded_col2 are dataframes # rename the column in order to find them after expanded_col1 = df.col1.str.split('|', expand=True).rename( lambda x: f'col1_{x}', axis='columns' ) expanded_col2 = df.col2.str.split('|', expand=True).rename( lambda x: f'col2_{x}', axis='columns' ) # create all combinations from values of string split to_concat = [] for col1, col2 in itertools.product(expanded_col1, expanded_col2): to_concat.append( pd.concat( [ # put back the initial column name expanded_col1.loc[:, [col1]].rename( lambda x: x.split('_')[0], axis='columns' ), expanded_col2.loc[:, [col2]].rename( lambda x: x.split('_')[0], axis='columns' ), ], axis='columns', ).dropna() ) result = pd.merge( # merge combinations and other columns df.drop(['col1', 'col2'], axis='columns'), # drop initial split columns pd.concat(to_concat), # concat all combinations left_index=True, right_index=True, ) 文件中的堆(Xmx)设置得太高。这只是您可能会想到的许多事情之一。

关于OOM杀手为何要获得进程还有其他细微差别,但这可能会涉及到很多事情,而又不知道您的系统设置以及其他难以确定的进程正在运行。

虽然您不会在DSE / Cassandra日志中看到任何消息,但这是很正常的,因为该过程由oom killer(例如 emp_id col3 col1 col2 0 1234 89 abc 2020 0 1234 89 abc 2011 0 1234 89 de 2020 0 1234 89 de 2011 1 5639 90 ma 2010 1 5639 90 ma 2019 )强制终止,因此日志只会停止。