Fork me on GitHub
#datomic
<
2019-12-04
>
iagwanderson02:12:06

yet on system planning for analytics support. I split my stack and managed to make the presto server to use a query group with 2 instances i3.xlarge which seems fine. Looking at the cloudwatch during some workload, the query group is not reaching cpu utilization above 40% which is ok by me. However, it still gets 6min to return a query like select date, sum(value) from table group by date with a table of 5MM "rows" (in pg), way too slow (?) 😕 As we can see in the screenshot the largest access-gateway available in cloud formation has only 2 processors and it is constantly on 100% usage during workload. The 4gb of memory looks like enough, but 2 cpu is not too low?

iagwanderson03:12:32

In fact, I see this behavior when running more than 1 query at the time. Didnt notice the x-ray launched some queries in the database. But I think the point is still valid. Would be possible to use a larger instance for access-gateway?

okilimnik07:12:28

I want to connect Datomic Cloud via VPC Peering and there is a note in the end of documentation:

If your application does not run in the provided datomic-$(SystemName)-apps security group, you must configure the datomic-$(SystemName)-entry security group to allow ingress from your application's security group.
But I don't see any *-entry security group in my environment. What security group have I to modify?

okilimnik07:12:35

it's a production topology

okilimnik09:12:35

@ghadi My question above was right about documentation)

marshall13:12:13

@okilimnik That section at the bottom that you mentioned is specifically for legacy versions of Datomic Cloud, prior to 397

okilimnik13:12:47

I see, thanks

john92020:12:07

Anyone using Datomic cloud from Heroku?

rgorrepati21:12:42

Hi, Does any know if the datomic transactor is ported to jdk 11