| Attachment | Size |
|---|---|
 run_on_server.png | 2.38 KB |
| run_on_my_pc.png | 4.89 KB |
I just run the demo script of the package and I don't modify the script.
when I run the demo script AlternativeApproaches.R on my computer, the running cpu is around 100% and completed in 10 seconds.
input:
time Rscript AlternativeApproaches.R
output:
real 0m2.431s
user 0m3.752s
sys 0m0.093s
But when I run the script on my company CentOS server, the running cpu is above 500% and completed in more than 15 minutes.
input:
time Rscript AlternativeApproaches.R
output:
real 2m39.438s
user 15m6.753s
sys 0m2.392s
it waste a lot of time to complete the mxRun() function.
I have checked the param of mxRun() he mxOption(), but I didn't find out what param involved to this problem.
what should I do to improve the performance of the script(almost all the demo script) when I run it on my server?
Printer-friendly version
What does
mxVersion()
return on the CentOS box?
mxVersion():
OpenMx version: 2.0.0.3838
R version: R version 3.1.1 (2014-07-10)
Platform: x86_64-unknown-linux-gnu
Default optimiser: CSOLNP
I run the script on my company Bioinformatics Linux Cluster(BLC), the system Version of the BLC is:
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.5 (Final)
Release: 5.5
Codename: Final
I think may be the problem is involved to the setting of BLC, but I don't know what cause this problem. Is there anyone else get into trouble with this problem?
I'm not at all sure this will fix the performance problem, but try adding
To the script anywhere before
mxRun(). Then see if the performance is still poor. This command changes the optimizer from its current CSOLNP to NPSOL. Is the performance the same for the other optimizer?thank you for your answer!
the method don't not solve the problem, so this is not the method I need, but thank you all the same.
You should definitely try the mxOption() to change the optimizer, as suggested by Dr. Hunter.
Another thing to explore is whether using multiple cores is somehow the problem. You can change the number being used by Centos using the following anywhere before the mxRun():
this would probably set the number of threads to be the same as on the PC, i.e., 1. However, some performance metrics might indicate 100% with just one core being used (and report 200% for 2 etc). Others might indicate 100% when all cores are running. Without more information I don't know which. If both the PC and Centos versions are given the above mxOption then for sure they would be on the same footing.
It solve my problem, I think it is the one I need, thank you!