GCP Ubuntu实例中的Python多处理Selenium隐藏瓶颈

我遇到了一个独特的问题，我无法找出潜在的瓶颈。该应用程序的基本布局如下:有一个由multiprocessing.JoinableQueue()启动的bot管理器。bot管理器的队列由一个烧瓶端点提供。当一个新用户出现时，bot管理器抛出一个新的bid bot，该bot使用一个headless Chromedriver启动一个Selenium实例，并将任务放入该bot的队列中(也是一个JoinableQueue())。 我做了一个压力测试，100个任务随机分配给~20个用户。Flask的应用程序可以轻松地浏览100个任务，在不到30秒的时间内就可以把它们放到bot管理器的队列中。这些任务包括登录到第三方的网站，做一些只需20-30秒就能完成的动作。 当我在我的个人电脑(Macbook Pro w/ i7 & 16GB)上运行这个压力测试时，压力测试运行顺利，所有100个任务都在2-3分钟内完成。我的CPU的利用率大约是80%，内存压力从来不会太高。 当然，我不能在我的机器上长期运行这个过程，所以我们使用一个GCP计算引擎实例，在一台拥有14.4GB内存的16vCPU机器上运行Ubuntu 18.04。当我在这台机器上运行压力测试时，它遇到了某种隐藏的瓶颈。cpu以50%的利用率运行，然后在所有任务完成之前，它们的利用率迅速下降到最低。Chromedriver开始出现超时问题，并出现一些通用的Chrome“页面未加载”错误。我在其中构建了重试逻辑，一些任务必须在GCP实例上重新加载页面40到50次(在我的Mac上是0次)。总之，在GCP实例上的压力测试需要15-20分钟才能完成，而在我的机器上只需要2-3分钟，而且经常出现故障和Selenium超时。Mac测试运行w/ 0故障或超时。 我已经尝试过通过终端(python3 -u app.py)完全运行Python应用程序，并在docker容器(docker-compose up)中运行，这两种方法都没有加快GCP实例的速度。 我知道这很难调试，特别是在一个StackOverflow的问题上，但是让我来运行一下我已经研究过并试图修复的东西，这可能会对一些尝试的建议有所帮助。我很高兴尝试任何事情，并提供任何额外的信息或调试数据的要求。 因为我是通过终端运行的，所以我受到了ulimit的影响。我曾经在我的个人Mac电脑上收到一个关于“打开了太多文件”的错误提示，这让我开始调查这些限制。限制打开的文件(ulimit - n)在macOS 10.15非常低(256)因此增加到16384年解决这个问题在我的Mac。展望GCP Ubuntu实例,打开文件限制高违约相比(1024)但我仍然增加了限制相同的16384。这并没有帮助，我甚至在没有任何运气的情况下将它增加到一个巨大的65535。Ubuntu比macOS有更多的限制，所以我不能让它们完全一样。下面是我在Ubuntu实例上运行ulimit -a时的当前限制:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 57576
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 65535
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

我已经按照这里的指南做了永久的调整，但没有运气。我也试着在ulimit中调整一些其他的标志，但是似乎没有任何改变。 我最初在创建一个webdriver (webdriver. chrome())时添加了一些不同的选项，但是除了headless和sandbox选项外，我都删除了。这是当前的设置选项:

options.set_headless(True)
options.add_argument('--no-sandbox')
#options.add_argument('--disable-setuid-sandbox')
#options.add_argument('--disable-gpu')
#options.add_argument('--headless')
#options.add_argument('--disable-dev-shm-usage')
#options.add_argument("--proxy-server='direct://'")
#options.add_argument('--proxy-bypass-list=*')

在我今天开始摆弄这个应用程序之前，我已经把无沙盒选项注释掉了，但我刚才还在摆弄我的Chromedriver安装，不得不再次启用这个选项——我忘记了我之前做了什么才使它成为可能。无论如何，无论是否使用沙箱选项，此问题都将持续存在。 我已经研究了与/dev/shm相关的dev shm选项通过阅读/dev/shm，我发现有人为了提高效率把Chromedriver移到了/dev/shm文件夹中，但是我不知道如何使用apt-get把这个包安装到另一个位置…… 我已经尝试使用上面的工具找到瓶颈，但是我不能100%确定我要寻找的是什么，而且没有什么是真正突出的。 上面是在Ubuntu GCP实例和我的个人Mac上运行Py-Spy top的截图(左图)。Ubuntu的运行有许多页面加载问题，由于Selenium超时导致任务不完整，运行时间大约为10分钟。Mac系统在大约3分钟内完美地运行了所有100个任务。 以下是两个Py-Spy输出比较占总时间的百分比:

Ubuntu似乎花了很多时间来处理Selenium，这让我觉得这可能与网络有关?GCP实例的下载速度非常快(运行speedtest-cli返回2000Mbit down/10Mbit up vs 130Mbit down/150Mbit up)，但是上传速度非常慢。我不确定较慢的上传速度是否真的会对网页加载产生那么大的影响? 以下是最后一个任务发送到bot管理器10秒后的输出: 在 HTOP IOTOP 我不知道下一步该做什么，我很乐意尝试任何建议!我有一种感觉，这可能与ulimit的东西有关，但我没能改变任何东西。 问题来源StackOverflow 地址：/questions/59380510/python-multiprocessing-selenium-hidden-bottleneck-in-gcp-ubuntu-instance