Neo4j:工作人员会话...崩溃。 Java堆空间OutOfMemoryError

weixin_38092506 weixin_38092506 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年,写一次发全网 我也要 + 加入社区

Spark正在运行: 这是一个非常简单的程序,它已经从java和'parallelized'转换为scala(它不打算并行运行,而是一个实验)学习spark和neo4j,b)看看我是否可以通过在更多节点上做更多工作的火花集群上运行来获得一些速度增益)。原因是大瓶颈是neo4j密码脚本中的空间调用(一个withinDistance调用)。测试数据集非常小,52,000个节点和大小为140 mb的数据库。 此外,当Neo4j的启动时,它给我的 Starting Neo4j. WARNING: Max 4096 open files allowed, minimum of 40000 recommended. See the Neo4j manual. /usr/share/neo4j/bin/neo4j: line 411: /var/run/neo4j/neo4j.pid: No such file or directory 这是奇怪的警告,因为我相信,这是打开的文件,我问的系统管理员设置,为一路走高? (ulimit -Hn似乎证实了这一点?说90,000虽然ulimit -a显示打开文件在4096(softlimit)我想这就是neo4j看到和呜呜) 此外,当我在我的Mac OS上本地运行X.软件会运行并执行大约14个小时左右(也许9次),然后我会在控制台中看到数据库会停止与火花交谈。它没有下降,或者任何类似的工作都会超时,我仍然可以在数据库中使用密码shell。但它会以某种方式失去与spark工作的联系,所以他们会尝试,最后火花提交会放弃并停止。 C02RH2U9G8WM:scala-2.11 little.mac$ ulimit -Hn unlimited (也从去年的编辑我甚至调升我的极限更在Neo4j的CONF,现在最大4GB内存堆大小) 从作业中的某些码位(使用移植的代码到斯卡拉与增加了火花数据框,我知道它并不合适,但希望在推进之前能有所作为)。我正在构建一个混合程序,就像我移植的java代码,但使用spark的数据框(连接到neo4j)。 本质(伪代码): while (going through all these lat and lons) { def DoCalculation() { val noBbox="call spatial.bbox('geom', {lat:" + minLat +",lon:"+minLon +"}, {lat:"+maxLat+",lon:" + maxLon +"}) yield node return node.altitude as altitude, node.gtype as gtype, node.toDateFormatLong as toDateFormatLong, node.latitude as latitude, node.longitude as longitude, node.fromDateFormatLong as fromDateFormatLong, node.fromDate as fromDate, node.toDate as toDate ORDER BY node.toDateFormatLong DESC"; try { //not overly sure what the partitions and batch are really doing for me. val initialDf2 = neo.cypher(noBbox).partitions(5).batch(10000).loadDataFrame val theRow = initialDf2.collect() //was someStr for(i <- 0 until theRow.length){ //do more calculations var radius2= 100 //this call is where the biggest bottle neck is,t he spatial withinDistance is where i thought //I could put this code ons park and make the calls through data frames and do the same long work //but by batching it out to many nodes would get more speed gains? val pointQuery="call spatial.withinDistance('geom', {lat:" + lat + ",lon:"+ lon +"}, " + radius2 + ") yield node, distance WITH node, distance match (node:POINT) WHERE node.toDateFormatLong < " + toDateFormatLong + " return node.fromDateFormatLong as fromDateFormatLong, node.toDateFormatLong as toDateFormatLong"; try { val pointResults = neo.cypher(pointQuery).loadDataFrame; //did i need to batch here? var prRow = pointResults.collect(); //do stuff with prRow loadDataFrame } catch { case e: Exception => e.printStackTrace } //do way more stuff with the data just in some scala/java datastructures } } catch { case e: Exception => println("EMPTY COLLECTION") } } } 运行该useses火花连接器连接到的Neo4j我得到这些错误在/var/log/neo4j/neo4j.log java.lang.OutOfMemoryError: Java heap space 2017-12-27 03:17:13.969+0000 ERROR Worker for session '13662816-0a86-4c95-8b7f-cea9d92440c8' crashed. Java heap space java.lang.OutOfMemoryError: Java heap space at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter(AbstractQueuedSynchronizer.java:1855) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2068) at java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:418) at org.neo4j.bolt.v1.runtime.concurrent.RunnableBoltWorker.run(RunnableBoltWorker.java:88) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) at org.neo4j.helpers.NamedThreadFactory$2.run(NamedThreadFactory.java:109) 2017-12-27 03:17:23.244+0000 ERROR Worker for session '75983e7c-097a-4770-bcab-d63f78300dc5' crashed. Java heap space java.lang.OutOfMemoryError: Java heap space 我知道Neo4j的火花提交工作.conf文件我可以改变heapsizes(目前注释掉,但设置为512米)我所要求的是它在conf文件中所说的内容: # Java Heap Size: by default the Java heap size is dynamically # calculated based on available system resources. # Uncomment these lines to set specific initial and maximum # heap size. 所以,这并不意味着我应该把这里的堆放在这里,如果他们的计算肯定会超过我所能设定的范围,那么这个堆栈就是这样吗? (这些机器有8个内核和8个内存RAM)。或者会专门设置这些真的有帮助?也许到2000年(如果它的兆字节),得到两个演出?我问,因为我觉得错误日志文件是给这个内存不足的错误,但它确实是由于不同的原因。 编辑调试我的jvm值。登录 BEFORE: 2017-12-26 16:24:06.768+0000 INFO [o.n.k.i.DiagnosticsManager] NETWORK 2017-12-26 16:24:06.768+0000 INFO [o.n.k.i.DiagnosticsManager] System memory information: 2017-12-26 16:24:06.771+0000 INFO [o.n.k.i.DiagnosticsManager] Total Physical memory: 7.79 GB 2017-12-26 16:24:06.772+0000 INFO [o.n.k.i.DiagnosticsManager] Free Physical memory: 5.49 GB 2017-12-26 16:24:06.772+0000 INFO [o.n.k.i.DiagnosticsManager] Committed virtual memory: 5.62 GB 2017-12-26 16:24:06.773+0000 INFO [o.n.k.i.DiagnosticsManager] Total swap space: 16.50 GB 2017-12-26 16:24:06.773+0000 INFO [o.n.k.i.DiagnosticsManager] Free swap space: 16.49 GB 2017-12-26 16:24:06.773+0000 INFO [o.n.k.i.DiagnosticsManager] JVM memory information: 2017-12-26 16:24:06.773+0000 INFO [o.n.k.i.DiagnosticsManager] Free memory: 85.66 MB 2017-12-26 16:24:06.773+0000 INFO [o.n.k.i.DiagnosticsManager] Total memory: 126.00 MB 2017-12-26 16:24:06.774+0000 INFO [o.n.k.i.DiagnosticsManager] Max memory: 1.95 GB 2017-12-26 16:24:06.776+0000 INFO [o.n.k.i.DiagnosticsManager] Garbage Collector: G1 Young Generation: [G1 Eden Space, G1 Survivor Space] 2017-12-26 16:24:06.776+0000 INFO [o.n.k.i.DiagnosticsManager] Garbage Collector: G1 Old Generation: [G1 Eden Space, G1 Survivor Space, G1 Old Gen] 2017-12-26 16:24:06.777+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: Code Cache (Non-heap memory): committed=4.94 MB, used=4.93 MB, max=240.00 MB, threshold=0.00 B 2017-12-26 16:24:06.777+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: Metaspace (Non-heap memory): committed=14.38 MB, used=13.41 MB, max=-1.00 B, threshold=0.00 B 2017-12-26 16:24:06.777+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: Compressed Class Space (Non-heap memory): committed=1.88 MB, used=1.64 MB, max=1.00 GB, threshold=0.00 B 2017-12-26 16:24:06.778+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: G1 Eden Space (Heap memory): committed=39.00 MB, used=35.00 MB, max=-1.00 B, threshold=? 2017-12-26 16:24:06.778+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: G1 Survivor Space (Heap memory): committed=3.00 MB, used=3.00 MB, max=-1.00 B, threshold=? 2017-12-26 16:24:06.778+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: G1 Old Gen (Heap memory): committed=84.00 MB, used=1.34 MB, max=1.95 GB, threshold=0.00 B 2017-12-26 16:24:06.778+0000 INFO [o.n.k.i.DiagnosticsManager] Operating system information: 2017-12-26 16:24:06.779+0000 INFO [o.n.k.i.DiagnosticsManager] Operating System: Linux; version: 3.10.0-693.5.2.el7.x86_64; arch: amd64; cpus: 8 2017-12-26 16:24:06.779+0000 INFO [o.n.k.i.DiagnosticsManager] Max number of file descriptors: 90000 2017-12-26 16:24:06.780+0000 INFO [o.n.k.i.DiagnosticsManager] Number of open file descriptors: 103 2017-12-26 16:24:06.782+0000 INFO [o.n.k.i.DiagnosticsManager] Process id: [email protected] 2017-12-26 16:24:06.782+0000 INFO [o.n.k.i.DiagnosticsManager] Byte order: LITTLE_ENDIAN 2017-12-26 16:24:06.793+0000 INFO [o.n.k.i.DiagnosticsManager] Local timezone: Etc/GMT 2017-12-26 16:24:06.793+0000 INFO [o.n.k.i.DiagnosticsManager] JVM information: 2017-12-26 16:24:06.794+0000 INFO [o.n.k.i.DiagnosticsManager] VM Name: OpenJDK 64-Bit Server VM 2017-12-26 16:24:06.794+0000 INFO [o.n.k.i.DiagnosticsManager] VM Vendor: Oracle Corporation 2017-12-26 16:24:06.794+0000 INFO [o.n.k.i.DiagnosticsManager] VM Version: 25.151-b12 2017-12-26 16:24:06.794+0000 INFO [o.n.k.i.DiagnosticsManager] JIT compiler: HotSpot 64-Bit Tiered Compilers 2017-12-26 16:24:06.795+0000 INFO [o.n.k.i.DiagnosticsManager] VM Arguments: [-XX:+UseG1GC, -XX:-OmitStackTraceInFastThrow, -XX:+AlwaysPreTouch, -XX:+UnlockExperimentalVMOptions, -XX:+TrustFinalNonStaticFields, -XX:+DisableExplicitGC, -Djdk.tls.ephemeralDHKeySize=2048, -Dunsupported.dbms.udc.source=rpm, -Dfile.encoding=UTF-8] 2017-12-26 16:24:06.795+0000 INFO [o.n.k.i.DiagnosticsManager] Java classpath: AFTER: 2017-12-27 16:17:30.740+0000 INFO [o.n.k.i.DiagnosticsManager] System memory information: 2017-12-27 16:17:30.749+0000 INFO [o.n.k.i.DiagnosticsManager] Total Physical memory: 7.79 GB 2017-12-27 16:17:30.750+0000 INFO [o.n.k.i.DiagnosticsManager] Free Physical memory: 4.23 GB 2017-12-27 16:17:30.750+0000 INFO [o.n.k.i.DiagnosticsManager] Committed virtual memory: 5.62 GB 2017-12-27 16:17:30.751+0000 INFO [o.n.k.i.DiagnosticsManager] Total swap space: 16.50 GB 2017-12-27 16:17:30.751+0000 INFO [o.n.k.i.DiagnosticsManager] Free swap space: 16.19 GB 2017-12-27 16:17:30.751+0000 INFO [o.n.k.i.DiagnosticsManager] JVM memory information: 2017-12-27 16:17:30.751+0000 INFO [o.n.k.i.DiagnosticsManager] Free memory: 1.89 GB 2017-12-27 16:17:30.751+0000 INFO [o.n.k.i.DiagnosticsManager] Total memory: 1.95 GB 2017-12-27 16:17:30.752+0000 INFO [o.n.k.i.DiagnosticsManager] Max memory: 1.95 GB 2017-12-27 16:17:30.777+0000 INFO [o.n.k.i.DiagnosticsManager] Garbage Collector: G1 Young Generation: [G1 Eden Space, G1 Survivor Space] 2017-12-27 16:17:30.777+0000 INFO [o.n.k.i.DiagnosticsManager] Garbage Collector: G1 Old Generation: [G1 Eden Space, G1 Survivor Space, G1 Old Gen] 2017-12-27 16:17:30.778+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: Code Cache (Non-heap memory): committed=4.94 MB, used=4.89 MB, max=240.00 MB, threshold=0.00 B 2017-12-27 16:17:30.778+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: Metaspace (Non-heap memory): committed=14.38 MB, used=13.42 MB, max=-1.00 B, threshold=0.00 B 2017-12-27 16:17:30.778+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: Compressed Class Space (Non-heap memory): committed=1.88 MB, used=1.64 MB, max=1.00 GB, threshold=0.00 B 2017-12-27 16:17:30.779+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: G1 Eden Space (Heap memory): committed=105.00 MB, used=59.00 MB, max=-1.00 B, threshold=? 2017-12-27 16:17:30.779+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: G1 Survivor Space (Heap memory): committed=0.00 B, used=0.00 B, max=-1.00 B, threshold=? 2017-12-27 16:17:30.779+0000 INFO [o.n.k.i.DiagnosticsManager] Memory Pool: G1 Old Gen (Heap memory): committed=1.85 GB, used=0.00 B, max=1.95 GB, threshold=0.00 B 2017-12-27 16:17:30.779+0000 INFO [o.n.k.i.DiagnosticsManager] Operating system information: 2017-12-27 16:17:30.780+0000 INFO [o.n.k.i.DiagnosticsManager] Operating System: Linux; version: 3.10.0-693.5.2.el7.x86_64; arch: amd64; cpus: 8 2017-12-27 16:17:30.780+0000 INFO [o.n.k.i.DiagnosticsManager] Max number of file descriptors: 90000 2017-12-27 16:17:30.781+0000 INFO [o.n.k.i.DiagnosticsManager] Number of open file descriptors: 103 2017-12-27 16:17:30.785+0000 INFO [o.n.k.i.DiagnosticsManager] Process id: [email protected] 2017-12-27 16:17:30.785+0000 INFO [o.n.k.i.DiagnosticsManager] Byte order: LITTLE_ENDIAN 2017-12-27 16:17:30.814+0000 INFO [o.n.k.i.DiagnosticsManager] Local timezone: Etc/GMT 2017-12-27 16:17:30.815+0000 INFO [o.n.k.i.DiagnosticsManager] JVM information: 2017-12-27 16:17:30.815+0000 INFO [o.n.k.i.DiagnosticsManager] VM Name: OpenJDK 64-Bit Server VM 2017-12-27 16:17:30.815+0000 INFO [o.n.k.i.DiagnosticsManager] VM Vendor: Oracle Corporation 2017-12-27 16:17:30.815+0000 INFO [o.n.k.i.DiagnosticsManager] VM Version: 25.151-b12 2017-12-27 16:17:30.815+0000 INFO [o.n.k.i.DiagnosticsManager] JIT compiler: HotSpot 64-Bit Tiered Compilers 2017-12-27 16:17:30.816+0000 INFO [o.n.k.i.DiagnosticsManager] VM Arguments: [-Xms2000m, -Xmx2000m, -XX:+UseG1GC, -XX:-OmitStackTraceInFastThrow, -XX:+AlwaysPreTouch, -XX:+UnlockExperimentalVMOptions, -XX:+TrustFinalNonStaticFields, -XX:+DisableExplicitGC, -Djdk.tls.ephemeralDHKeySize=2048, -Dunsupported.dbms.udc.source=rpm, -Dfile.encoding=UTF-8] 2017-12-27 16:17:30.816+0000 INFO [o.n.k.i.DiagnosticsManager] Java classpath: 只是一个供参考的,我似乎仍然得到Java堆错误。这些机器(不适用于生产只是开发)只有8GB每个








...全文

相关推荐

Ubuntu VPS 安装 Neo4J 详细指南:避坑、调优与安全加固

Neo4J 是面向图数据建模与复杂关系查询的高性能图数据库,其核心能力依赖于 Java 运行时环境、内存映射缓存(pagecache)和 Bolt 二进制协议等底层机制。在资源受限的 Ubuntu VPS 环境中,直接 apt 安装常因 JDK 版本不兼容、JVM 堆内存超限或默认监听地址限制而失败。正确部署需先校准运行时(如强制使用 JDK 17)、合理分配内存(heap + pagecache)、开放并保护 7474/7687 端口,并通过 systemd 日志与 debug.log 进行精准排错。本文

wangdetian161

Python连接Neo4j实战:图数据库建模、Cypher查询与性能优化

图数据库是一种以‘关系’为一等公民的新型数据存储范式,其核心原理在于将实体间关联直接映射为原生存储结构,支持高效路径遍历与图算法计算。相比关系型数据库依赖JOIN和递归应用层处理,图数据库通过Cypher查询语言和Bolt协议实现低延迟、高表达力的关系推理,技术价值体现在复杂网络分析、实时推荐、故障传播追踪等强关联场景。典型应用包括社交人脉挖掘、物流路径优化、风控关系链识别等。本文聚焦Python生态下Neo4j驱动选型、连接池配置、Cypher参数化查询、UNWIND批量导入及gds图算法集成等关键实践,

weixin_34323858

mongodb-linux-x86_64-ubuntu2004-8.0.13.tgz

mongodb-linux-x86_64-ubuntu2004-8.0.13

一and一>二

chromedriver-linux64-159.0.8135.0(Canary).zip

chromedriver-linux64-159.0.8135.0(Canary).zip

LCG元

三相四桥臂电压不对称跌落补偿动态电压恢复器DVR(Simulink仿真实现)

内容概要:本文围绕三相四桥臂动态电压恢复器(DVR)在电压不对称跌落情况下的补偿能力展开,重点介绍了基于Simulink平台构建的仿真模型,用于研究和验证DVR对电网电压不平衡的动态补偿性能。系统采用三相四桥臂逆变器结构,利用其独立的中性线控制能力有效处理零序分量,结合多准PR(Proportional Resonant)控制策略实现对正负序电压分量的精确跟踪与快速响应,从而提升在不平衡负载或电网故障条件下DVR的补偿精度与系统稳定性。文中提供了完整的仿真模型及相关参考文献,涵盖控制算法设计、系统建模与参数整定等关键技术环节,适用于复杂电能质量问题的研究与教学演示。; 适合人群:电气工程、电力电子与电力系统相关专业的研究生、科研人员及从事电能质量治理的技术工程师;具备一定的电路理论、自动控制原理和Simulink仿真基础者更佳。; 使用场景及目标:①研究动态电压恢复器在三相电压不对称跌落工况下的补偿机制与控制策略;②掌握三相四桥臂逆变器在不平衡条件下的建模与控制方法;③深入理解多准PR控制器在正负序分离控制中的应用,提升对电能质量调节装置的设计与仿真能力; 阅读建议:建议结合提供的参考文献与说明文档,逐步搭建并调试Simulink仿真模型,重点关注控制器参数设计与系统动态响应特性,通过设置不同类型的电压跌落场景(如单相跌落、两相短路等)来验证控制策略的有效性与鲁棒性。

威武编程狮
评论 1
收藏 已收藏
分享
返回顶部