前言
继上次《怪谈级别疑难问题收录》后，怪谈级别的疑难问题又更新了，这次更新了三个让人吐血的奇葩问题，其中就包括大家又爱又恨的Rstudio，一起围观下。
本教程基于Linux环境演示，计算资源不足的同学可参考：
足够支持你完成硕博生涯的生信环境
忘记宣传了，独享用户连技术支持都是独享的
RTX5090、4080S、5070显卡上机
如果你对下面的教程比较迷茫，那么你可以先行学习编程教程：
十小时学会Linux
生信Linux及服务器使用技巧
5.5h入门R语言
Rstudio后台运行任务消失
-
Rstudio Background Job无缘无故消失？
-
首先，我们先搞清楚Rstudio的Background Job的特点，正常来说运行结束的后台任务，无论成功与否都是有运行记录的，但是这个运行记录不是一直存在的，如果Session变了就看不到了。（有可能是长时间没使用，Session自动退出了；有可能是Rstduio加载缓慢时，点击了Terminate R；有可能是Session崩溃了，之前的Session已经不存在了）
-
最后还是得靠nohup Rscript运行才找出原因，nohup的一个好处是其运行的日志都存储到了一个文件里面，方便后续排查问题！
-
查看官网issue，有相同问题，原因是数据超出软件限制：https://github.com/navinlabcode/copykat/issues/84#issue-1646109349
Rstudio文件管理bug导致文件丢失
当前项目下，有TestFile.R、TeeFile.R两个文件
有一个TestDir目录，其下面有一个TestFile子目录（注意，子目录TestFile与TestFile.R同名）
现在尝试将TestFile.R、TeeFile.R两个文件移动到TestDir目录下，会发生什么？
-
当选择移动文件，当前文件被移动到其它目录，所以Rstudio提示之前打开的文件被移动或删除了，文件出现在目标目录下，符合预期
-
当选择复制文件，会提示文件已存在。如果点击确认覆盖，会导致原文件丢失，目标目录也没有文件复制过去，文件直接丢失！
-
如果是选择目标目录时，直接选择进入到子目录，则不会出现上述问题。
-
总结：经过测试，在最新版Rstudio中已修复此问题，虽然还会提示This file already exists, Do you want to replace it?，但是点击Yes也不会导致文件丢失，相当于取消了这个操作。
在docker容器内部运行代码，运行慢，CPU占用异常
-
用户反馈下面代码运行慢，预计运行时间要几天，不符合预期。
-
下面是使用官方数据的测试代码
install.packages("devtools")
devtools::install_github("data2intelligence/SpaCET")library(SpaCET)visiumPath <- file.path(system.file(package = "SpaCET"), "extdata/Visium_BC")SpaCET_obj <- create.SpaCET.object.10X(visiumPath = visiumPath)# debug(SpaCET:::SpatialDeconv)SpaCET_obj <- SpaCET.deconvolution(SpaCET_obj, cancerType="BRCA", coreNo=1)-
接到用户反馈后，将测试实例迁移到用户实例所在节点，安装相关依赖运行代码，预计运行时间为20分钟左右，符合预期，也能正常运行完毕。
-
后续沟通得知是使用docker运行的R，使用docker部署相同环境rocker/rstudio:4.2（ID为0d506cb12a0f），运行代码可以复现问题，程序运行时间需要几天。
-
在出现问题的场景中，运行程序时CPU占用异常，占用了超过20核心，而正常的场景中，只占用1核心。经过debug调试后，发现程序卡在pbmcapply::pbmclapply这一代码块，考虑应该是依赖的并行库有问题。并且点击Rstudio的红色已经没反应了，强制终止后进程还是占用大量CPU，只能重启docker容器，Rstudio崩溃。
-
网上搜索相关资料，发现有相关的帖子
-
https://forums.docker.com/t/r-mcmapply-parallized-mapply-function-broken-with-docker-linux/143758/6
-
https://github.com/OpenMathLib/OpenBLAS/issues/2642
-
大概意思是openblas这个库在某些场景下有bug，可以卸载其其它依赖，仅安装libopenblas-openmp-dev，重启session后运行（一定要重启，不重启无效），以下命令在docker里面的命令行执行。
apt remove -y libopenblas0-pthread libopenblas0 libopenblas0-openmp libopenblas-openmp-dev libopenblas-devapt install libopenblas-openmp-dev-
移除上述依赖后，重启session，重新运行代码，程序运行介绍预计时间正常了，CPU占用也恢复正常。
-
将coreNo适当调大也能正常并行加速程序运行，程序运行时间缩短到5分钟。
结语
本系列文章记录了那些我们实际遇到过的，匪夷所思的一些问题，很多用户遇到这种问题，往往第一时间觉得是服务器的问题，但是经过实际的排查，发现都是一些怪谈级别的bug或者问题。
)
map组件)
