T2.micro instance for Metabase 0.28 - weird behaviour- AWS

After being charged 80 bucks per month for using a t2.small instance, I decided to try metabase on a t2.micro instance - SIngle Zone (free) on AWS.

I started fresh, sat up Metabase and it works about ok.

I can display questions, DB connection works.

However, I have 2 issues:

  1. Pulses always fail (card could not be displayed)
  2. Every time I go to a dashboardor question, the results fail to display until I refresh (F5) which is quite annoying.

I’m connecting to a 8 mb MySQL DB, a pretty simple one which is hosted at Godaddy. Direct link is however not activated but I duplicated this DB with a direct link and the same problem appears.

What could be the problem?

Thanks a lot.

Kind regards

Matth

Ps: with the small instance (multi zone) I also had dashboarding issues but the pulse went perfectly well.

Does logs reveal anything?

Hello jornh,

Thanks for your message. Link Communication failed.

Apparently, the pulse worked with the backup db with direct access enabled.

I believe it might be because the sql connection is open but there should be max 5 connections at the same time.

Do you have another idea?

Thanks,

Matth

Sounds like a reasonable explanation. Hard for me to suggest anything better :slight_smile:

Ok, so the pulse stopped working with the backup db and I get communication error while this db has direct access and is not connected to anything else than metabase.

And being on godaddy, I just have no way of checking the MySQL connection.

My question is, does anybody have a 100% reliable access to their MySQL db using Metabase? It often happens that I have a first try with a communication erro rand then it succeeds.

Do you honestly think a t2.micro vs a t2.small could generate this weird behaviour? The difference between both are:

  • single instance
  • 2 GB vs 1 GB

Thanks for your help. Here is the metabase log:

The last packet successfully received from the server was 71,836 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago.
(“driver.generic_sql$get_tables.invokeStatic(generic_sql.clj:296)”
“driver.generic_sql$get_tables.invoke(generic_sql.clj:293)”
“driver.generic_sql$post_filtered_active_tables.invokeStatic(generic_sql.clj:319)”
“driver.generic_sql$post_filtered_active_tables.invoke(generic_sql.clj:314)”
“driver.generic_sql$fn__47867$G__47748__47874.invoke(generic_sql.clj:30)”
“driver.generic_sql$describe_database.invokeStatic(generic_sql.clj:364)”
“driver.generic_sql$describe_database.invoke(generic_sql.clj:359)”
“driver$fn__25431$G__25369__25438.invoke(driver.clj:51)”
“sync.fetch_metadata$fn__35644$db_metadata__35649$fn__35650.invoke(fetch_metadata.clj:13)”
“sync.fetch_metadata$fn__35644$db_metadata__35649.invoke(fetch_metadata.clj:10)”
“sync.sync_metadata.tables$fn__36774$db_metadata__36779$fn__36780.invoke(tables.clj:127)”
“sync.sync_metadata.tables$fn__36774$db_metadata__36779.invoke(tables.clj:124)”
“sync.sync_metadata.tables$fn__36834$sync_tables_BANG___36839$fn__36840.invoke(tables.clj:144)”
“sync.sync_metadata.tables$fn__36834$sync_tables_BANG___36839.invoke(tables.clj:139)”
“sync.sync_metadata$fn__36864$sync_db_metadata_BANG___36869$fn__36870$fn__36871.invoke(sync_metadata.clj:26)”
“sync.util$do_with_error_handling.invokeStatic(util.clj:124)”
“sync.util$do_with_error_handling.invoke(util.clj:119)”
“sync.util$do_with_error_handling.invokeStatic(util.clj:122)”
“sync.util$do_with_error_handling.invoke(util.clj:119)”
“driver$fn__25602.invokeStatic(driver.clj:226)”
“driver$fn__25602.invoke(driver.clj:226)”
“driver$fn__25526$G__25357__25535.invoke(driver.clj:51)”
“sync.util$sync_in_context$fn__34128.invoke(util.clj:115)”
“sync.util$with_db_logging_disabled$fn__34125.invoke(util.clj:106)”
“sync.util$with_start_and_finish_logging$fn__34120.invoke(util.clj:92)”
“sync.util$with_sync_events$fn__34117.invoke(util.clj:75)”
“sync.util$with_duplicate_ops_prevented$fn__34108.invoke(util.clj:54)”
“sync.util$do_sync_operation.invokeStatic(util.clj:142)”
“sync.util$do_sync_operation.invoke(util.clj:139)”
“sync.sync_metadata$fn__36864$sync_db_metadata_BANG___36869$fn__36870.invoke(sync_metadata.clj:23)”
“sync.sync_metadata$fn__36864$sync_db_metadata_BANG___36869.invoke(sync_metadata.clj:20)”
“task.sync_databases.SyncAndAnalyzeDatabase.execute(sync_databases.clj:36)”)

Kind regards

Matth

If it may help, some queries have 16 db calls…

Feb 14 15:07:10 DEBUG metabase.middleware :: POST /api/card/15/query 200 (299 ms) (16 DB calls)
Feb 14 15:07:13 WARN metabase.query-processor.middleware.expand :: You shouldn’t specify an :and filter with only one subclause.
Feb 14 15:07:14 DEBUG metabase.middleware :: POST /api/card/15/query 200 (616 ms) (16 DB calls)

Happy Valentine Day, btw… :wink:

Possibly related?: (issue is currently active being worked on)

Thanks for your help.

The weird part is that my previous setup worked much better on a t2.small instance.

Is there anybody else running a T2.micro instance with calls to a MySQL DB and that works flawlessly?

Thanks for letting me know.

KR

Matth