jcman indexing 30k mols+30k rx takes 2 1/2 hr?

We are doing an upgrade from 551 to 614 on RHE 5.5, JVM 1.6.0_26 of 31853 reactions and 34128 structures stored in jchem tables. The time to rebuild the indexes was 2 1/2 hours using "jcman -Xmx2024m" . This seems excessive - we would expect this to take less than an hour.

The 614 version is part of a third party product install, so we cannot upgrade to 62x. jchemproperties table is attached - partially obfuscated.

Is this a known issue with this version? 

Hi John,

You have forgot to attach the contents of the JChemProperties.

(or maybe the extension wasn't good for the forum, in that case you may try zip it)

One thing that might slow down the recalculation of JChem tables is a number of Chemical Terms columns with complex computations.

Do you have such columns ?

Complex custom standardization or custom fingerprint parameters may also have an effect on speed.

The output of

jcman t <table_name>

should provide information on this.

Of course the property table data holds even more information.

Best regards,

Szilard

 

Szilard,

Thanks, I probably didn't [Add Attachment] after selection.

If we need more info about the setup, I can check with the software vendor that supplies jchem as part of their product.

-JJ

John,

I don't see anything extraordinary in your property table, pretty much default values.

- Are you sure the server was not heavily loaded with other applications ? ;)

- Can you check if you are running the correct Java by typing

java -version

and paste here the output. 

On some Linux system GNU Java may be installed which is not supported and cause speed issues as well as other problems. Only Oracle (Sun) Java is officially supported.

Best regards,

Szilard

It is an oracle server as well, but this hasn't been a problem in the past.

Looks like it is an oracle standard jvm, although a bit dated:

java version "1.6.0_26"

Java(TM) SE Runtime Environment (build 1.6.0_26-b03)

Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Hi James,

I'm afraid I'm running out of quick tips for the possible cause.

An other potential bottleneck may be network communication (esp. Internet) between the database and the machine where the jcman command is run, but in this case it seems like it's the same machine, right ?

It is also a theoretical possibility  that some particular weird / unlucky structures cause a performance problem for some of our algorithms. 

We can test this if you send us the structure zipped.

I assume they are confidential (not for the forum), in this case you can send them to support _at_ chemaxon.com.

Best regards,

Szilard

Hi John,

 

Are your reaction structures mapped?

 

Best regards,

Norbert

The cartridge and oracle server are on the same server, so it isn't a network delay. 

I'll have to check with the vendor if the reactions are mapped. The reindexing we were doing was a table of reactions and a table of structures, as mentioned in the initial post.

Hi John,

 

I am asking about the mapping because, if the reactions were not mapped originally (very likely, I think), the upgrade/recalculation will do it as it needs it for recalculation of the mapped fingerprints. This operation could increase the upgrade time considerably. 

Best regards,

Norbert