在测试数据库时发现了一个以前一直忽略的问题

在Drupal7的job page（Your Web address/admin/tripal/tripal_jobs）里会依据我们向后台发送执行内容的时间进行排序（以job name前的id区分先后关系）并且按照顺序执行，在默认条件下它只会一条接着一条进行Run，在正在有运行的Job时，就会无法执行后续的Job

例：在使用Tripal Data Loader上传GFF3文件时，这个Job所使用的时间很长，所以我在建六个BLAST库后进行测试BLAST时这个上传GFF3的Job仍然在占用Drush所以BLAST进行比对就会一直不出结果（一直停留在等待页面）。还以为是BLAST库的问题或者功能的问题，再去测试容器测试库以后可以正常比对，所以库是没问题的。

现在就意识到了可能是drush后台被占用的可能了，去搜索了一下平行多线程运行drush命令：

[root@6e43d822f3bf html]# drush --parallel=2 trp-run-jobs --username=admin --root=/var/www/html
2024-04-04 04:31:56
Tripal Job Launcher (in parallel)
Running as user 'admin'
-------------------
2024-04-04 04:31:56: There are 1 jobs queued.
2024-04-04 04:31:56: Job ID 539.
2024-04-04 04:31:56: Calling: tripal_jbrowse_mgmt_create_instance_files(9)

使用 --parallel=2 参数平行任务（等于2就是除去现在正在利用Drush的那个Job外再跑另一个，因为尝试用1是没有任何改变的）。现在就可以在执行GFF3上传的同时进行BLAST比对任务和其他一些需要后台Drush的其他操作了

再附加两个有用的命令

查看处理任务队列的后台进程，查看当前状态（查trpjob-daemon的当前状态，包是否正在运行以及相关的统计信息）只有当它进程状态ok时才可以在后台正常执行进程，否则就要start以后才可以（将status改为start即可）

[root@6e43d822f3bf html]# drush trpjob-daemon status
The Daemon is currently running...
The last known status for this daemon is:
    PID: 11869
    Hibernating: FALSE
    Number of Iterations: 3136
    Current Log File: /tmp/drupal-TripalDaemon_20240404.log
    Running Job: FALSE
    Current Jobs: None.
                                                                                                                                                                                            [ok]

用drush命令停下某个id的进程。其中，$pid 是要停止的进程的 ID。进程ID可以通过上面的查询状态看到

drush php-eval "drupal_kill($pid)"