Hi Caio, How do you create threads to process your task? From what I've read, the issue you are describing looks like a synchronization bottleneck (all your threads go through a single lock). Instead, you could've spawned as many jobs as you have partitions in your grid and use a per-partition scan query in each of the jobs. In this case not only will Ignite take care of parallel processing, but it will also make sure that you iterate over data in a consistent manner if topology changes.
A few more suggestions on your task: 1) Try to extract some part of the comparison to Ignite SQL index. This will reduce the number of entries you want to iterate through JNI 2) If you see that JNI call overhead is too big, try using batching - collect a bunch of fingerprints and pass multiple entries to your native algorithm. 2016-09-05 17:30 GMT+03:00 Caio Nishibe <[email protected]>: > As I've mentioned here > <http://apache-ignite-users.70518.x6.nabble.com/Access- > cache-entries-in-C-via-JNI-call-td7462.html> > , I'm trying to use Ignite within a biometric identification system to > store > fingerprint templates in memory and to use Ignite's compute grid capability > to perform matching operations, given an input fingerprint. My > identification task creates one job per cluster node and each job runs a > scan query through local cache entries performing fingerprint comparisons. > The problem is, even though I've created as many threads as cores, the cpu > only rises up to 20%. The comparison algorithm is very cpu intensive. I'm > using the jvm tunning suggested for OFF_HEAP caches. Any ideas or system > tunning hints to get to 100% cpu utilization? > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/JVM-tuning-tp7532.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
