问题描述
正在编写一个使用testthat包进行测试的R包。这些测试在本地和Travis上都通过了。
用户想要绘制并行化在多达24个核心上的效果，因此他在Azure上编程方式设置了一个虚拟机。
他调用devtools::test()，但虚拟机在testthat处卡住了几个小时，CPU使用率为0%。
当用户删除了测试后，代码在一个函数调用处卡住了。用户多次停止和重新启动，所以他认为这是Azure的问题。
其他大小的机器，如Standard_F16s_v2和Standard DS3 v2，也存在相同的问题。
用户想知道如何解决这个问题。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
问题出在使用的镜像上。用户使用的镜像是”microsoft-dsvm:linux-data-science-vm-ubuntu:linuxdsvmubuntu:18.12.01″，这是一个旧的镜像，使用的是R 3.4版本，而不是最新的3.5版本。
用户可以尝试使用以下虚拟机镜像（Ubuntu Server 19.04.19，大小为D64 v3）：
az vm create \
--resource-group <resource group> \
--name <name> \
--image Canonical:UbuntuServer:19.04:19.04.201906280 \
--size Standard_D64_v3 \
--admin-username <azure user> \
--generate-ssh-keys
然后，用户需要在虚拟机上安装R、Rstan以及用于curl和devtools的SSL库：
sudo apt update
sudo apt -y install r-base
sudo apt -y install r-cran-rstan
sudo apt-get install libcurl4-openssl-dev libssl-dev
这样，用户就可以在虚拟机上使用多个核心了。
方案2
使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。
示例：
以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。
方案3
用户可以尝试使用其他虚拟机和镜像组合，以查看是否可以成功在Azure上运行并行化。可以尝试不同的虚拟机大小和不同的镜像版本，以找到适合用户需求的组合。
以上是几种可能的解决方案，用户可以根据自己的需求选择适合的方法来解决问题。希望对您有所帮助！