前言
繼上次《怪談級別疑難問題收錄》后，怪談級別的疑難問題又更新了，這次更新了三個讓人吐血的奇葩問題，其中就包括大家又愛又恨的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組件)
